FROM DAVID BRYAN THE MANAGING DIRECTOR OF ECOBANK call me +233546972482 or +2349035653866,
My name is David Bryan . I am the managing director of All Ecobank international PLC Ghana Accra . i want to inform you that the a little boy lucky holton came to the bank and deposit 7.5 million dollars in the bank and your Email ID is attached to it as the beneficiary of the fund and it has kept long and we have not heard from him that is why i am consulting you to transfer the fund to you. So Please kindly bring your bank information to enable me to transfer the money to you Your Full name Your bank account your Profession and your Telephone number so that i can transfer the money to you by online account or ATM Card. you can contact me here by this (ecobankonlinetransferw...@gmail.com) THANK YOU YOURS FROM DAVID BRYAN THE MANAGING DIRECTOR OF ECOBANK call me +233546972482 -- 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
Re: Debugging scsi abort handling ?
Hi, On 08/23/2014 05:42 PM, Douglas Gilbert wrote: On 14-08-23 10:52 AM, Hans de Goede wrote: Hi All, Now that the UAS driver is no longer marked as CONFIG_BROKEN, I'm getting quite a few bug reports about issues with UAS drives. One if the issues is that there might be a number of bugs in the abort handling path, as I don't think that was ever tested properly. So I'm wondering is there a way to test the abort path with a real drive? E.G. submit some command which is known to take a significant amount of time, and then abort it right after submitting ? Hi, You might experiment with starting a streaming read from one shell (e.g. with dd or ddpt) and while that is underway, from another shell issue a 'sg_reset --device' and see what happens. If nothing then try 'sg_reset --target'. Aborting a single, long duration command from the user space (and only that command, assuming other processes might be using that disk) is not easy to do. Thanks, I'll give sg_reset a try. Regards, Hans -- 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
Re: Debugging scsi abort handling ?
Hi, On 08/23/2014 11:05 PM, James Bottomley wrote: On Sat, 2014-08-23 at 16:52 +0200, Hans de Goede wrote: Hi All, Now that the UAS driver is no longer marked as CONFIG_BROKEN, I'm getting quite a few bug reports about issues with UAS drives. One if the issues is that there might be a number of bugs in the abort handling path, as I don't think that was ever tested properly. Can you report the actual bugs and we'll try to take a look at them? To be clear I believe there may be a bug or 2 in the uas.c abort code paths, not in the scsi core or sd drivers. But getting more eyes on these definitely makes sense. Should I CC linux-scsi@vger on issues like this, or should I get the users to file a bug at bugzilla.kernel.org (my own preference would be to do the latter, as that keeps all info in a single place). So I'm wondering is there a way to test the abort path with a real drive? E.G. submit some command which is known to take a significant amount of time, and then abort it right after submitting ? This scenario can't really happen under the current eh, if by abort path, you mean the path where we abort the command by sending an abort TMF in error handling. Yes that is the one I mean, some users of uas are seeing the 30 second timeout kick in, and then most of the times the uas abort code does not seem to actually abort, and a device reset is needed to resolve things. This could mean 1 of 2 things: 1) the abort code in uas.c is no good 2) the device has actually locked up / crashed Sometimes though the uas abort code does not just timeout on the abort, and instead seems to go down in flames (kernel page fault), which seems to indicate that even if 2 is the case here, that we still have an issue in the uas abort code. The reason is that the command must timeout before we abort. If you mean the path where the driver says it aborted the command and we have to retry, you can test that by returning DID_ABORT immediately in the queuecommand routine ... I use this to test some of the EH properties. What you want to do is to modify the queuecommand to return abort on a small number of commands (say around 5%) and then try normal operation. This is what I used to test our submission and resubmission routines, but I haven't run it for a year or so. The final suggestion is that you need to make sure this patch is in their environment: commit c69e6f812bab0d5442b40e2f1bfbca48d40bc50b Author: James Bottomley jbottom...@parallels.com Date: Thu Apr 10 13:36:11 2014 -0700 [SCSI] More USB deadlock fixes The reason this may make a difference is that USB appears fragile to issuing commands before you complete a reset. uas is only enabled in 3.15 and newer so that patch should be present. Regards, Hans -- 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
RE: [PATCH v3] scsi: ufs-msm: add UFS controller support for Qualcomm MSM chips
Thanks Dan, Your quick glance did spotted a good catch. This variable if un-necessary, A new version will be uploaded soon Thanks, Yaniv -Original Message- From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-ow...@vger.kernel.org] On Behalf Of Dan Aloni Sent: Saturday, August 16, 2014 8:33 PM To: Yaniv Gardi Cc: james.bottom...@hansenpartnership.com; h...@infradead.org; linux-ker...@vger.kernel.org; linux-scsi@vger.kernel.org; linux-arm-...@vger.kernel.org; santos...@gmail.com; linux-scsi-ow...@vger.kernel.org; subha...@codeaurora.org; n...@codeaurora.org; dra...@codeaurora.org; Rob Herring; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala; Vinayak Holikatti; James E.J. Bottomley; Grant Likely; Sujit Reddy Thumma; Sahitya Tummala; open list:OPEN FIRMWARE AND... Subject: Re: [PATCH v3] scsi: ufs-msm: add UFS controller support for Qualcomm MSM chips On Thu, Aug 14, 2014 at 05:22:18PM +0300, Yaniv Gardi wrote: diff --git a/drivers/scsi/ufs/ufs-msm.h b/drivers/scsi/ufs/ufs-msm.h new file mode 100644 index 000..6e93f1e --- /dev/null +++ b/drivers/scsi/ufs/ufs-msm.h @@ -0,0 +1,158 @@ [...] +}; + +static LIST_HEAD(phy_list); + Just noticed this via a quick glance - Seems that this variable is not referenced by any of the compilation units, what's the purpose of it? And as a static global in a shared private, each of the including compilation units gets a copy, which I am not sure was intended anyway. -- Dan Aloni -- 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 -- 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
Re: [PATCH v1 0/8][SCSI] mpt3sas: Phase2 and Phase3 mpt3sas driver patch set
On Sat, Aug 23, 2014 at 05:41:34PM +0530, Sreekanth Reddy wrote: Just resending the complete Phase2 and Phase3 mpt3sas driver patch set Reviewed by the Martin K. Petersen. This will make easy for Christoph to pick up this patch set for next kernel release. Can you please also send me the equivalent mpt2 patches? I don't want these drivers to get out of sync. Thanks! -- 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
Re: [Bug 80711] [PATCH]SG_FLAG_LUN_INHIBIT is no longer implemented and there's not way to prevent the kernel from using the 2nd cdb byte for the LUN
On Fri, Aug 22, 2014 at 01:29:32PM -0400, Alan Stern wrote: Other than this, I'm fine with the code ... you can add the acked by from me when we resolve the above question. Okay. It's true that this issue is only tangentially related to the main point of the patch. It could be removed and addressed later. Just make it a separate patch and send it along.. -- 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
Re: [PATCH 0/2] qla2xxx: Miscellaneous fixes
On Fri, Aug 08, 2014 at 07:38:07AM -0400, Chad Dupuis wrote: Hi James, Christoph, Pleas apply the following two patches at your earliest convenience. Thanks, I've applied them to the drivers-for-3.18 branch (actually already a few days ago, so they are in Linux-next already) -- 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
Re: [PATCH] drivers: scsi: #define missing include guards
On Fri, Aug 22, 2014 at 02:37:33PM +0200, Rasmus Villemoes wrote: The four files aha1542.h, aha1740.h, gvp11.h and mvme147.h under drivers/scsi/ contain two-thirds of an include guard, but do not elsewhere. Signed-off-by: Rasmus Villemoes li...@rasmusvillemoes.dk Looks reasonable to me, can I get a quick review for it? -- 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
Re: [RESEND][PATCH 07/10] [SCSI] mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support
Can you please send me a single big series with all the mpt2 and mpt3 updates? With all the resends I'm losing track. Please also pick up third party mpt patches like '[PATCH 3/3] mpt3sas, mpt2sas: fix scsi_add_host error handling problems in _scsih_probe' from Robert Elliott. And while I can't enforce it on you git send-email really is your friend for that. -- 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
Re: [RFC 09/10] sd: Avoid sending medium write commands if device is write protected
Thanks, applied. -- 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
Re: Performance degradation in IO writes vs. reads (was scsi-mq V2)
On 8/21/2014 5:02 PM, Sagi Grimberg wrote: On 8/21/2014 4:03 PM, Christoph Hellwig wrote: On Thu, Aug 21, 2014 at 03:32:09PM +0300, Sagi Grimberg wrote: So I just got back to checking this issue of *extremely low* IO write performance I got in 3.16-rc2. Please test with 3.16 final. There once issue each in aio and dio that caused bad I/O performance regression that were only fixed last minute in the 3.16 cycle. I'll do that now. Indeed this issue is resolved in 3.16. Sorry for the false alarm... Thanks Christoph. Sagi. -- 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
Re: [PATCH v3 00/13] scsi: Use pci_enable_msix_range() instead of pci_enable_msix()
I've applied all other patches except for the lpfc one now. Thanks again! -- 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
scsi logging future directions, was Re: [RFC PATCH -logging 00/10] scsi/constants: Output continuous error messages on trace
On Fri, Aug 22, 2014 at 12:39:59AM +, Elliott, Robert (Server Storage) wrote: If you trigger hundreds of errors (e.g., hot remove a device during heavy IO), then all the prints to the linux serial console bog down the system, causing timeouts in commands to other devices and soft lockups for applications. Some changes that would help are: 1. Put them under SCSI logging level control 2. Use printk_ratelimited so an excessive number are trimmed Would you like to include something like this in your patch set? I think we should come to an agreement where we want to go with scsi logging first before doing various smaller adjustments. (Although your example is one that's urgent enough that I'd like to put it in ASAP, I had issues with it a few times). I had a chat with Martin at Linuxcon about these issues, and we were both in favor of getting rid of the old scsi logging mechansisms and instead replace it by an extended version of the scsi tracepoints that cover all places, and dump all data from the old logging mechanism that people find useful. In a few places we'd still want to log normal dev_printk style errors, and the I/O completion is one of them, even if they really need to be ratelimited and condensed. If someone has arguments in favour of keeping the old logging code I'd love to hear them, but in practive the traceevent code has huge benefits: - almost zero overhead if disabled - can easily be used without any tools through configs, but can be used even better with tools like trace-cmd or perf - allows both fine and coarse grained selections of events to trace - allows to capture statistics on each trace point without event enabling the output - doesn't have any of the console lockup problems. -- 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
Re: [PATCH/RFC V2 07/16] scsi: support well known logical units
On Fri, Aug 22, 2014 at 12:02:30AM -, subha...@codeaurora.org wrote: + /* + * put runtime pm reference for well-known logical units, + * drivers are expected to _get_* again during probe. + */ + if (scsi_is_wlun(sdev-lun)) + scsi_autopm_put_device(sdev); Special casing the well known LUNs here seems wrong. Shouldn't we do this for any devices that don't get a driver attached to them? Agreed, i will replace if (scsi_is_wlun(sdev-lun)) check with if (sdev-sdev_gendev.driver). I would really prefer the callers of autopm get/put to be symmetric to issues with later than probe driver attach or similar. Think of the case say the CDROM or tape driver only gets loaded after we already did a bus scan. A quick check of the autopm code and it's underlying implementation seems to suggest that nesting them is okay. If that's indeed the case I would suggest to restructure it the following way: - make the scsi_autopm_put_device call you add at the end of scsi_sysfs_add_sdev unconditional to make it balance out the get earlier in the function (and delete the now incorrect comment above the scsi_autopm_get_device call). - let drivers do paired get/put calls in their probe/remove methods. If you still need any wlun changes after that please send them as a separate patch with a detailed description on why you need it. All in all the autopm code and it's underlying implementation is highly confusing, so additional documentation on it would also be very welcome. -- 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
Re: Logging of all scsi commands to a certain target?
On Sat, Aug 23, 2014 at 04:54:55PM +0200, Hans de Goede wrote: Hi, Now that the UAS driver is no longer marked as CONFIG_BROKEN, I'm getting quite a few bug reports about issues with UAS drives. Some of these seem to be related to the scsi core and/or the sd driver sending a command the device does not like. As such I'm wondering if there us a way to get the kernel to log each scsi command ? Or at least is there a helper function to log scsi commands which I can add to the uas driver (under a verbose option) to allow this ? Enable the scsi_dispatch_cmd_start tracepoint using trace-cmd or debugfs, and filter using host_no/channel/id/lun for your specific device. See Documentation/trace/events.txt for details on setting up filters. -- 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
Re: Debugging scsi abort handling ?
On Sun, Aug 24, 2014 at 10:46:57AM +0200, Hans de Goede wrote: To be clear I believe there may be a bug or 2 in the uas.c abort code paths, not in the scsi core or sd drivers. But getting more eyes on these definitely makes sense. Should I CC linux-scsi@vger on issues like this, or should I get the users to file a bug at bugzilla.kernel.org (my own preference would be to do the latter, as that keeps all info in a single place). Please Cc linux-scsi. I and some others definitively don't have the pain and patience to deal with bugzilla. uas is only enabled in 3.15 and newer so that patch should be present. There have been a few more important fixes since 3.15: ac61d19559349e205dad7b5122b281419aa74a82 scsi: set correct completion code in scsi_send_eh_cmnd() 8922a908908ff947f1f211e07e2e97f1169ad3cb scsi_error: fix invalid setting of host byte a33c070bced8b283e22e8dbae35177a033b810bf scsi_error: set DID_TIME_OUT correctly make sure you have those as well. -- 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
Epäilyttävää toimintaa: Sähköposti
Epäilyttävää toimintaa: Sähköposti Olet saanut tämän sähköpostiviestin: koska järjestelmämme on huomannut joitakin epäilyttävää toimintaa Webmail tunnus. Kaikki mitä sinun pitää nauttia kaikista Welmail palvelu oman id on vahvistaa henkilöllisyytesi, seuraa linkkiä Alla aloittamaan tämän prosessin. Klikkaa tästä nyt: http://mbnett.jigsy.com/ Sähköposti insinööri. -- 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
Re: [PATCH/RFC V2 07/16] scsi: support well known logical units
On Fri, Aug 22, 2014 at 12:02:30AM -, subha...@codeaurora.org wrote: + /* + * put runtime pm reference for well-known logical units, + * drivers are expected to _get_* again during probe. + */ + if (scsi_is_wlun(sdev-lun)) + scsi_autopm_put_device(sdev); Special casing the well known LUNs here seems wrong. Shouldn't we do this for any devices that don't get a driver attached to them? Agreed, i will replace if (scsi_is_wlun(sdev-lun)) check with if (sdev-sdev_gendev.driver). I would really prefer the callers of autopm get/put to be symmetric to issues with later than probe driver attach or similar. Think of the case say the CDROM or tape driver only gets loaded after we already did a bus scan. A quick check of the autopm code and it's underlying implementation seems to suggest that nesting them is okay. If that's indeed the case I would suggest to restructure it the following way: - make the scsi_autopm_put_device call you add at the end of scsi_sysfs_add_sdev unconditional to make it balance out the get earlier in the function (and delete the now incorrect comment above the scsi_autopm_get_device call). - let drivers do paired get/put calls in their probe/remove methods. If you still need any wlun changes after that please send them as a separate patch with a detailed description on why you need it. Thanks, yes I was also thinking on same lines but was not sure if it would work or not. But let me check this more and if it works, will make a different patch for it. All in all the autopm code and it's underlying implementation is highly confusing, so additional documentation on it would also be very welcome. I would agree but not sure if I would be able to add it now, hopefully some time in future. -- 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 -- 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
