Thank you Randy, Jens for your suggestions. I folded the second patch as
it is just a clean up. Here is the fixed one patch version.
Signed-off-by: Mike Christie <[EMAIL PROTECTED]>
Signed-off-by: Malahal Naineni <[EMAIL PROTECTED]>
Thanks, Malahal.
diff -r 2cd6b249e335 block/ll_rw_blk.c
--- a/b
If the aic94xx chip doesn't have a SAS address in the chip's flash memory,
make libsas get one for us. Also clean out some old code that had been
used to do this in the past.
Signed-off-by: Darrick J. Wong <[EMAIL PROTECTED]>
---
drivers/scsi/aic94xx/aic94xx.h | 16
driv
Use the request_firmware() interface to get a SAS address from userspace.
This way, there's no debate as to who or how an address gets generated;
it's up to the administrator to provide one if the driver can't find one
on its own.
Signed-off-by: Darrick J. Wong <[EMAIL PROTECTED]>
---
drivers/sc
On Mon, 08 Oct 2007, Darrick J. Wong wrote:
> On Mon, Oct 08, 2007 at 03:48:32PM -0700, Andrew Vasquez wrote:
>
> > So how about factoring that out to a transport-level interface. How
> > about something along the lines of the following patch, whereby the
> > software driver upon detecting no va
Thanks to acme's pahole utility, I found some places where we can save
a lot of bytes in scsi_cmnd, just by rearranging struct elements and
reducing the size of some elements. We go from 272 to 260 bytes on x86
and from 368 to 344 bytes on x86-64.
- eh_eflags had a 4-byte hole after it on 64-bi
On Mon, Oct 08, 2007 at 03:48:32PM -0700, Andrew Vasquez wrote:
> So how about factoring that out to a transport-level interface. How
> about something along the lines of the following patch, whereby the
> software driver upon detecting no valid WWPN, makes an upcall to each
> interface's 'reques
On Mon, 08 Oct 2007, Darrick J. Wong wrote:
> If the aic94xx chip doesn't have a SAS address in the chip's flash memory,
> use the request_firmware() interface to get one from userspace. This
> way, there's no debate as to who or how an address gets generated--it's
> totally up to the administrat
If the aic94xx chip doesn't have a SAS address in the chip's flash memory,
use the request_firmware() interface to get one from userspace. This
way, there's no debate as to who or how an address gets generated--it's
totally up to the administrator to provide it if the card doesn't have one.
Signe
Hi,
thanks to my stupidity I found out only last weekend that `scsiinfo -i` in
fact does create the fifo offset behaviour. However, `scsiinfo -a` as
stefan described does not (this is why I haven't tried `-i` up to now).
Well, the good news is that almost any other queries of scsiinfo instead
--- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> James Bottomley wrote:
> > If you remember Rusty's guide to interfaces, this is a level 14 easy to
> > misuse interface: "The obvious use is wrong"; since the obvious use is
> > to put it in module parameters and have the problem go away (for
> > now ...
--- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> James Bottomley wrote:
> > My problem with auto generated is that it's provably impossible to
> > generate globally unique numbers for WWNs without some internal source
> > of uniqueness (I know sparcs have this in their serial number, but most
> > PCs
--- James Bottomley <[EMAIL PROTECTED]> wrote:
>
> For the record, what the current in-kernel aic94xx driver does for this
> case is allow a parameter override to specify the WWN in the case where
> the card burned in one has gone missing or is corrupt. I think this is
> the correctly balanced ap
David Miller wrote:
> From: James Bottomley <[EMAIL PROTECTED]>
> Date: Sat, 06 Oct 2007 10:04:55 -0500
>
>> If you remember Rusty's guide to interfaces, this is a level 14 easy to
>> misuse interface: "The obvious use is wrong"; since the obvious use is
>> to put it in module parameters and hav
[sorry for sending twice, but after I read the sil sources, I see the mail
address had been wrong]
Hi,
somehow the sil3114 causes data corruption with some (newer?) disks. Simply
filling the filesystem with zeros and reading the these data will make the
kernel to report filesystem corruption.
- 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_cmnd(struct scsi_cmnd *scmd,
struct scsi_eh_save *sesci, u
- regrouped variables for easier reviewing of next patch
- Support of cmnd==NULL in call to scsi_send_eh_cmnd()
- In the @sense_bytes case set transfer size to the minimum
size of sense_buffer and passed @sense_bytes. cmnd[4] is
set accordingly.
- REQUEST_SENSE is set into cmnd[0]
I will send a ver4 of these patches as reply to base patches
Meanwhile I have some comments below.
Thanks for the review.
On Wed, Oct 03 2007 at 17:55 +0200, James Bottomley <[EMAIL PROTECTED]> wrote:
>
> You've altered the signature and function of the routine here, this
> needs to be documente
Hi,
somehow the sil3114 causes data corruption with some (newer?) disks. Simply
filling the filesystem with zeros and reading the these data will make the
kernel to report filesystem corruption.
This is definitely not an issue of memory, since the systems (several tested)
do have ECC memory an
On Wed, Oct 03 2007 at 3:55 +0200, Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> The narrow board used two global structures to set up a command;
> unfortunately they weren't locked, so with two boards in the machine,
> one call to queuecommand could corrupt the data being used by the other
> call to
On Sun, Oct 07 2007, [EMAIL PROTECTED] wrote:
> Jens Axboe [EMAIL PROTECTED] wrote:
> > On Thu, Oct 04 2007, [EMAIL PROTECTED] wrote:
> > > Mike Christie's patches refreshed to 2.6.23-rc8-mm1.
> > >
> > > Signed-off-by: Mike Christie <[EMAIL PROTECTED]>
> > > Signed-off-by: Malahal Naineni <[EMAIL
20 matches
Mail list logo
