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_ use
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
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
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
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:
Andrew Vasquez
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 be the
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
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 comfortable with
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
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 kernel
module
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 admin policy to
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-by:
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
struct in
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
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
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, and
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
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
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. Any
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
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
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 the
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
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
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
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.
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:
--- 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_random_bytes() or
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
Status: running
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
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(-)
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(-)
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
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
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
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
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 files
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/megaraid_sas.h
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 the number
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 thousands
--- 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, or what OS
-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;
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 PROTECTED]; [EMAIL
--- 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
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 show
Target 1:
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
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
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
51 matches
Mail list logo
