Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Thursday, March 24, 2016 2:06 AM
> To: Matthias Prager
> Cc: Sreekanth Reddy ; linux-scsi
> ; Jason Taylor ;
> LKML ; x...@kernel.org
> Subject: Re: [BUG] mpt2sas: driver init fails on kernel >=4.2 for 9211-8i IT
>
>
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
>> 'ba
Cc: Dimitri Sivanich
> Cc: Joerg Roedel
> Link:
> http://lkml.kernel.org/r/1428905519-23704-14-git-send-email-jiang@linux.intel.com
> Signed-off-by: Thomas Gleixner
>
> :04 04 786bcad9a3fad413e0b744e2cfa20da7ff402db6
> 22618cac66dee85a7752bb3af81169fff3a242d8 March
> :04000
es definitely - 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
> wrote:
>> Am 21.03
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
> 'ini
elaborate below statement 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
> wrote:
>
.803272] 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),
>
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 w
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 c
per card 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 JMB
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
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 interes
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 checksum
ue but thus far 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
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
Hello James,
Am 25.07.2012 21:55, schrieb James Bottomley:>
> It looks like a hack like this might be needed.
>
> James
>
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 mod
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 f
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 fin
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&#
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. Me
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 t
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 85ef06d1d252f6a2e73b678591ab71c
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 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 92
Am 10.07.2012 00:08, schrieb NeilBrown:
> On Mon, 09 Jul 2012 16:40:15 +0200 Matthias Prager
> 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 their i
o let me know if I'm
posting 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
26 matches
Mail list logo
