Thanks for your insights Baruch.
The crc count did not increase any further - so this was probably just
small oddity (was zero before when the write-same issue already
happened). The real issue however does persist. I found a way to
reliably trigger the log messages. Using a program called
Hello everyone,
an update: I was able to reproduce the problem on my testing
machine (at least sort of) and confirmed that
c8dc9c6 md: raid1,10: Handle REQ_WRITE_SAME flag in write bios
fixes things.
Also applied c8dc9c6 to the main system's 3.8.6 kernel. Working without
any issues.
One
Hello everyone,
I'm having a hard time getting my JMicron JMB363 PCI SATA/IDE Card
to work under linux.
The 'lspci -nn' output reads as follows:
RAID bus controller [0104]: JMicron Technology Corp. JMB363 SATA/IDE
Controller [197b:2363] (rev 03)
I tried my own kernel (3.9.6) under gentoo with
are still not detected). I'm trying to
understand how the pata_jmicron driver is supposed to work
but haven't wrapped my head around it yet.
- Matthias
Am 19.06.2013 15:12, schrieb Matthias Prager:
Hello everyone,
I'm having a hard time getting my JMicron JMB363 PCI SATA/IDE Card
to work under
Am 23.06.2013 16:28, schrieb Matthias Prager:
I did some more digging and came up with a partial
workaround:
After adding the line:
{ PCI_VDEVICE(JMICRON, 0x236f), board_ahci_ign_iferr },
(at line 301 of drivers/ata/ahci.c)
The the sata ports of my two cards get detected and lspci -k
failed to do so.
Unfortunately I don't have access to the system on a day-to-day basis,
but I will test eventual fixes as soon as I get the chance.
---
Matthias Prager
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More
this to the wrong lists (linux-scsi and linux-raid) or if there
is anything which might not be helpful with the way I'm reporting this.
Regards,
Matthias Prager
--
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
Am 10.07.2012 00:08, schrieb NeilBrown:
On Mon, 09 Jul 2012 16:40:15 +0200 Matthias Prager li...@matthiasprager.de
wrote:
Even though it says creating aborted it still created md127.
One of my pet peeves in when people interpret the observations wrongly and
then report
Am 09.07.2012 21:37, schrieb Robert Trace:
I did some further research regarding my problem.
It appears to me the fault does not lie with the mpt2sas driver (not
that I can definitely exclude it), but with the md implementation.
I'm actually discovering some of the same issues (LSI 9211-8i
Am 10.07.2012 00:24, schrieb Robert Trace:
Also, TURs don't appear to actually wake the disk up (should they?).
The only thing I've found that'll wake the disk up is an explicit START
UNIT command.
I haven't checked the scsi logging side, but about the only commands
that wake up the disks
Am 11.07.2012 01:27, schrieb Robert Trace:
On 07/09/2012 09:51 PM, Robert Trace wrote:
Huh.. I just retested this and I'm seeing really random behavior.
Ok, with a refined test I've been able to reliably reproduce this and I
bisected it back to commit
I just tested kernel version 3.4.4 without commit
85ef06d1d252f6a2e73b678591ab71caad4667bb and it also works fine (beware
of commit 62d3c5439c534b0e6c653fc63e6d8c67be3a57b1 as it conflicts with
reverting 85ef06d1d252f6a2e73b678591ab71caad4667bb).
I'm trying to understand why this commit leads to
Hello Tejun,
Am 17.07.2012 20:09, schrieb Tejun Heo:
Hello,
On Wed, Jul 11, 2012 at 03:48:00PM +0200, Matthias Prager wrote:
I'm trying to understand why this commit leads to the issue of i/o
failing on spun down drives, in hopes of being able to fix it. Meanwhile
maybe Tejun Heo (author
Am 17.07.2012 22:01, schrieb Tejun Heo:
On Tue, Jul 17, 2012 at 09:39:41PM +0200, Matthias Prager wrote:
I could not however reproduce the issue on any other device than a LSI
SAS controller (using SATA disks) - on a regular ICH10 using AHCI and a
SATA drive I don't see these i/o errors
Hello Tejun,
Am 22.07.2012 19:31, schrieb Tejun Heo:
I haven't consulted SAT but it seems like a bug in SAS driver or
firmware. If it's a driver bug, we better fix it there. If a
firmware bug, working around those is one of major roles of drivers,
so I think setting allow_restart is fine.
Hello everyone,
I retested with a new firmware (P14 - released today), since it contains
a bunch of sata and SATL fixes (according to the changelog).
Unfortunately the observed behavior is unchanged (tested on a 3.4.5 kernel).
Just wanted to let everyone know.
Cheers
Matthias
--
To unsubscribe
Hello James,
Am 25.07.2012 21:55, schrieb James Bottomley:
It looks like a hack like this might be needed.
James
SNIP
I don't yet understand all the code but I'm following your discussion
with Tejun: I've set up a minimal vm running gentoo with a mpt2sas
driven controller in passthrough
Am 16.08.2012 20:26, schrieb Robert Trace:
On 07/25/2012 03:55 PM, James Bottomley wrote:
Well, reading it, so do I. Unfortunately, we get to deal with the world
as it is rather than as we would wish it to be. We likely have this
problem with a lot of USB SATLs as well ...
Has this patch
Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Thursday, March 24, 2016 2:06 AM
> To: Matthias Prager <li...@matthiasprager.de>
> Cc: Sreekanth Reddy <sreekanth.re...@broadcom.com>; linux-scsi
> <linux-scsi@vger.kernel.org>; Jason Taylor <jason.tay...@simplivity
72] scsi 1:0:1:0: SATA: handle(0x000e),
> sas_addr(0x443322110200), phy(2), device_name(0x5000c500908f1d05)
> [2.803660] scsi 1:0:1:0: SATA: enclosure_logical_id(0x500605b0026f79b0),
> slot(1)
> [2.803981] scsi 1:0:1:0: atapi(n), ncq(y), asyn_notify(n), smart(y),
&
ely - I never observed these timeouts with any kernel
<=4.1.20, and I started seeing them from kernel 4.2.1 onward (I haven't
actually tested 4.2.0 yet).
>
> Thanks,
> Sreekanth
>
> On Mon, Mar 21, 2016 at 10:00 PM, Matthias Prager
> <li...@matthiasprager.de> wrote:
>
de>
> Cc: Dimitri Sivanich <sivan...@sgi.com>
> Cc: Joerg Roedel <j...@8bytes.org>
> Link:
> http://lkml.kernel.org/r/1428905519-23704-14-git-send-email-jiang@linux.intel.com
> Signed-off-by: Thomas Gleixner <t...@linutronix.de>
>
> :04000
Am 21.03.2016 um 16:52 schrieb Matthias Prager:
> Hi Sreekanth,
>
> thanks for digging into this issue. Regarding the 4.5.0 after 4.1.20
> boot statement, I will try to express myself better:
>
> I first started the system with the 4.1.20 kernel. Then I issued an
> 'init 6'
ement for me, I am not able
> understand this statement
> "I managed to boot the same 4.5.0 kernel successfully after warm
> rebooting from 4.1.20"
>
> Thanks,
> Sreekanth
>
> On Mon, Mar 21, 2016 at 2:48 PM, Matthias Prager
> <li...@matthiasprager.de>
Hello,
I don't know what's the correct procedure, whether I should file a bug or first
report this issue on the kernel mailing-list. So please feel free to tell me to
open a ticket in the bugtracker (bugzilla.kernel.org?).
But first let me present the issue I encounter:
Kernels >= 4.2 (4.2.1
Am 24.03.2016 um 07:06 schrieb Thomas Gleixner:
> On Thu, 24 Mar 2016, Matthias Prager wrote:
>> The timeout happens reliably after two warm boots with a 'bad' kernel
>> after coming from a 'good' kernel, and also after one cold boot with a
>> 'bad' kernel (meaning cold b
26 matches
Mail list logo
