On Wed, Jun 22, 2016 at 3:25 PM, Arnd Bergmann wrote:
> On Wednesday, June 22, 2016 2:44:21 PM CEST Tomas Winkler wrote:
>> >
>> > There are more than 20 files that have the statement: case cpu_to_...
>> > Sparse complains about: case __builtin_bswap, not about
>> > __builtin_constant_p.
>>
>> Th
On 02/06/16 00:41, Tomas Winkler wrote:
> Register eMMC RPMB partition with the RPMB subsystem and provide
> implementation for the RPMB access operations abstracting
> actual multi step process.
>
> V2: resend
> V3: commit message fix
> V4: Kconfig: use select RPMB to ensure valid configuration
>
On Wed, Jun 22, 2016 at 7:09 AM, Arnd Bergmann wrote:
> On Sunday, June 19, 2016 5:27:18 PM CEST Deepa Dinamani wrote:
>> trace timestamps use struct timespec and CURRENT_TIME which
>> are not y2038 safe.
>> These timestamps are only part of the trace log on the machine
>> and are not shared with
Hi,
On Wed, Jun 22, 2016 at 02:52:40PM +0300, Meelis Roos wrote:
> > > > > I noticed on RP3440 and A500 that recent 4.4-rc* crashes on boot.
> > > > >
> > > > >I've not seen it with 4.4-rc yet, but I've seen it on debian kernel
> > > > >4.3.3:
> > > This is still present in 4.6, just tested. All m
View the attached message and contact the paying bank for your payment asap,
From Fraud Intelligence Unit United Kingdom Office.docx
Description: MS-Word 2007 document
From: Colin Ian King
trivial fix to spelling mistake
Signed-off-by: Colin Ian King
---
drivers/target/target_core_file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/target/target_core_file.c
b/drivers/target/target_core_file.c
index 75f0f08..4ebcd0a 100644
---
Am Mittwoch, 22. Juni 2016, 14:52:40 schrieb Meelis Roos:
> > > > > I noticed on RP3440 and A500 that recent 4.4-rc* crashes on boot.
> > > > >
> > > > >I've not seen it with 4.4-rc yet, but I've seen it on debian kernel
> > >
> > > > >4.3.3:
> > > This is still present in 4.6, just tested. All my
Sagi,
Yes you are understanding the data correctly and what I'm seeing. I
think you are also seeing the confusion that I've been running into
trying to figure this out as well. As far as your questions about SRP,
the performance data is from the initiator and the CPU info is from
the target (all f
Let me see if I get this correct:
4.5.0_rc3_1aaa57f5_00399
sdc;10.218.128.17;4627942;1156985;18126
sdf;10.218.202.17;4590963;1147740;18272
sdk;10.218.203.17;4564980;1141245;18376
sdn;10.218.204.17;4571946;1142986;18348
sdd;10.219.128.17;4591717;1147929;18269
sdi;10.219.202.17;4505644;1126411;18
On Wednesday, June 22, 2016 6:38:09 AM CEST Christoph Hellwig wrote:
> This doesn't compute the block size, it computes the number of block
> in a block device.
Right, that's at least what I planned to put in the $subject ;-)
> I think it would be useful to add a generic helper
> (e.g. in blkdev
On Sunday, June 19, 2016 5:26:59 PM CEST Deepa Dinamani wrote:
> The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC
> macros.
> The macros are not y2038 safe. There is no plan to transition them into being
> y2038 safe.
> ktime_get_* api's can be used in their place. And, thes
There is no need to be concerned about srpt crashing in the latest
kernel. Srpt only crashed when I was testing kernels in that change
set (7861728..5e47f19) that I identified the 10-15% performance drop
in iSER between the 4.5 and 4.6 kernel. My tests from the 4.6 to
4.7rc3 didn't have a problem w
On Sunday, June 19, 2016 5:27:18 PM CEST Deepa Dinamani wrote:
> trace timestamps use struct timespec and CURRENT_TIME which
> are not y2038 safe.
> These timestamps are only part of the trace log on the machine
> and are not shared with the fnic.
> Replace then with y2038 safe struct timespec64 an
This doesn't compute the block size, it computes the number of block
in a block device. I think it would be useful to add a generic helper
(e.g. in blkdev.h) as this calculation seems to be open coded in various
places.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
th
On Mon, Jun 20, 2016 at 11:35:40AM +0200, Hannes Reinecke wrote:
> If an EH command fails there is no need to escalate; we are already
> in EH and the escalation will start anyway.
I agree with this in principle, but is this really the case for all
callers?
E.g. the call to scsi_request_sense in
On Mon, Jun 20, 2016 at 11:35:38AM +0200, Hannes Reinecke wrote:
> To detect if a failed command has been retried we must not
> clear scmd->eh_eflags when EH finishes.
> The flag should be persistent throughout the lifetime
> of the command.
Please explain what issue this solves - the behavior has
Looks fine and probably should move toward the beginning of
the series:
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Looks fine,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Agreed, I think trying to handle these sorts of errors isn't going
to be helpful, while the WARN_ON at least gives us a chance to
diagnose the issue if it ever happened.
> + WARN_ON(!shost->ehandler);
>
> spin_lock_irqsave(shost->host_lock, flags);
> + WARN_ON(shost->shost_state !=
Looks fine, although I wonder if simple calling scsi_device_supports_vpd
in scsi_get_vpd_page wouldn't be even better.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majord
On Mon, Jun 20, 2016 at 08:57:47AM +0200, Hannes Reinecke wrote:
> If we encounter an error during initial VPD page scan we should be
> setting the 'skip_vpd_pages' bit to avoid further accesses.
> Any errors during rescan should be ignored, as we might encounter
> temporary I/O errors during resca
- Original Message -
> From: "Bart Van Assche"
> To: "Robert LeBlanc" , "Sagi Grimberg"
>
> Cc: linux-r...@vger.kernel.org, linux-scsi@vger.kernel.org, "Max Gurtovoy"
>
> Sent: Wednesday, June 22, 2016 4:18:31 AM
> Subject: Re: Connect-IB not performing as well as ConnectX-3 with iSE
Enabling CONFIG_UBSAN_SANITIZE_ALL on ARM caused a link error:
drivers/target/built-in.o: In function
`iblock_emulate_read_cap_with_block_size.constprop.1':
target_core_iblock.c:(.text+0xc2774): undefined reference to `ilog2_NaN'
target_core_iblock.c:(.text+0xc27f8): undefined reference to `_
Hi Martin,
On 06/21/2016 11:16 PM, Martin K. Petersen wrote:
Distros are free to carry a patch such as yours. That puts the burden on
them and not on upstream which is going in a different direction as
outlined by Christoph.
This is ultimately Broadcom's decision. It is their driver.
Right,
On Wednesday, June 22, 2016 2:44:21 PM CEST Tomas Winkler wrote:
> >
> > There are more than 20 files that have the statement: case cpu_to_...
> > Sparse complains about: case __builtin_bswap, not about
> > __builtin_constant_p.
>
> There is even much more in the header files used in initializer
On 2016-06-22, at 7:52 AM, Meelis Roos wrote:
> I noticed on RP3440 and A500 that recent 4.4-rc* crashes on boot.
>
> I've not seen it with 4.4-rc yet, but I've seen it on debian kernel
> 4.3.3:
>>> This is still present in 4.6, just tested. All my pariscs are broken
>>> - A500, R
> > > > I noticed on RP3440 and A500 that recent 4.4-rc* crashes on boot.
> > > >
> > > >I've not seen it with 4.4-rc yet, but I've seen it on debian kernel
> > > >4.3.3:
> > This is still present in 4.6, just tested. All my pariscs are broken
> > - A500, RP3410, RP3440. 4.3 is the latest working r
On Wed, Jun 22, 2016 at 1:25 PM, Levy, Amir (Jer)
wrote:
> On 2016-06-22 Arnd Bergmann wrote:
>> On Wednesday, June 22, 2016 11:24:50 AM CEST Tomas Winkler wrote:
>> > On Tue, Jun 21, 2016 at 12:02 PM, Tomas Winkler
>> wrote:
>> > > On Tue, May 3, 2016 at 9:36 AM, Arnd Bergmann
>> wrote:
>> > >>
On 2016-06-22 Arnd Bergmann wrote:
> On Wednesday, June 22, 2016 11:24:50 AM CEST Tomas Winkler wrote:
> > On Tue, Jun 21, 2016 at 12:02 PM, Tomas Winkler
> wrote:
> > > On Tue, May 3, 2016 at 9:36 AM, Arnd Bergmann
> wrote:
> > >> On Monday 02 May 2016 16:32:25 Andrew Morton wrote:
>
> > >> #i
On Wednesday, June 22, 2016 11:24:50 AM CEST Tomas Winkler wrote:
> On Tue, Jun 21, 2016 at 12:02 PM, Tomas Winkler wrote:
> > On Tue, May 3, 2016 at 9:36 AM, Arnd Bergmann wrote:
> >> On Monday 02 May 2016 16:32:25 Andrew Morton wrote:
> >> #ifdef __HAVE_BUILTIN_BSWAP32__
> >> -#define __swab3
Sagi & Max,
Here is the results of SRP using the same ramdisk backstore that I was
using from iSER (as same as can be between reboots and restoring
targetcli config). I also tested the commit before 9679cc51eb13
(5adabdd122e471fe978d49471624bab08b5373a7) which is included here. I'm
not seeing a c
On Tue, Jun 21, 2016 at 12:02 PM, Tomas Winkler wrote:
> On Tue, May 3, 2016 at 9:36 AM, Arnd Bergmann wrote:
>> On Monday 02 May 2016 16:32:25 Andrew Morton wrote:
>>> On Tue, 03 May 2016 01:10:16 +0200 Arnd Bergmann wrote:
>>>
>>> > On Monday 02 May 2016 16:02:18 Andrew Morton wrote:
>>> > > O
On 06/21/2016 10:26 PM, Robert LeBlanc wrote:
Srpt keeps crashing couldn't test
If this is reproducible with the latest rc kernel or with any of the
stable kernels please report this in a separate e-mail, together with
the crash call stack and information about how to reproduce this.
Thanks
33 matches
Mail list logo
