On Wed, Oct 03, 2007 at 08:23:14PM -0700, Matthew Jacob wrote:
> For smaller bit spaces like 64 bit WWNs, you cannot, as you correctly
> point out, generate reliably unique numbers all by youself. The
> closest you could probably come is using a type 5 WWN with a known
> single OUI and then use "se
Matthew Jacob wrote:
A much better choice is to get real stamped serial number WWNs. I also
hold with some of the other folks on this discussion that some of this
is policy that the admin should be allowed to choose. After they've
segmented the company's main fabric by choosing unwisely and
forge
> But having a WWN generator in the kernel, although not terribly
> difficult to write, makes it possible to create an inconsistent
> storage domain. It is that possibility which troubles me,
> due to the intention of SAS WWNs.
But one should make sure that you *do* create a consistent storage
do
On Wed, 03 Oct 2007 12:47:26 -0700
Seokmann Ju <[EMAIL PROTECTED]> wrote:
> FUJITA Tomonori wrote:
> > On Mon, 01 Oct 2007 11:00:44 -0700
> > Seokmann Ju <[EMAIL PROTECTED]> wrote:
> >> atl-01:/lib/modules/2.6.23-rc3-smp-tgt/kernel/drivers/scsi/qla2xxx #
> >> tgtadm --lld fc --mode target --op sh
--- David Miller <[EMAIL PROTECTED]> wrote:
> From: Luben Tuikov <[EMAIL PROTECTED]>
> Date: Wed, 3 Oct 2007 15:08:48 -0700 (PDT)
>
> > Your "want to get their card working" way of view is very
> > simplistic to justify generating and assigning SAS WWN in the kernel.
> > This is the job of the man
On Wed, 3 Oct 2007 17:32:55 -0600
"Patro, Sumant" <[EMAIL PROTECTED]> wrote:
>
>
> > -Original Message-
> > From: FUJITA Tomonori [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, October 02, 2007 5:01 PM
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> > [EMAIL PR
> -Original Message-
> From: FUJITA Tomonori [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 02, 2007 5:01 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; Patro, Sumant; DL-MegaRAID
> Linux; linux-
From: Luben Tuikov <[EMAIL PROTECTED]>
Date: Wed, 3 Oct 2007 15:08:48 -0700 (PDT)
> Your "want to get their card working" way of view is very
> simplistic to justify generating and assigning SAS WWN in the kernel.
> This is the job of the manufacturer/packager, not the host OS.
When you are thous
--- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Luben Tuikov wrote:
> > What is needed is persistence, regardless of reboots of what OS
> > is running on the host CPU/system. SAS WWNs are properties of
> > the SAS target/initiator port, they are not properties of when
> > the host system was booted,
On Wed, Oct 03, 2007 at 11:19:22PM +0900, FUJITA Tomonori wrote:
> On Tue, 2 Oct 2007 09:44:13 -0700
> Greg KH <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Oct 02, 2007 at 09:25:34AM -0600, Matthew Wilcox wrote:
> > > On Tue, Oct 02, 2007 at 05:23:39PM +0200, Kay Sievers wrote:
> > > > Just looking at
On Mon, 01 Oct 2007 11:51:48 -0400 bo yang wrote:
> Adding module parameters to configure max sectors per request & # of cmds per
> lun.
>
> Signed-off-by: Bo Yang <[EMAIL PROTECTED]>
>
> ---
> drivers/scsi/megaraid/megaraid_sas.c | 68 -
> drivers/scsi/megaraid/megar
Update version and changelog.
Updated "LSI Logic" to new name "LSI"
Signed-off-by: Bo Yang <[EMAIL PROTECTED]>
---
Documentation/scsi/ChangeLog.megaraid_sas | 160
drivers/scsi/megaraid/megaraid_sas.c | 10 -
drivers/scsi/megaraid/megaraid_sas.h |8 -
3 fil
Added module parameter "poll_mode_io" to support for "polling" (reduced
interrupt operation).
In this mode, IO completion interrupts are delayed. At the end of
initiating IOs, the
driver schedules for cmd completion if there are pending cmds. A
timer-based interrupt
ha
Driver will call cmd completion routine from Reset path without waiting for cmd
completion from isr context.
Signed-off-by: Bo Yang <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_sas.c | 122 +
drivers/scsi/megaraid/megaraid_sas.h |2
2 files changed, 70 ins
MegaRAID utilities expect sense_buff to be of type unsigned long.
Signed-off-by: Bo Yang <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_sas.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff -uprN linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c
linux-2
1. Setting the max_sectors_per_req based on max SGL supported by the FW. Prior
versions calculated
this value from controller info's max_sectors_1, max_sectors_2. For
certain controllers/FW,
this was resulting in a value greater than max SGL supported by the FW.
Now we take th
Adding module parameters to configure max sectors per request & # of cmds per
lun.
Signed-off-by: Bo Yang <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_sas.c | 68 -
drivers/scsi/megaraid/megaraid_sas.h |2
2 files changed, 68 insertions(+), 2 deletions(-)
Driver will skip physical devices scan for the first time if the fast_load is
set. This is to reduce time for loading driver.
Signed-off-by: Bo Yang <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_sas.c | 69 +++--
1 files changed, 55 insertions(+), 14 deletions(-)
Luben Tuikov wrote:
What is needed is persistence, regardless of reboots of what OS
is running on the host CPU/system. SAS WWNs are properties of
the SAS target/initiator port, they are not properties of when
the host system was booted, or what OS is running on it.
As part of the previously d
Adding hibernation support. suspend, resume routine implemented.
Signed-off-by: Bo Yang <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_sas.c | 302 +++--
drivers/scsi/megaraid/megaraid_sas.h |1
2 files changed, 233 insertions(+), 70 deletions(-)
diff -uprN linu
Just updated jgarzik/misc-2.6.git#ALL...
'ALL' meta-branch contains these branches, exported for review and testing:
dmi-const DMI subsystem constification
--> added your fix/warning patches
isdn-cleanups ISDN subsystem cleanups for 2.6.24
--> no word fr
FUJITA Tomonori wrote:
> On Mon, 01 Oct 2007 11:00:44 -0700
> Seokmann Ju <[EMAIL PROTECTED]> wrote:
>> atl-01:/lib/modules/2.6.23-rc3-smp-tgt/kernel/drivers/scsi/qla2xxx # tgtadm
>> --lld fc --mode target --op show
>> Target 1: volume1
>> System information:
>> Driver: fc
>> S
--- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Matthew Jacob wrote:
> >> The generation algorithm is whatever makes people happy. I would
> >> probably pick a fixed prefix like 0x6C 0x69 0x63 ("lin"), something that
> >> doesn't conflict with IEEE org ids for a long time to come. Then,
> >> get_ran
On Tuesday, October 02, 2007 5:06 PM, Darrick J. Wong wrote:
> Yep. Replied to it, too. Apparently it never got to you, so I've
> attached it below.
>
Sorry, I didn't receive the previous email you sent.
> -
>
> On Thu, Sep 20, 2007 at 07:06:35PM -0600, Moore, Eric wrote
On Tue, Oct 02, 2007 at 08:02:45PM +0200, Rolf Eike Beer wrote:
> volatile here is probably nonsense. Either you need proper locking on this
> struct in case there may be side-effects between different callers or it's
> unneeded at all. This looks really suspicious:
Yes, it's most likely wrong.
Matthew Jacob wrote:
The generation algorithm is whatever makes people happy. I would
probably pick a fixed prefix like 0x6C 0x69 0x63 ("lin"), something that
doesn't conflict with IEEE org ids for a long time to come. Then,
get_random_bytes() or hash some useful machine characteristics for the
Christoph Hellwig wrote:
On Wed, Oct 03, 2007 at 01:59:23PM -0400, Jeff Garzik wrote:
Come on. The patches were posted for comments, and Rolf commented.
Don't give him a hard time for a valid comment.
Sorry, but these comments are utterly useless. It's not like we're doing
anything related t
On Wed, Oct 03, 2007 at 01:59:23PM -0400, Jeff Garzik wrote:
> Come on. The patches were posted for comments, and Rolf commented.
> Don't give him a hard time for a valid comment.
Sorry, but these comments are utterly useless. It's not like we're doing
anything related to dma mapping, but just
>
> The generation algorithm is whatever makes people happy. I would
> probably pick a fixed prefix like 0x6C 0x69 0x63 ("lin"), something that
> doesn't conflict with IEEE org ids for a long time to come. Then,
> get_random_bytes() or hash some useful machine characteristics for the
> rest of th
Christoph Hellwig wrote:
On Wed, Oct 03, 2007 at 07:32:24PM +0200, Rolf Eike Beer wrote:
It's not about passing NULL there. We need to do that. But we should call it
with NULL as argument and not with ha->pdev to make this obvious.
Feel free to send your cleanup patches once we've finished doi
FUJITA Tomonori wrote:
On Tue, 2 Oct 2007 09:44:13 -0700
Greg KH <[EMAIL PROTECTED]> wrote:
On Tue, Oct 02, 2007 at 09:25:34AM -0600, Matthew Wilcox wrote:
On Tue, Oct 02, 2007 at 05:23:39PM +0200, Kay Sievers wrote:
Just looking at the number of devices, it seems that allocating it
dynamical
On Wed, Oct 03, 2007 at 07:32:24PM +0200, Rolf Eike Beer wrote:
> It's not about passing NULL there. We need to do that. But we should call it
> with NULL as argument and not with ha->pdev to make this obvious.
Feel free to send your cleanup patches once we've finished doing the
important heavy l
Christoph Hellwig wrote:
> On Tue, Oct 02, 2007 at 07:20:38PM +0200, Rolf Eike Beer wrote:
> > Same thing as in ISA patch: this is not PCI and we should not hide what
> > we're doing so dma_alloc_consistent(NULL, ...) is better IMHO.
>
> passing NULL is the documented way to deal with ISA/EISA devi
On Tue, Oct 02, 2007 at 07:20:38PM +0200, Rolf Eike Beer wrote:
> Same thing as in ISA patch: this is not PCI and we should not hide what we're
> doing so dma_alloc_consistent(NULL, ...) is better IMHO.
passing NULL is the documented way to deal with ISA/EISA devices with
the old pci dma api. An
On Tue, 2007-09-11 at 20:39 +0300, Boaz Harrosh wrote:
> - regrouped variables for easier reviewing of next patch
> - Support of cmnd==NULL in call to scsi_send_eh_cmnd()
> - In the copy_sense case set transfer size to the minimum
> size of sense_buffer and passed @sense_bytes. cmnd[4] is
>
On Tue, 2007-09-11 at 11:04 +0300, Boaz Harrosh wrote:
> - Drivers/transports that want to send a synchronous REQUEST_SENSE command
>as part of their .queuecommand sequence, have 2 new API's that facilitate
>in doing so and abstract them from scsi-ml internals.
>
>void scsi_eh_prep_cmn
Douglas Gilbert wrote:
Jeff Garzik wrote:
Luben Tuikov wrote:
--- Jeff Garzik <[EMAIL PROTECTED]> wrote:
The admin will have the option to auto-generate a WWN, should they so
desire.
What does that mean? "auto-generate"? By whom?
The admin tells the kernel module to auto-generate a WWN, an
Michael Reed wrote:
Jeff Garzik wrote:
Luben Tuikov wrote:
Do you mean:
"The admin will have the option to SPECIFY(SET) a WWN, should they
sodesire."
OR do you mean:
"The admin will have the option to HAVE THE KERNEL auto-generate a WWN,
should they so desire."
Both. It is up to a
Rolf Eike Beer wrote:
What we have here is cleanly not PCI memory as it's ISA initialisation. And
for making things obvious passing NULL as first argument of
dma_alloc_consistent() is IMHO the better way.
While this is true, this is largely a code movement patch.
It's up to Boaz/Christoph wh
Boaz Harrosh wrote:
> - Cleanup the rest of the scsi_cmnd-SCp members and move them
> to gdth_cmndinfo:
> SCp.have_data_in => volatile wait_for_completion
> Signed-off-by Boaz Harrosh <[EMAIL PROTECTED]>
volatile here is probably nonsense. Either you need proper locking on this
stru
Boaz Harrosh wrote:
> Split eisa probing into it's own helper, and do proper error unwinding.
> Protect EISA probind by the proper CONFIG_EISA symbol.
>
> Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
> @@ -5694,6 +5582,148 @@ static int gdth_isa_probe_one(struct
> scsi_host_template *shtp,
Boaz Harrosh wrote:
> (note: this is ontop of Jeff's pci cleanup patch)
>
> Split out isa probing into a helper of it's own. Error handling is
> cleaned up, but errors are not propagated yet. Also enclose the isa
> probe under the proper CONFIG_ISA symbol instead of the !IA64 hack.
>
> Signed-off
Jeff Garzik wrote:
> Luben Tuikov wrote:
>> Do you mean:
>> "The admin will have the option to SPECIFY(SET) a WWN, should they
>> sodesire."
>> OR do you mean:
>> "The admin will have the option to HAVE THE KERNEL auto-generate a WWN,
>>should they so desire."
>
> Both. It is up to
Jeff Garzik wrote:
> Luben Tuikov wrote:
>> --- Jeff Garzik <[EMAIL PROTECTED]> wrote:
>>> The admin will have the option to auto-generate a WWN, should they so
>>> desire.
>
>> What does that mean? "auto-generate"? By whom?
>
> The admin tells the kernel module to auto-generate a WWN, and the
Christoph Hellwig wrote:
On Tue, Oct 02, 2007 at 10:28:29PM -0400, Jeff Garzik wrote:
Incorrect. That is highly platform specific, with many using unsigned
long, since the [non-x86] platform is generally pointing to a special
memory region rather than directly using an x86-like instruction.
Matthew Wilcox wrote:
On Wed, Oct 03, 2007 at 10:28:31AM -0400, Jeff Garzik wrote:
Matthew Wilcox wrote:
On Tue, Oct 02, 2007 at 10:13:07PM -0400, Jeff Garzik wrote:
check dma_map_single for error
It's on the todo list. Since so many other drivers don't check
dma_map_single for error, I feel
On Wed, Oct 03, 2007 at 10:28:31AM -0400, Jeff Garzik wrote:
> Matthew Wilcox wrote:
> >On Tue, Oct 02, 2007 at 10:13:07PM -0400, Jeff Garzik wrote:
> >>check dma_map_single for error
> >
> >It's on the todo list. Since so many other drivers don't check
> >dma_map_single for error, I feel comforta
Matthew Wilcox wrote:
On Tue, Oct 02, 2007 at 10:13:07PM -0400, Jeff Garzik wrote:
check dma_map_single for error
It's on the todo list. Since so many other drivers don't check
dma_map_single for error, I feel comfortable with leaving it for later.
The issue became more urgent with x86-64 a
On Tue, 2 Oct 2007 09:44:13 -0700
Greg KH <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 02, 2007 at 09:25:34AM -0600, Matthew Wilcox wrote:
> > On Tue, Oct 02, 2007 at 05:23:39PM +0200, Kay Sievers wrote:
> > > Just looking at the number of devices, it seems that allocating it
> > > dynamically would b
On Mon, 01 Oct 2007 11:00:44 -0700
Seokmann Ju <[EMAIL PROTECTED]> wrote:
> FUJITA Tomonori wrote:
> > On Thu, 27 Sep 2007 07:34:52 -0700
> > Seokmann Ju <[EMAIL PROTECTED]> wrote:
> >
> >> FUJITA Tomonori wrote:
> >>> On Fri, 21 Sep 2007 07:34:18 -0700
> >>> Seokmann Ju <[EMAIL PROTECTED]> wrote
On Tue, Oct 02, 2007 at 10:13:07PM -0400, Jeff Garzik wrote:
> check dma_map_single for error
It's on the todo list. Since so many other drivers don't check
dma_map_single for error, I feel comfortable with leaving it for later.
--
Intel are signing my paycheques ... these opinions are still mi
Hi
Sorry I Got no answer, so i resend
i think there is wasted space in allocated pages for
request and response rings.
The allocations are made with REQUEST_ENTRY_CNT + 1 and
RESPONSE_ENTRY_CNT + 1, but they are set with 256 and 16.
So we got more pages, which we dont use very much.
Can you ple
Hi
Sorry, I got no answer, so i resend.
I think there will be a wrong goto target after a failed
pci_set_dma_mask.
Please Check.
Signed-off-by: Johannes Dickgreber [EMAIL PROTECTED]
---
--- qla1280.c.orig 2007-09-19 23:32:33 +0200
+++ qla1280.c 2007-09-19 23:58:46 +0200
@@ -4298,7 +4298,
On Tue, Oct 02, 2007 at 11:15:01PM -0400, Jeff Garzik wrote:
> You're pushing against over a decade-long practice and moving into
> NAK-land... This is the way portable drivers have always been written.
Fortunately you're not the one to NAK scsi driver for this kind of
bullshit. Pleae grow up.
On Tue, Oct 02, 2007 at 10:28:29PM -0400, Jeff Garzik wrote:
> Incorrect. That is highly platform specific, with many using unsigned
> long, since the [non-x86] platform is generally pointing to a special
> memory region rather than directly using an x86-like instruction.
For port I/O we _do_ u
55 matches
Mail list logo
