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 regards.
Douglas
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 has been
Dear user of Kernel.org,
We warn you about some attacks on your e-mail account. Your computer may
contain viruses, in order to keep your computer and e-mail account safe,
please, follow the instructions.
For further details see the attach.
Sincerely,
The Kernel.org team
Hi all,
/proc/scsi/scsi currently has a very dumb implementation of the seq_file
api which causes 'cat /proc/scsi/scsi' to return with -ENOMEM when a
large amount of devices are connected.
This patch impelements the proper seq_file interface which prints out
all devices sequentially.
The use of
On Thu, Apr 07, 2005 at 11:46:27AM +0200, Hannes Reinecke wrote:
Hi all,
/proc/scsi/scsi currently has a very dumb implementation of the seq_file
api which causes 'cat /proc/scsi/scsi' to return with -ENOMEM when a
large amount of devices are connected.
/proc/scsi/scsi is deprecated and
Christoph Hellwig wrote:
On Thu, Apr 07, 2005 at 11:46:27AM +0200, Hannes Reinecke wrote:
Hi all,
/proc/scsi/scsi currently has a very dumb implementation of the seq_file
api which causes 'cat /proc/scsi/scsi' to return with -ENOMEM when a
large amount of devices are connected.
On Thu, Apr 07, 2005 at 01:21:23PM +0200, Hannes Reinecke wrote:
/proc/scsi/scsi is deprecated and even only compiled in if
legacy /proc/scsi/ support is enabled. Please move over to lssci which
is using sysfs ASAP.
Ah. And that's enough reason for it not to work properly?
Deprecated
First forgive me to change the mail subject to the above.
The HBA driver is Fusion_MPT, the log file is filled up by the following lines:
Apr 7 19:15:29 tiger43 kernel: mptbase: ioc0: IOCStatus(0x0043): SCSI Device
Not
On Thu, 2005-04-07 at 08:49 +0200, Jens Axboe wrote:
On Wed, Apr 06 2005, James Bottomley wrote:
My proposal is to correct this by moving the data back to the correct
object, and make any object using it hold a reference, so this would
make the provider of the block request_fn hold a
On Thu, Apr 07, 2005 at 09:18:38AM -0400, James Bottomley wrote:
On Thu, 2005-04-07 at 08:49 +0200, Jens Axboe wrote:
On Wed, Apr 06 2005, James Bottomley wrote:
My proposal is to correct this by moving the data back to the correct
object, and make any object using it hold a reference, so
On Thu, Apr 07 2005, James Bottomley wrote:
On Thu, 2005-04-07 at 08:49 +0200, Jens Axboe wrote:
On Wed, Apr 06 2005, James Bottomley wrote:
My proposal is to correct this by moving the data back to the correct
object, and make any object using it hold a reference, so this would
make
On Thu, 2005-04-07 at 14:22 +0100, Christoph Hellwig wrote:
Do we really need the sdev_lock pointer? There's just a single place
where we're using it and the code would be much more clear if it had just
one name.
Humour me for a while. I don't believe we have any way the lock can be
used
This patch addresses the sparse -Wbitwise warnings that Christoph wanted
me to eliminate. This mostly consisted of making data structure
elements of hardware associated structures the __le* equivalent.
Although there were a couple places where there was mixing of cpu and le
variable math. These
On Thu, Apr 07 2005, James Bottomley wrote:
On Thu, 2005-04-07 at 15:32 +0200, Jens Axboe wrote:
I think Christophs point is that why add sdev_lock as a pointer, instead
of just killing it? It's only used in one location, so it's not really
that confusing (and a comment could fix that).
This is my first attempt at submitting a patch, so I hope I'm not making any
mistakes...
This patch fixes two problems I came across in sg, both of which occur when
sg_remove is called on a disk which hasn't yet been sg_release'd:
1. I got the following Oops in sg_remove:
--
Unable to handle
Hi,
Just wamted to ask if anyone has some will into it, or if this driver
shoudl be removed from the kernel as broken.
--
pozdrawiam |Help me master, I felt the burning twilight behind
[EMAIL PROTECTED]|those gates of stell... --Perihelion, Prophecy Sequence
-
To unsubscribe from this list:
On Thu, Apr 07, 2005 at 11:06:03AM +1000, Douglas Gilbert wrote:
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?
Patrick,
lsscsi currently uses proc_name so
On Thu, Apr 07, 2005 at 08:35:16AM +0200, Frederic TEMPORELLI wrote:
Hi,
Sorry, no such driver directory in /sys/class/scsi_host/hostX/
Doug answered that.
Why do you need it?
If you answer the above you might get better/other suggestions.
-- Patrick Mansfield
-
To unsubscribe from this
18 matches
Mail list logo
