On 08/17/2017 03:25 PM, Tejun Heo wrote:
> Hello,
>
> On Thu, Aug 17, 2017 at 03:18:06PM +0200, Bernd Schubert wrote:
>> So for Gionatan the root cause was an instable power supply, but in my
>> case there wasn't any power loss, there were just failed sata comm
Hello Tejun,
On 08/17/2017 02:48 PM, Tejun Heo wrote:
> Hello,
>
> On Thu, Aug 17, 2017 at 11:24:22AM +0200, Bernd Schubert wrote:
>>> More concerning is the fact that these undetected errors can make their
>>> way even when the higher application consistently ca
[This seems to be libata error handling and not scsi, so I added more CCs]
On 08/17/2017 12:27 AM, Gionatan Danti wrote:
> Hi list,
> some time ago, I had a filesystem corruption on a simple, two disks
> RAID1 MD array. On the affected machine, /var/log/messages shown some
> "failed command:
The second patch tweaks the SCSI disk driver to prefer WRITE SAME w/
UNMAP instead of the UNMAP command since the former has deterministic
behavior.
I have seen data corruption on an Intel SSD 510 after sending WRITE SAME
UNMAP. As far as I remember, these disks ignore writes after sending
On 02/12/2014 03:27 AM, Kurt Miller wrote:
I can report that the Samsung 840 Pro*does* support trim on the LSI
SAS2008. As suspected it supports deterministic read zeros after trim.
One other thing to note, in my testing the P16 LSI firmware has broken
trim support. P14 and P15 report
u8 scsi_io_cb_idx;
diff --git a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
index 7f0af4f..d502728 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
@@ -127,6 +127,11 @@ static int disable_discovery =
Hello Joseph,
On 10/29/2013 08:21 PM, Joseph Salisbury wrote:
Hi Martin,
A bug was opened against the Ubuntu kernel[0]. After a kernel bisect,
it was found that reverting the following commit resolved this bug:
commit 66c28f97120e8a621afd5aa7a31c4b85c547d33d
Author: Martin K. Petersen
On 09/26/2013 07:39 AM, Douglas Gilbert wrote:
On 13-09-25 08:44 PM, Martin K. Petersen wrote:
Bernd == Bernd Schubert bernd.schub...@fastmail.fm writes:
Hey Bernd,
Bernd I'm afraid we have another problem. I'm currently working on to
Bernd get discard working for our LSI2008 HBAs
On 09/26/2013 04:42 PM, Martin K. Petersen wrote:
Bernd == Bernd Schubert bernd.schub...@fastmail.fm writes:
Bernd,
Bernd Both types of systems we have in-house neither block limits vpd
Bernd nor READ_CAP16 return anything that would indicate discard is
Bernd supported. But UNMAP and WRITE
On 09/24/2013 02:35 PM, KY Srinivasan wrote:
-Original Message-
From: Jack Wang [mailto:xjtu...@gmail.com]
Sent: Tuesday, September 24, 2013 5:08 AM
To: KY Srinivasan
Cc: Greg KH; linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
oher...@suse.com; jbottom...@parallels.com;
From: Bernd Schubert bernd.schub...@itwm.fraunhofer.de
Somehow older areca firmware versions have issues with
scsi_get_vpd_page() and a large buffer, the firmware
seems to crash and the scsi error-handler will start endless
recovery retries.
Limiting the buf-size to 64-bytes fixes this issue
James Bottomley jbottom...@parallels.com wrote:
[cc to linux-scsi added]
On Sun, 2013-09-22 at 16:27 +0200, Christian Bahls - gmail.com wrote:
Dear all,
Looks like i have been bitten by the above mentioned commit.
Just from a practical point of view, I only really work upstream, so
this
On 08/31/2013 09:48 PM, Nix wrote:
On 31 Aug 2013, Greg KH said:
On Fri, Aug 30, 2013 at 11:01:56AM +0100, Nix wrote:
On 1 Aug 2013, Bernd Schubert said:
Once I noticed that scsi_get_vpd_page() works fine from other function
calls and that it is not 0x89, but already 0x0 that fails fixing
Martin,
sorry for my late reply, I entirely lost track of this (customer issues,
vacation, lots of main work, ...).
On 08/02/2013 05:00 AM, Martin K. Petersen wrote:
Bernd == Bernd Schubert bernd.schub...@fastmail.fm writes:
Bernd,
Bernd Once I noticed that scsi_get_vpd_page() works fine
Once I noticed that scsi_get_vpd_page() works fine from other function
calls and that it is not 0x89, but already 0x0 that fails fixing it became
easy.
Nix, any chance you could verify it also works for you?
From: Bernd Schubert bernd.schub...@itwm.fraunhofer.de
Somehow older areca firmware
Whoops, the title is wrong, it should have been:
[PATCH] scsi disk: Limit get_vpd_page buf size
On 08/01/2013 04:34 PM, Bernd Schubert wrote:
Once I noticed that scsi_get_vpd_page() works fine from other function
calls and that it is not 0x89, but already 0x0 that fails fixing it became
easy
On 07/30/2013 11:20 PM, Nix wrote:
On 30 Jul 2013, Bernd Schubert told this:
On 07/30/2013 02:56 AM, Nix wrote:
On 30 Jul 2013, Douglas Gilbert outgrape:
Please supply the information that Martin Petersen asked
for.
Did it in private IRC (the advantage of working for the same division
On 08/01/2013 06:04 PM, Nix wrote:
On 1 Aug 2013, Bernd Schubert verbalised:
On 07/30/2013 11:20 PM, Nix wrote:
On 30 Jul 2013, Bernd Schubert told this:
On 07/30/2013 02:56 AM, Nix wrote:
On 30 Jul 2013, Douglas Gilbert outgrape:
Please supply the information that Martin Petersen asked
On 07/31/2013 05:15 AM, Martin K. Petersen wrote:
Bernd == Bernd Schubert bernd.schub...@fastmail.fm writes:
Bernd,
Product revision level: R001
It's clearly not verbatim passthrough...
Bernd Besides the firmware, the difference might be that I'm exporting
Bernd single disks without
On 07/30/2013 01:34 AM, Martin K. Petersen wrote:
Nix == Nix n...@esperi.org.uk writes:
Bernd,
Nix I can now confirm that reverting this commit causes this problem to
Nix go away, and my machine boots fine again.
Can you please send me the output of sq_inq with your 1.49 firmware?
I made a
On 07/30/2013 02:56 AM, Nix wrote:
On 30 Jul 2013, Douglas Gilbert outgrape:
Please supply the information that Martin Petersen asked
for.
Did it in private IRC (the advantage of working for the same division of
the same company!)
I didn't realise the original fix was actually implemented
Hi Nick,
On 07/29/2013 12:10 PM, Nick Alcock wrote:
My server's ARC-1210 has been working fine for years, but when I
upgraded from 3.10.1, it started failing:
Instead of
[0.784044] Areca RAID Controller0: F/W V1.46 2009-01-06 Model ARC-1210
[0.804028] scsi0 : Areca SATA Host Adapter
On 07/29/2013 03:05 PM, Nix wrote:
On 29 Jul 2013, Bernd Schubert said:
Hi Nick,
On 07/29/2013 12:10 PM, Nick Alcock wrote:
arcmsr0: abort device command of scsi id = 0 lun = 1
arcmsr0: abort device command of scsi id = 0 lun = 0
arcmsr: executing bus reset eh.num_resets=0, num_
On 06/07/2013 04:15 AM, Martin K. Petersen wrote:
Bernd == Bernd Schubert bernd.schub...@itwm.fraunhofer.de writes:
max_t(unsigned long, max, SD_MAX_WS10_BLOCKS);
Bernd Max? Not min_t()?
Brain fart. Updated patch with a few other adjustments.
I have tested this on a couple of JBODs
On 06/05/2013 12:02 PM, Bernd Schubert wrote:
On 06/04/2013 05:39 PM, Joe Lawrence wrote:
Just curious, what type drives were in your RAID and what does
/sys/class/scsi_disk/*/max_write_same_blocks report? If you have a spare
drive to test, maybe you could try a quick sg_write_same command
On 06/05/2013 09:14 PM, Martin K. Petersen wrote: Bernd == Bernd
Schubert bernd.schub...@itwm.fraunhofer.de writes:
Bernd The md layer currently cannot handle failed WRITE_SAME commands
Bernd and the initial easiest fix is to check if the device supports
Bernd WRITE_SAME at all. It already
being down while rsync is running.
do you have the write-back cache of the controller enabled for your disks?
When you disable this cache, the controller will also disable the disks,
cause a write-performance between 3 to 8MB/s per disks.
Cheers,
Bernd
--
Bernd Schubert
Q-Leap Networks GmbH
handling patches in queue for 2.6.22, I would like to
know if I would have catched this error, but 0x0007 is pretty meaningless
for me :(
Thanks,
Bernd
--
Bernd Schubert
Q-Leap Networks GmbH
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message
On Wednesday 16 January 2008 19:27:43 James Bottomley wrote:
On Wed, 2008-01-16 at 19:13 +0100, Bernd Schubert wrote:
Hi,
I already grepped, but I don't find the definition of
return code = 0x0007
Just got with FC and 2.4.18 of scientitfic linux:
sd 1:0:0:0: SCSI error
in
production situation. Some hints for further debugging should be suffienct
for now.
Thanks,
Bernd
--
Bernd Schubert
Q-Leap Networks GmbH
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
]
[ 2349.916713]
Thanks,
Bernd
--
Bernd Schubert
Q-Leap Networks GmbH
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
within
+time limit */
wait_queue_head_t host_wait;
struct scsi_host_template *hostt;
struct scsi_transport_template *transportt;
--
Bernd Schubert
Q-Leap Networks GmbH
-
To unsubscribe from this list: send the line
Domain Validation
Hmm, somehow related to sdev-inquiry_len, but isn't it the task of
spi_schedule_dv_device() and subfunctions to do that properly?
Any comments, hints and help is appreciated.
Signed-of-by: Bernd Schubert [EMAIL PROTECTED]
Index: linux-2.6.22/drivers/scsi/scsi_error.c
On Wednesday 12 December 2007 14:39:27 Matthew Wilcox wrote:
On Wed, Dec 12, 2007 at 01:54:14PM +0100, Bernd Schubert wrote:
below is a patch introducing device recovery, trying to prevent i/o
errors when a DID_NO_CONNECT or SOFT_ERROR does happen.
Why doesn't the regular scsi_eh do what
:36 +0100, Bernd Schubert wrote:
On Wednesday 12 December 2007 14:39:27 Matthew Wilcox wrote:
On Wed, Dec 12, 2007 at 01:54:14PM +0100, Bernd Schubert wrote:
below is a patch introducing device recovery, trying to prevent i/o
errors when a DID_NO_CONNECT or SOFT_ERROR does happen
() doesn't seem to be suffient.
I would be greatful for any hints.
Signed-off-by: Bernd Schubert [EMAIL PROTECTED]
Index: linux-2.6.22/drivers/scsi/scsi_error.c
===
--- linux-2.6.22.orig/drivers/scsi/scsi_error.c 2007-12-10 19:58
Hello Andrew,
thanks for your help!
On Friday 07 December 2007 02:09:11 Andrew Morton wrote:
On Wed, 5 Dec 2007 21:44:54 +0100
Bernd Schubert [EMAIL PROTECTED] wrote:
after scsi-recovery a system here went into some kind lock-up, everything
seems to be in wait_for_completion(). Please see
.
Any hints and suggestions are highly appreciated.
Thanks in advance,
Bernd
--
Bernd Schubert
Q-Leap Networks GmbH
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
we have to deal here with troublesome Infortrend devices. These units do
have 2 independent scsi channels, which are unfortunately not so
independent as they should be.
Now we have two different systems (lets say OSS-1 and OSS-2) connected to
each of the scsi-channels and both channels are
it
would solve Soerens problem and ours as well (ours magically already went
away using the mod15 fix). Well, maybe I port it anyway to 2.6.23 to see if
it also solves our problem.
Thanks,
Bernd
--
Bernd Schubert
Q-Leap Networks GmbH
-
To unsubscribe from this list: send the line unsubscribe
On Friday 12 October 2007 23:08:21 Jeff Garzik wrote:
Bernd Schubert wrote:
a) 2.6.23 + sil-patch I posted, this is on a customer system (though my
former group), I wouldn't like to use -mm there.
b) .config is attached
c) attached
d) attached (don't get irritaded by those machine
On Wednesday 10 October 2007 11:12:20 Bernd Schubert wrote:
On Monday 08 October 2007 17:09:17 Bernd Schubert wrote:
[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
/s to 20-25MB/s. But better safe than
lost data or damaged filesystem.
Signed-off-by: Bernd Schubert [EMAIL PROTECTED]
Index: linux-2.6.23-rc9/drivers/ata/sata_sil.c
===
--- linux-2.6.23-rc9.orig/drivers/ata/sata_sil.c2007-10
| 58 ++--
include/linux/libata.h|6 +++
3 files changed, 62 insertions(+), 11 deletions(-)
Signed-off-by: Bernd Schubert [EMAIL PROTECTED]
Index: linux-2.6.23-rc9/drivers/ata/libata-core.c
and no
definite prove...
Also, this is with 3114, maybe this chip behaves a bit different than 3112?
Thanks,
Bernd
--
Bernd Schubert
Q-Leap Networks GmbH
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
On Thursday 11 October 2007 17:04:45 Jeff Garzik wrote:
Bernd Schubert wrote:
On Thursday 11 October 2007 16:19:37 Jeff Garzik wrote:
1) Just about the only valid optimization is to ensure that only the
write path must be limited to small chunks, not both read- and
write-paths. Tejun had
On Monday 08 October 2007 17:09:17 Bernd Schubert wrote:
[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
disk will suffer from data corruption,
but the data on the older ST3200822AS will *not*.
kernel versions tested: 2.6.15-2.6.20
Any ideas how to proceed?
Thanks,
Bernd
--
Bernd Schubert
Q-Leap Networks GmbH
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body
: p1 p2 p3
[ 345.187133] sd 1:0:0:0: Attached scsi disk sdb
The ST3250820AS data on the ST3250820AS disk will suffer from data corruption,
but the data on the older ST3200822AS will *not*.
kernel versions tested: 2.6.15-2.6.20
Any ideas how to proceed?
Thanks,
Bernd
--
Bernd Schubert
Q-Leap
Hi,
recently I asked about problems to expect with 2TB devices and the answer
of Douglas made me hope we won't get any problems this time.
Unfortunately, we get I/O errors on accessing the device.
The unit is called transtec PV610S, which is actually an Infortrend EonStor
A16U-G2421-1 device.
in Debian don't have these files and including the header
files directly from the kernel tree doesn't work.
Do you have newer sources (the most recent version I could find are from
mptlinux-3.02.60) or a working binary?
Thanks,
Bernd
--
Bernd Schubert
PCI / Theoretische Chemie
Universität
expert those scsi card dumps really don't say
anything :(
Thanks again,
Bernd
--
Bernd Schubert
Physikalisch Chemisches Institut / Theoretische Chemie
Universität Heidelberg
INF 229
69120 Heidelberg
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message
Hi,
we have not bought the device yet, but presently in the process to do so.
Before we buy it, I want to know about problems in advance...
I'm somewhat worried about this problem report
http://lists.freebsd.org/pipermail/aic7xxx/2006-January/thread.html#4280
Especially as I don't see a final
the system as it is without another reboot.
Of course, we would also like to know the reason for the oops. Any help is
appreciated.
Thanks in advance,
Bernd
--
Bernd Schubert
Physikalisch Chemisches Institut / Theoretische Chemie
Universität Heidelberg
INF 229
69120 Heidelberg
e-mail
54 matches
Mail list logo
