https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #52 from o...@ojab.ru ---
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ffdadd68af5a397b8a52289ab39d62e1acb39e63
Patch is merged, bug can be closed.
--
You are receiving this mail because:
You are
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #51 from o...@ojab.ru ---
(as a side note, does anyone else has an issue [0] with `rmmod mpt3sas`? It's
reproducible with LSI SAS 9217-8i HBA, and I would like to know if other HBAs
are affected)
[0]
https://bugzilla.kernel.org/show_bug.cgi?id=60644
o...@ojab.ru changed:
What|Removed |Added
CC||o...@ojab.ru
--- Comment #50 from
https://bugzilla.kernel.org/show_bug.cgi?id=60644
rlung...@yahoo.com changed:
What|Removed |Added
CC||rlung...@yahoo.com
--- Comment #49
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #45 from Jeff Johnson jeff.john...@aeoncomputing.com ---
I ran more detailed tests this weekend.
ASPM MSI disabled = stable machine under zfs load
ASPM disabled / MSI enabled = stable machine under zfs load
ASPM enabled / MSI
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #46 from Jeff Johnson jeff.john...@aeoncomputing.com ---
addendum/corrections to last...
LSI 9207-8i with phase 17 firmware.
Motherboards with Intel C602 chipset appear to be functioning w/o issue
Apologies.. not enough coffee
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #47 from Konstantin ktrac...@gmail.com ---
Thanks for the hint at ASPM ! After disabling it in the BIOS I was able to
scrub my zpool without a single issue.
# zpool status
scan: scrub repaired 0 in 6h32m with 0 errors on Tue Jan
https://bugzilla.kernel.org/show_bug.cgi?id=60644
Konstantin ktrac...@gmail.com changed:
What|Removed |Added
CC||ktrac...@gmail.com
---
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #42 from Konstantin ktrac...@gmail.com ---
Created attachment 122581
-- https://bugzilla.kernel.org/attachment.cgi?id=122581action=edit
zpool status output
zpool status showing the disks configured as a raidz3 vdev.
--
You are
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #43 from Konstantin ktrac...@gmail.com ---
Hello all,
enabling Above 4G encoding in the bios did not help in my case.
I enabled PERR and SERR as well. PCIe ASPM is forced on by the bios and the
kernel.
When I scrub my zpool, the
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #37 from Jeff Johnson jeff.john...@aeoncomputing.com ---
I can confirm Tommy's observations about disabling PERR and SERR solving the
issue.
The motherboard I am using (Supermicro X8DTH-iF) does not have those exact BIOS
settings to
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #38 from Jeff Johnson jeff.john...@aeoncomputing.com ---
Apologies, I forgot to add important information..
I am not running a 3.x kernel, I am running a 2.6 kernel. It would appear that
this problem is a hardware issue (LSI) and not
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #39 from Sreekanth Reddy sreekanth.re...@lsi.com ---
I am on vacation till 17th Janury 2014. I will have limited access to emails
during this time. For urgent issues, please contact my manager Krishna
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #40 from Tommy Apel tommyape...@gmail.com ---
Hello all,
I've actually been playing around with this a bit more and found out that the
PERR and SERR might only hide problem for a while, sustained load over longer
periods (4-5 hours)
https://bugzilla.kernel.org/show_bug.cgi?id=60644
Tommy Apel tommyape...@gmail.com changed:
What|Removed |Added
CC||tommyape...@gmail.com
https://bugzilla.kernel.org/show_bug.cgi?id=60644
Jeff Johnson jeff.john...@aeoncomputing.com changed:
What|Removed |Added
CC|
On Tue, Sep 17, 2013 at 11:00:21AM +, bugzilla-dae...@bugzilla.kernel.org
wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #32 from livea...@live.com ---
Hi .
This bug is still present in 3.12-rc1 as of today's tests .
You might want to try the latest P17
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #33 from pa...@iki.fi ---
You might want to try the latest P17 firmware aswell, it has been out for a
couple of weeks now. There's not much in the changelogs, but it seems to fix
some other SGPIO related issues at least.
--
You are
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #34 from livea...@live.com ---
Hi .
In fact I installed P17 on both controllers (2308 -as 9207- and M1015 -as
9211-) , but nothing has changed at all .
P16 worked just fine under Windows Server 2012 .
the problem lies in MPT2SAS as
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #32 from livea...@live.com ---
Hi .
This bug is still present in 3.12-rc1 as of today's tests .
Thank you .
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #28 from livea...@live.com ---
PS . :
To summerize what I have in my server :
1 - BTRFS RAID1 (5 disks) : FAILS
2 - BTRFS Single Data Profile (2 disks) : FAILS
3 - BTRFS Single disk FS (No RAID) : FAILS (But recovers without
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #29 from livea...@live.com ---
Hi .
I created a BTRFS RAID0 using a leafsize of 64k .
Copying some files to the RAID results in some strange output in dmesg :
[107991.481826] sd 8:0:10:0: [sdm]
[107991.482239] Sense Key : 0x2
https://bugzilla.kernel.org/show_bug.cgi?id=60644
Kurk k...@shiftmail.org changed:
What|Removed |Added
CC||k...@shiftmail.org
--- Comment
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #31 from livea...@live.com ---
Hi Kurk .
As for the HDDs , here is the list :
Hitachi_HDS5C4040ALE630 (4TB) - (4 disks)
TOSHIBA_DT01ACA300 (3TB) (2 disks)
WDC_WD10EARS-00Y5B1_WD-WCAV5N165986 (1TB) (1 disk)
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #23 from Hannes Reinecke h...@suse.de ---
So the firmware does indeed wedge under high load. Given the issues I've had so
far with LSI SATL I'm not surprised.
Does the same thing happen when running on a single disk, ie without MD?
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #24 from livea...@live.com ---
Hello .
I used to have the same issues with MD . yes .
I'm using BTRFS , I don't know if BTRFS RAID code was ported from MD , but the
issue is the same .
I didn't try anything other than BTRFS and MD .
https://bugzilla.kernel.org/show_bug.cgi?id=60644
Bernd Schubert bernd.schub...@fastmail.fm changed:
What|Removed |Added
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #26 from livea...@live.com ---
Hi .
Thanks for your kind help , Bernd .
setting /sys/block/sdX(c~j)/device/queue_depth to 1 unfortuantely didn't solve
the issue .
I put the following in the end of the boot line :
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #27 from livea...@live.com ---
Hi again .
I set up two disks as two seperate BTRFS volumes (No RAID) , and did some tests
.
One of the disks failed to complete the process given to it , but it wasn't
dropped , and checking the
https://bugzilla.kernel.org/show_bug.cgi?id=60644
Per Zetterlund p...@pz.se changed:
What|Removed |Added
CC||p...@pz.se
--- Comment #18
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #19 from livea...@live.com ---
It seems the LSI isn't interested in fixing this . I also purchased a 9211-8i
card lately , and it has the same issue .
Perhaps , I might consider buying an Adaptec HBA to replace these LSI
controllers .
https://bugzilla.kernel.org/show_bug.cgi?id=60644
Hannes Reinecke h...@suse.de changed:
What|Removed |Added
CC||h...@suse.de
--- Comment
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #21 from Hannes Reinecke h...@suse.de ---
Try with this patch. With a bit of luck it's just the firmware becoming
sluggish under high load, so disabling the watchdog will be circumvent this.
And any real error would still be handled by
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #22 from livea...@live.com ---
Hi . Thank you Hannes very much for the patch .
I compiled it inside a 3.11-rc7 , and put mpt2sas.disable_watchdog=1 in the
boot parameters .
It helped the driver to survive longer -around an hour
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #17 from livea...@live.com ---
Hi .
Today , I ran some tests on all 8 drives connected to the LSI 2308 .
The results are rather surprising . The controller goes non-operational under
high READ workloads , while WRITE workloads always
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #14 from livea...@live.com ---
Hi .
Any updates regarding this bug ?
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #15 from Sreekanth Reddy sreekanth.re...@lsi.com ---
(In reply to liveaxle from comment #14)
Hi .
Any updates regarding this bug ?
I tried to reproduce this issue locally, but for me this issue is not
reproduced.
Here are the
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #16 from livea...@live.com ---
Hello .
The thing is that I'm using SATA drives and not SAS drives . The motherboard
exposes the LSI controller as 8 SATA ports .
This wasn't an issue under Windows 2012 , so I think that hardware
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #11 from Sreekanth Reddy sreekanth.re...@lsi.com ---
Hi,
Thanks for providing the logs.
From the logs what I observed is that controller is going in to the non
operational state and so we are seeing the messages mpt2sas0:
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #12 from livea...@live.com ---
Hi .
I can easily reproduce this issue in a second by running :
btrfs scrub start /MOUNTPOINT
The btrfs system is a RAID1 that consists of 5 drives .
Also in an MD-RAID0 that consists of 3 drives by
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #13 from livea...@live.com ---
One more thing , the MD-RAID0 has XFS but that doesn't matter because it used
to have EXT4 with the same results .
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To
https://bugzilla.kernel.org/show_bug.cgi?id=60644
Sreekanth Reddy sreekanth.re...@lsi.com changed:
What|Removed |Added
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #4 from livea...@live.com ---
Hi .
I'll attach it , however dmesg only shows the last 16000 events . I hope it
would be enough .
Sorry for being a noob in reporting my first bug , but can you tell me how can
I find the exact IO rate
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #5 from livea...@live.com ---
Created attachment 107033
-- https://bugzilla.kernel.org/attachment.cgi?id=107033action=edit
dmeg logs 2
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #6 from livea...@live.com ---
Hi again .
I did monitor the IO of the RAID array using IOstat tool .
I'll attach the output .
One thing I noticed is that monitoring the raid array made it survive a LOT
longer than before .
I simply
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #7 from livea...@live.com ---
Created attachment 107038
-- https://bugzilla.kernel.org/attachment.cgi?id=107038action=edit
iostat log
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #8 from Sreekanth Reddy sreekanth.re...@lsi.com ---
Hi,
Can you please provide me the /var/log/message file as dmesg logs is not enough
to analysize this issue.
Thanks,
Sreekanth
--
You are receiving this mail because:
You are
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #9 from livea...@live.com ---
Hi .
Ok . Journal for this entire day will be attached . It starts at 12:00 AM
To save your time , mpt2sas errors start at (03:19:26) mark .
Thank you .
--
You are receiving this mail because:
You
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #10 from livea...@live.com ---
Created attachment 107041
-- https://bugzilla.kernel.org/attachment.cgi?id=107041action=edit
Journal 1
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #1 from livea...@live.com ---
Created attachment 107032
-- https://bugzilla.kernel.org/attachment.cgi?id=107032action=edit
dmesg logs
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To
https://bugzilla.kernel.org/show_bug.cgi?id=60644
--- Comment #2 from livea...@live.com ---
Kernel locks are rather soft , the machine functions but the HDDs activity
LED stays on and the kernel doesn't respond to a reboot or shutdown command
from console .
It has to be hard-reset using the
51 matches
Mail list logo
