sleep_on is known broken and going away. The atari_scsi driver is one of
two remaining users in the falcon_get_lock() function, which is a rather
crazy piece of code. This does not attempt to fix the driver's locking
scheme in general, but at least prevents falcon_get_lock from going to
sleep when
In case a SCSI command is queued from softirq context, and another
driver currently holds the ST-DMA lock, tell the SCSI midlevel to
hold off queueing commands for now. Midlevel will resume play later.
Signed-off-by: Michael Schmitz
Cc: Geert Uytterhoeven
Cc: James E.J. Bottomley
Cc: linux-scsi
All,
please review the following patches to the m68k Atari NCR5380 SCSI code.
The first patch is my corrected version of Arnd Bergmann's sleep_on removal RFC
series (2/16), tested on my Atari Falcon. Geert, please take this one through
the
linux-m68k tree so Arnd's sleep_on remove can go ah
The abort/reset lowlevel return codes had changed with the new
error SCSI handling - update Atari NCR5380 driver to reflect this.
Change reset handling to clear queues only, do not attempt to
call done() on each command aborted by the reset. The EH code
should do that for us.
Queues _must_ be clea
Hello Arnd,
On Thursday 27 February 2014, Michael Schmitz wrote:
Arnd Bergmann wrote:
Nack - the completion condition in the first hunk has its logic
reversed. Try this instead (while() loops while condition true, do {}
until () loops while condition false, no?)
Sorry
Attention: Please, Kindly contact KENYA COMMERCIAL BANK immediately for your
compensation payment of (3MILLION UNITED STATE DOLLARS) via email:
Email:(servic...@kenya.ncommercialbnk.com) quote your payment Ref
No:KCB/00Y/2014 For purposes of immediate payment.
--
To unsubscribe from this li
On Fri, 2014-02-28 at 16:14 +0100, Hannes Reinecke wrote:
> On 02/28/2014 02:58 AM, Mike Christie wrote:
> > On 02/27/2014 06:14 PM, Stewart, Sean wrote:
> >> This allows the sd driver to retry commands like read capacity until a
> >> LUN is ready, rather than giving up after three retries.
> >>
>
https://bugzilla.kernel.org/show_bug.cgi?id=71231
Saurav Kashyap changed:
What|Removed |Added
CC||saurav.kash...@qlogic.com
--- Comment #6
On Thu, Feb 13, 2014 at 11:07:11AM +0100, Hannes Reinecke wrote:
> EVPD page 0x83 is used to uniquely identify the device.
> So instead of having each and every program issue a separate
> SG_IO call to retrieve this information it does make far more
> sense to display it in sysfs.
This just shows
https://bugzilla.kernel.org/show_bug.cgi?id=71231
--- Comment #5 from Alex ---
This bug can be "easily" reproduced by havin two machines with one fibre
channel card each.
Install scst on one machine (as target) and conenct the other one to this one
(via two cables).
Than add 20 LUNs and open them
From: "Ewan D. Milne"
Move up the logging of messages and generation of uevents
for certain sense codes before checking for TEST UNIT READY
commands not generated by the mid-layer, so they won't be
silently discarded.
Signed-off-by: Ewan D. Milne
---
drivers/scsi/scsi_error.c | 4 ++--
1 file
On 02/28/2014 02:58 AM, Mike Christie wrote:
> On 02/27/2014 06:14 PM, Stewart, Sean wrote:
>> This allows the sd driver to retry commands like read capacity until a
>> LUN is ready, rather than giving up after three retries.
>>
>> In NetApp E-Series, a controller can return not ready like this whe
Some, almost not used variables removed.
Cc: Sumit Saxena
Cc: Adam Radford
Signed-off-by: Tomas Henzl
---
drivers/scsi/megaraid/megaraid_sas_base.c | 53 +++
1 file changed, 11 insertions(+), 42 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b
Hi all,
I have posted almost the same fix back 2011
http://www.spinics.net/lists/linux-scsi/msg50624.html
now it looks like someone was really hit by the hw read race.
This patch is split into two part - the first patch fixes the actual race,
the second is a bonus, it just removes some almost unu
When the driver reads state values from the hw it might happen that
different values are read in subsequent reads and this can cause problems,
this may lead to a timeout in this function and a non working adapter.
Cc: Sumit Saxena
Cc: Adam Radford
Signed-off-by: Tomas Henzl
---
drivers/scsi/me
https://bugzilla.kernel.org/show_bug.cgi?id=71231
--- Comment #4 from Alex ---
Kernel 3.13.1 is fine too.
--
You are receiving this mail because:
You are the assignee for the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger
https://bugzilla.kernel.org/show_bug.cgi?id=71231
--- Comment #3 from Alex ---
Kernel 3.8.13 is working fine
Kernel 3.9.11 is working fine
Kernel 3.12.13 has the bug too
Kernel 3.13.5 is working fine again.
So what has changed in 3.13? It would be nice to have it fixed for the longterm
kernel ve
Am 26.02.2014 12:01, schrieb Arnd Bergmann:
> It's been a while since the first submission of these patches,
> but a lot of them have made it into linux-next already, so here
> is the stuff that is not merged yet, hopefully addressing all
> the comments.
>
> Geert and Michael: the I was expecting
18 matches
Mail list logo