Dan Williams | 1 Apr 01:58 2011
Picon

Re: [PATCH] isci: kill dead data structurs in scic_io_request.h

On Thu, Mar 31, 2011 at 8:01 AM, Christoph Hellwig <hch <at> infradead.org> wrote:
> Signed-off-by: Christoph Hellwig <hch <at> lst.de>

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Tejun Heo | 1 Apr 11:01 2011

Re: 2.6.39-rc1 problem

(cc linux-scsi)
Hello,

On Thu, Mar 31, 2011 at 11:35:23AM -0700, Andrew Morton wrote:
> (cc linux-ide)
> 
> On Wed, 30 Mar 2011 22:47:32 -0300 (GFT)
> werner <at> guyane.yi.org wrote:
> 
> > The mailing list is anyhow blocking my mails, I suppose it didnt
> > appear there, so I send my error report to you You can send it to
> > someone wich can correct these erros

Can you please provide more details on the circumstances?  When did
this happen and how reproducible is it?  Which controller is in use
(lspci -nn)?  Please also attach full output of dmesg including the
boot messages.

> > ==============================================
> > Mar 30 03:48:42 werner kernel: ------------[ cut here ]------------
> > Mar 30 03:48:42 werner kernel: WARNING: at drivers/ata/libata-core.c:5015 ata_qc_issue+0x1ba/0x33c()
> > Mar 30 03:48:42 werner kernel: Hardware name: System Product Name
> > Mar 30 03:48:42 werner kernel: Modules linked in: ipv6 snd_usb_audio snd_usbmidi_lib snd_rawmidi
snd_seq_device rt2860sta(C) uvcvideo lp snd_hda_codec_realtek tpm_tis tpm tpm_bios rtc_cmos
rtc_core rtc_lib asus_atk0110 snd_hda_intel 8139too snd_hda_codec snd_hwdep snd_pcm snd_timer
k8temp atl1 snd soundcore snd_page_alloc i2c_nforce2
> > Mar 30 03:48:42 werner kernel: Pid: 0, comm: swapper Tainted: G         C  2.6.39-rc1 #1
> 
> I assume that 2.6.38 was OK and that this is a post-2.6.38 regression?
> 
(Continue reading)

Desai, Kashyap | 1 Apr 14:46 2011

RE: [PATCH] mpt2sas : WarpDrive New product SSS6200 support added

James,

Can I have your feedback for this particular patch?

~ Kashyap

> -----Original Message-----
> From: Desai, Kashyap
> Sent: Thursday, March 10, 2011 6:42 PM
> To: linux-scsi <at> vger.kernel.org
> Cc: James.Bottomley <at> HansenPartnership.com; Moore, Eric; Prakash, Sathya
> Subject: RE: [PATCH] mpt2sas : WarpDrive New product SSS6200 support
> added
>
> James,
> Any feedback on this patch submission?  I observe that this patch is
> not following relative depth.
> It has "mpt2sas-phase8.0_wd/mpt2sas_base.c" path, so need to apply
> using -p1 instead of -p4.
>
> Is there any need to resend patch with correct relative depth? Please
> let me know I will resend in that case.
>
> ~ Kashyap
>
>
>
>
> > -----Original Message-----
> > From: linux-scsi-owner <at> vger.kernel.org [mailto:linux-scsi-
(Continue reading)

Christoph Hellwig | 1 Apr 15:11 2011

Re: [PATCH 2/2] isci: remove base_request abstraction

On Thu, Mar 31, 2011 at 03:14:14PM -0700, Dan Williams wrote:
> We'll want to do a tree-wide s/sci_base_/sci_/, but maybe not until we
> settle on the final unified object names... put it off for now.

I don't think much of the sci_base names will be left, basically just
the core state machine helpers.

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Julia Lawall | 1 Apr 16:23 2011
Picon

[PATCH 5/6] drivers/scsi/bnx2fc/bnx2fc_hwi.c: introduce missing kfree

Error handling code following a kmalloc should free the allocated data.

The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
 <at> r exists <at> 
local idexpression x;
statement S;
expression E;
identifier f,f1,l;
position p1,p2;
expression *ptr != NULL;
 <at>  <at> 

x <at> p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
     when != if (...) { <+...x...+> }
(
x->f1 = E
|
 (x->f1 == NULL || ...)
|
 f(...,x->f1,...)
)
...>
(
 return \(0\|<+...x...+>\|ptr\);
(Continue reading)

Ted Ts'o | 1 Apr 17:19 2011
Picon
Picon

Re: [Lsf] Preliminary Agenda and Activities for LSF

On Wed, Mar 30, 2011 at 07:28:34AM -0400, Ric Wheeler wrote:
> 
> What possible semantics could you have?
> 
> If you ever write concurrently from multiple processes without
> locking, you clearly are at the mercy of the scheduler and the
> underlying storage which could fragment a single write into multiple
> IO's sent to the backend device.
> 
> I would agree with Dave, let's not make it overly complicated or try
> to give people "atomic" unbounded size writes just because they set
> the O_DIRECT flag :)

I just want to have it written down.  After getting burned with ext3's
semantics promising more than what the standard guaranteed, I've just
gotten paranoid about application programmers getting upset when
things change on them --- and in the case of direct I/O, this stuff
isn't even clearly documented anywhere official.

I just think it's best that we document it the fact that concurrent
DIO's to the same region may result in completely arbitrary behaviour,
make sure it's well publicized to likely users (and I'm more worried
about the open source code bases than Oracle DB), and then call it a day.

The closest place that we have to any official documentation about
O_DIRECT semantics is the open(2) man page in the Linux manpages, and
it doesn't say anything about this.  It does give a recommendation
against not mixing buffered and O_DIRECT accesses to the same file,
but it does promise that things will work in that case.  (Even if it
does, do we really want to make the promise that it will always work?)
(Continue reading)

Tejun Heo | 1 Apr 17:43 2011

Re: [PATCH] sr: Ensure disk is revalidated when media changes

Hello,

On Thu, Mar 31, 2011 at 11:50:04PM +0530, Amit Shah wrote:
> After the first GET_EVENT_STATUS_NOTIFICATION command, any new media
> notification is reset by the device.  The following is then noticed:
> 
> 1. insert a CD of a particular size
> 2. mount it
> 3. note /sys/block/sr0/size
> 4. unmount cd
> 5. replace cd with a size greater than previous one
> 6. mount it
> 7. /sys/block/sr0/size isn't updated
> 8. copy all files from cd to somewhere; IO errors will pop up where the
>    files lie beyond previous CD's geometry
> 
> The cause is:
> 
>  cdrom_open()
>      open_for_data()
>          cdo->drive_status() = sr_drive_status()
>              cdrom_get_media_event()
>              --> GPCMD_GET_EVENT_STATUS_NOTIFICATION
>          --> med.media_present is true, return CDS_DISK_OK
>      (success)
>  check_disk_change()
>     ... -> 2nd call to GPCMD_GET_EVENT_STATUS_NOTIFICATION
> 
> at this point the device has already reset the new media event and the
> call to revalidate_disk() in check_disk_change() is never made.
(Continue reading)

Amir Goldstein | 1 Apr 18:30 2011
Picon

Re: [Lsf] Preliminary Agenda and Activities for LSF

On Fri, Apr 1, 2011 at 8:19 AM, Ted Ts'o <tytso <at> mit.edu> wrote:
> On Wed, Mar 30, 2011 at 07:28:34AM -0400, Ric Wheeler wrote:
>>
>> What possible semantics could you have?
>>
>> If you ever write concurrently from multiple processes without
>> locking, you clearly are at the mercy of the scheduler and the
>> underlying storage which could fragment a single write into multiple
>> IO's sent to the backend device.
>>
>> I would agree with Dave, let's not make it overly complicated or try
>> to give people "atomic" unbounded size writes just because they set
>> the O_DIRECT flag :)
>
> I just want to have it written down.  After getting burned with ext3's
> semantics promising more than what the standard guaranteed, I've just
> gotten paranoid about application programmers getting upset when
> things change on them --- and in the case of direct I/O, this stuff
> isn't even clearly documented anywhere official.
>
> I just think it's best that we document it the fact that concurrent
> DIO's to the same region may result in completely arbitrary behaviour,
> make sure it's well publicized to likely users (and I'm more worried
> about the open source code bases than Oracle DB), and then call it a day.
>
> The closest place that we have to any official documentation about
> O_DIRECT semantics is the open(2) man page in the Linux manpages, and
> it doesn't say anything about this.  It does give a recommendation
> against not mixing buffered and O_DIRECT accesses to the same file,
> but it does promise that things will work in that case.  (Even if it
(Continue reading)

Tomas Henzl | 1 Apr 18:31 2011
Picon

Re: [PATCH 5/14] megaraid_sas: Fix probe_one to clear MSI-X flags in kdump

On 03/31/2011 08:50 PM, adam radford wrote:
> On Wed, Mar 30, 2011 at 5:30 AM, Tomas Henzl <thenzl <at> redhat.com> wrote:
>
>   
>> Hi Adam,
>> sorry I'm late, but this is still not applied I think.
>>     
> Yes, it is here:
>
> http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commit;h=66192dfe1e74eae31a76cfc36092dabdba1324e6
>
>   
>> The above #define are already defined in msi.h and pci_regs.h
>> I'd prefer to include those files instead of define the values.
>>
>>     
> msi_control_reg() macro is defined in drivers/pci/msi.h _not_
> include/linux/msi.h.
>
> Are you suggesting I try to include drivers/pci/msi.h ?
>   
That doesn't look that good, probably better would be to put the definition
to some other place. The patch is already accepted and the priority for me low...

The PCI_MSIX_FLAGS_ENABLE is defined in pci_regs.h this is included in linux/pci.h and this is included 
in megaraid_sas_base.c - I think the definition could be simply removed from your patch, isn't it so?
Again this is low priority I expect no immediate action from you :)

Tomas

(Continue reading)

Giridhar Malavali | 1 Apr 21:57 2011

[LSF]: fc_rport attributes to further populate HBAAPIv2

James,

I would also like to discuss the following topic.

The patches were submitted to linux-scsi earlier which basically includes
fc_rport attributes to FC transport.
Here are the links to previous submission

http://marc.info/?l=linux-scsi&m=128828294426031&w=2
http://marc.info/?l=linux-scsi&m=128828255825328&w=2
http://marc.info/?l=linux-scsi&m=128828263025468&w=2

From review comments from community (Christof S and James Smart), it is
felt that a common implementation either in transport or block layer would
be better to avoid all LLD implementing this. In an effort the BSG
interface is extended to send in-kernel BSG commands to query name server
and get the required information to populate.

Here are the links for the review comments received

http://marc.info/?l=linux-scsi&m=128834912816011&w=2
http://marc.info/?l=linux-scsi&m=128838095128776&w=2
http://marc.info/?l=linux-scsi&m=128871208700376&w=2

I would like to discuss to tap more idea from community for any better
approach. If not, to continue with the present approach.

Thanks,
Giridhar Malavali

(Continue reading)


Gmane