4:18 a.m.
has anybody else faced complete freezes of a machine
due raid-check? today the same as last thursday while
the freeze seems not to happen by the raid-check itself
according to running smokepings from outside which are
green until i try to use the machine
* last thursday morining around 8:30 while login in KDE
* today around 9:45 AM while power on the screen and
continue to re-use a existing KDE session
however, after hard power off, the fsck, login in KDE
and start the raid-check manually on TTY3 it continues
____________________________________________________
since the raid-check starts at 5:30 and all heavy IO
from remote-backups and rsnapshot ends at 4:30 to not
collide it's hardly IO-dependent
[root@srv-rhsoft:~]$ cat /etc/cron.d/raid-check
30 5 * * Thu root /usr/sbin/raid-check
7:12 a.m.
On Thu, May 01, 2014 at 11:18:25 +0200,
Reindl Harald <h.reindl(a)thelounge.net> wrote:
has anybody else faced complete freezes of a machine
due raid-check? today the same as last thursday while
the freeze seems not to happen by the raid-check itself
according to running smokepings from outside which are
green until i try to use the machine
I had something similar happen in pre-release kernels a few versions ago,
but it got fixed and I am not seeing it now.
7:45 a.m.
Am 01.05.2014 14:12, schrieb Bruno Wolff III:
On Thu, May 01, 2014 at 11:18:25 +0200,
Reindl Harald <h.reindl(a)thelounge.net> wrote:
> has anybody else faced complete freezes of a machine
> due raid-check? today the same as last thursday while
> the freeze seems not to happen by the raid-check itself
> according to running smokepings from outside which are
> green until i try to use the machine
I had something similar happen in pre-release kernels a few versions ago, but it got
fixed and I am not seeing it now
interesting - thanks for feedback
i have faced this only on F20 with the recent 3.14 kernel which
is except the weekly raid-check hyperstable under any heavy
networking and/or IO load, what makes it hard to debug is that
it's not triggerable by starting raid-check manually
the only information i sadly can provide is partitioning / raid setup
[root@srv-rhsoft:~]$ df
Filesystem Type Size Used Avail Use% Mounted on
/dev/md1 ext4 29G 6.4G 23G 23% /
/dev/md0 ext4 485M 37M 444M 8% /boot
/dev/md2 ext4 3.6T 2.0T 1.6T 57% /mnt/data
[root@srv-rhsoft:~]$ cat /usr/local/bin/raid_status
#!/usr/bin/bash
echo
"---------------------------------------------------------------------------------"
/sbin/mdadm --detail /dev/md0
echo
"---------------------------------------------------------------------------------"
/sbin/mdadm --detail /dev/md1
echo
"---------------------------------------------------------------------------------"
/sbin/mdadm --detail /dev/md2
echo
"---------------------------------------------------------------------------------"
cat /proc/mdstat
echo
"---------------------------------------------------------------------------------"
[root@srv-rhsoft:~]$ raid_status
---------------------------------------------------------------------------------
/dev/md0:
Version : 1.0
Creation Time : Wed Jun 8 13:10:48 2011
Raid Level : raid1
Array Size : 511988 (500.07 MiB 524.28 MB)
Used Dev Size : 511988 (500.07 MiB 524.28 MB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent
Update Time : Thu May 1 09:42:22 2014
State : clean, resyncing (DELAYED)
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Name : localhost.localdomain:0
UUID : 1d691642:baed26df:1d197496:4fb00ff8
Events : 651
Number Major Minor RaidDevice State
0 8 49 0 active sync /dev/sdd1
5 8 33 1 active sync /dev/sdc1
4 8 1 2 active sync /dev/sda1
3 8 17 3 active sync /dev/sdb1
---------------------------------------------------------------------------------
/dev/md1:
Version : 1.1
Creation Time : Wed Jun 8 13:10:52 2011
Raid Level : raid10
Array Size : 30716928 (29.29 GiB 31.45 GB)
Used Dev Size : 15358464 (14.65 GiB 15.73 GB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Thu May 1 14:43:16 2014
State : active, resyncing (DELAYED)
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Layout : near=2
Chunk Size : 512K
Name : localhost.localdomain:1
UUID : b7475879:c95d9a47:c5043c02:0c5ae720
Events : 12359
Number Major Minor RaidDevice State
0 8 50 0 active sync set-A /dev/sdd2
5 8 34 1 active sync set-B /dev/sdc2
4 8 2 2 active sync set-A /dev/sda2
3 8 18 3 active sync set-B /dev/sdb2
---------------------------------------------------------------------------------
/dev/md2:
Version : 1.1
Creation Time : Wed Jun 8 13:10:56 2011
Raid Level : raid10
Array Size : 3875222528 (3695.70 GiB 3968.23 GB)
Used Dev Size : 1937611264 (1847.85 GiB 1984.11 GB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Thu May 1 14:43:23 2014
State : active, checking
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Layout : near=2
Chunk Size : 512K
Check Status : 42% complete
Name : localhost.localdomain:2
UUID : ea253255:cb915401:f32794ad:ce0fe396
Events : 496336
Number Major Minor RaidDevice State
0 8 51 0 active sync set-A /dev/sdd3
5 8 35 1 active sync set-B /dev/sdc3
4 8 3 2 active sync set-A /dev/sda3
3 8 19 3 active sync set-B /dev/sdb3
---------------------------------------------------------------------------------
Personalities : [raid1] [raid10]
md2 : active raid10 sdd3[0] sda3[4] sdb3[3] sdc3[5]
3875222528 blocks super 1.1 512K chunks 2 near-copies [4/4] [UUUU]
[========>............] check = 42.9% (1665190848/3875222528) finish=278.2min
speed=132374K/sec
bitmap: 3/29 pages [12KB], 65536KB chunk
md1 : active raid10 sda2[4] sdb2[3] sdd2[0] sdc2[5]
30716928 blocks super 1.1 512K chunks 2 near-copies [4/4] [UUUU]
resync=DELAYED
bitmap: 1/1 pages [4KB], 65536KB chunk
md0 : active raid1 sdb1[3] sda1[4] sdd1[0] sdc1[5]
511988 blocks super 1.0 [4/4] [UUUU]
resync=DELAYED
unused devices: <none>
---------------------------------------------------------------------------------
7:55 a.m.
The bug I reported to upstream is:
https://bugzilla.kernel.org/show_bug.cgi?id=68061
That was for 3.13, so if you were running into a varient of the problem
I was seeing, you should have seen it in 3.13. I did not see the problem
with 3.14 or 3.15 pre-release kernels. I'm using raid 1 instead of raid 10.
8:06 a.m.
Am 01.05.2014 14:55, schrieb Bruno Wolff III:
The bug I reported to upstream is:
https://bugzilla.kernel.org/show_bug.cgi?id=68061
That was for 3.13, so if you were running into a varient of the problem I was seeing, you
should have seen it in
3.13. I did not see the problem with 3.14 or 3.15 pre-release kernels. I'm using raid
1 instead of raid 10
different problem class
you where able to look at cat/proc/mdstat
in my case the machine is just dead and don't react on any
input including ACPI powerbutton, this morning i saw a frozen
KDE desktop with high CPU load from the past in monitoring
widgets, last week it froze while login (after enter username
and password in KDM the first black screen before build the
desktop appeared and any operatins stopped)
i will wait some hours for possible feedback here and than
file a bugreport, sadly there is not much constrcutive i
can report caused by the complete system freeze and no logs
or anything after hard power off and boot again
4:09 a.m.
Am 01.05.2014 15:06, schrieb Reindl Harald:
Am 01.05.2014 14:55, schrieb Bruno Wolff III:
> The bug I reported to upstream is:
> https://bugzilla.kernel.org/show_bug.cgi?id=68061
>
> That was for 3.13, so if you were running into a varient of the problem I was seeing,
you should have seen it in
> 3.13. I did not see the problem with 3.14 or 3.15 pre-release kernels. I'm using
raid 1 instead of raid 10
different problem class
you where able to look at cat/proc/mdstat
in my case the machine is just dead and don't react on any
input including ACPI powerbutton, this morning i saw a frozen
KDE desktop with high CPU load from the past in monitoring
widgets, last week it froze while login (after enter username
and password in KDM the first black screen before build the
desktop appeared and any operatins stopped)
i will wait some hours for possible feedback here and than
file a bugreport, sadly there is not much constrcutive i
can report caused by the complete system freeze and no logs
or anything after hard power off and boot again
ok, it's not only raid-check, 15 minutes ago it happened again
freeze number 3 - i fear a bugreport makes not much sense
because "system freezes once or two per week before lunch"
is not that much helpful, most likely that will not hit
only me and get away with a following 3.14.x update
Apr 21 23:34:54 Installed: kernel-3.14.1-200.fc20.x86_64
Apr 28 20:50:54 Installed: kernel-3.14.2-200.fc20.x86_64
4:10 a.m.
Am 02.05.2014 11:09, schrieb Reindl Harald:
Am 01.05.2014 15:06, schrieb Reindl Harald:
> Am 01.05.2014 14:55, schrieb Bruno Wolff III:
>> The bug I reported to upstream is:
>> https://bugzilla.kernel.org/show_bug.cgi?id=68061
>>
>> That was for 3.13, so if you were running into a varient of the problem I was
seeing, you should have seen it in
>> 3.13. I did not see the problem with 3.14 or 3.15 pre-release kernels. I'm
using raid 1 instead of raid 10
>
> different problem class
> you where able to look at cat/proc/mdstat
>
> in my case the machine is just dead and don't react on any
> input including ACPI powerbutton, this morning i saw a frozen
> KDE desktop with high CPU load from the past in monitoring
> widgets, last week it froze while login (after enter username
> and password in KDM the first black screen before build the
> desktop appeared and any operatins stopped)
>
> i will wait some hours for possible feedback here and than
> file a bugreport, sadly there is not much constrcutive i
> can report caused by the complete system freeze and no logs
> or anything after hard power off and boot again
ok, it's not only raid-check, 15 minutes ago it happened again
freeze number 3 - i fear a bugreport makes not much sense
because "system freezes once or two per week before lunch"
is not that much helpful, most likely that will not hit
only me and get away with a following 3.14.x update
Apr 21 23:34:54 Installed: kernel-3.14.1-200.fc20.x86_64
Apr 28 20:50:54 Installed: kernel-3.14.2-200.fc20.x86_64
3.14.3-200.fc20.x86_64 and sadly today the same on two
machines - the only thing i can say for sure that after
whatever happens in the background *any* write to disks
hangs forever
* woke up -> no music
* turn on screen, move the mouse, KDM login screen
* try to enter password
* see the first asterisk and followed input ignored
* move the mousepointer still works
* STRG+ALT+F3 -> thank god there is a active root session
* type "sync" -> no disk activity, no response
* well, power off hard
_____________________________________________
second machine in the office:
* KDM hangs
* login on TTY3 by luck possible
* dmesg -> only the usual lines about starting raid-check
and delay the two other raid devices
* nothing else in dmesg or syslog
* also here: any write to disk stalls
2:10 p.m.
https://bugzilla.redhat.com/show_bug.cgi?id=1096414
https://bugzilla.redhat.com/show_bug.cgi?id=1092937
*both* seems to be fixed with 3.14.5-200.fc20.x86_64
while i am unable to find the relevant change in
the kernel-upstream-changelog
would be nice to know that it is fixed for a reason
and not by random as it came - *maybe* the change
to "data=ordered" instead "data=writeback" is
responsible but i don't want to test that since
there where enough data-damages by that freezes
however, rebootet my workstation 40 times after the
update from koji and 4 raid-check runs without any
freeze on two different machines
Am 08.05.2014 11:10, schrieb Reindl Harald:
Am 02.05.2014 11:09, schrieb Reindl Harald:
> Am 01.05.2014 15:06, schrieb Reindl Harald:
>> Am 01.05.2014 14:55, schrieb Bruno Wolff III:
>>> The bug I reported to upstream is:
>>> https://bugzilla.kernel.org/show_bug.cgi?id=68061
>>>
>>> That was for 3.13, so if you were running into a varient of the problem I was
seeing, you should have seen it in
>>> 3.13. I did not see the problem with 3.14 or 3.15 pre-release kernels.
I'm using raid 1 instead of raid 10
>>
>> different problem class
>> you where able to look at cat/proc/mdstat
>>
>> in my case the machine is just dead and don't react on any
>> input including ACPI powerbutton, this morning i saw a frozen
>> KDE desktop with high CPU load from the past in monitoring
>> widgets, last week it froze while login (after enter username
>> and password in KDM the first black screen before build the
>> desktop appeared and any operatins stopped)
>>
>> i will wait some hours for possible feedback here and than
>> file a bugreport, sadly there is not much constrcutive i
>> can report caused by the complete system freeze and no logs
>> or anything after hard power off and boot again
>
> ok, it's not only raid-check, 15 minutes ago it happened again
> freeze number 3 - i fear a bugreport makes not much sense
> because "system freezes once or two per week before lunch"
> is not that much helpful, most likely that will not hit
> only me and get away with a following 3.14.x update
>
> Apr 21 23:34:54 Installed: kernel-3.14.1-200.fc20.x86_64
> Apr 28 20:50:54 Installed: kernel-3.14.2-200.fc20.x86_64
3.14.3-200.fc20.x86_64 and sadly today the same on two
machines - the only thing i can say for sure that after
whatever happens in the background *any* write to disks
hangs forever
* woke up -> no music
* turn on screen, move the mouse, KDM login screen
* try to enter password
* see the first asterisk and followed input ignored
* move the mousepointer still works
* STRG+ALT+F3 -> thank god there is a active root session
* type "sync" -> no disk activity, no response
* well, power off hard
_____________________________________________
second machine in the office:
* KDM hangs
* login on TTY3 by luck possible
* dmesg -> only the usual lines about starting raid-check
and delay the two other raid devices
* nothing else in dmesg or syslog
* also here: any write to disk stalls
5:28 p.m.
New subject: :-( Re: F20 Kernel 3.14.x / raid-check and freezes
sadly both re-opened today, after some hours of
running shutdown and raid-check with 3.14 is a
pain and taht is *for sure* 3.14.x because my
co-developer stayed at the last 3.13 until i
thought it's fine now, had never that problems
and both 3.14.x shutdowns freezed with mdraid
Am 03.06.2014 21:10, schrieb Reindl Harald:
https://bugzilla.redhat.com/show_bug.cgi?id=1096414
https://bugzilla.redhat.com/show_bug.cgi?id=1092937
*both* seems to be fixed with 3.14.5-200.fc20.x86_64
while i am unable to find the relevant change in
the kernel-upstream-changelog
would be nice to know that it is fixed for a reason
and not by random as it came - *maybe* the change
to "data=ordered" instead "data=writeback" is
responsible but i don't want to test that since
there where enough data-damages by that freezes
however, rebootet my workstation 40 times after the
update from koji and 4 raid-check runs without any
freeze on two different machines
Am 08.05.2014 11:10, schrieb Reindl Harald:
> Am 02.05.2014 11:09, schrieb Reindl Harald:
>> Am 01.05.2014 15:06, schrieb Reindl Harald:
>>> Am 01.05.2014 14:55, schrieb Bruno Wolff III:
>>>> The bug I reported to upstream is:
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=68061
>>>>
>>>> That was for 3.13, so if you were running into a varient of the problem I
was seeing, you should have seen it in
>>>> 3.13. I did not see the problem with 3.14 or 3.15 pre-release kernels.
I'm using raid 1 instead of raid 10
>>>
>>> different problem class
>>> you where able to look at cat/proc/mdstat
>>>
>>> in my case the machine is just dead and don't react on any
>>> input including ACPI powerbutton, this morning i saw a frozen
>>> KDE desktop with high CPU load from the past in monitoring
>>> widgets, last week it froze while login (after enter username
>>> and password in KDM the first black screen before build the
>>> desktop appeared and any operatins stopped)
>>>
>>> i will wait some hours for possible feedback here and than
>>> file a bugreport, sadly there is not much constrcutive i
>>> can report caused by the complete system freeze and no logs
>>> or anything after hard power off and boot again
>>
>> ok, it's not only raid-check, 15 minutes ago it happened again
>> freeze number 3 - i fear a bugreport makes not much sense
>> because "system freezes once or two per week before lunch"
>> is not that much helpful, most likely that will not hit
>> only me and get away with a following 3.14.x update
>>
>> Apr 21 23:34:54 Installed: kernel-3.14.1-200.fc20.x86_64
>> Apr 28 20:50:54 Installed: kernel-3.14.2-200.fc20.x86_64
>
> 3.14.3-200.fc20.x86_64 and sadly today the same on two
> machines - the only thing i can say for sure that after
> whatever happens in the background *any* write to disks
> hangs forever
>
> * woke up -> no music
> * turn on screen, move the mouse, KDM login screen
> * try to enter password
> * see the first asterisk and followed input ignored
> * move the mousepointer still works
> * STRG+ALT+F3 -> thank god there is a active root session
> * type "sync" -> no disk activity, no response
> * well, power off hard
> _____________________________________________
>
> second machine in the office:
>
> * KDM hangs
> * login on TTY3 by luck possible
> * dmesg -> only the usual lines about starting raid-check
> and delay the two other raid devices
> * nothing else in dmesg or syslog
> * also here: any write to disk stalls
6:53 p.m.
New subject: :-( Re: F20 Kernel 3.14.x / raid-check and freezes
Am 06.06.2014 00:28, schrieb Reindl Harald:
sadly both re-opened today, after some hours of
running shutdown and raid-check with 3.14 is a
pain and taht is *for sure* 3.14.x because my
co-developer stayed at the last 3.13 until i
thought it's fine now, had never that problems
and both 3.14.x shutdowns freezed with mdraid
the two commits below smell like related
not sure how to understand the second one
filestems on affected machines are mounted with nobarrier
https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.14.6
____________________________________________________________________________________________
commit 0bc4091108e8f2e65faef3082e5261f2c35cd2b4
Author: NeilBrown <neilb(a)suse.de>
Date: Tue May 6 09:36:08 2014 +1000
md: avoid possible spinning md thread at shutdown.
commit 0f62fb220aa4ebabe8547d3a9ce4a16d3c045f21 upstream.
If an md array with externally managed metadata (e.g. DDF or IMSM)
is in use, then we should not set safemode==2 at shutdown because:
1/ this is ineffective: user-space need to be involved in any 'safemode'
handling,
2/ The safemode management code doesn't cope with safemode==2 on external
metadata
and md_check_recover enters an infinite loop.
Even at shutdown, an infinite-looping process can be problematic, so this
could cause shutdown to hang.
Signed-off-by: NeilBrown <neilb(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
____________________________________________________________________________________________
commit 8c7311a1c4a8d804bde91b00a2f2c1a22a954c30
Author: NeilBrown <neilb(a)suse.de>
Date: Mon May 5 13:34:37 2014 +1000
md/raid10: call wait_barrier() for each request submitted.
commit cc13b1d1500656a20e41960668f3392dda9fa6e2 upstream.
wait_barrier() includes a counter, so we must call it precisely once
(unless balanced by allow_barrier()) for each request submitted.
Since
commit 20d0189b1012a37d2533a87fb451f7852f2418d1
block: Introduce new bio_split()
in 3.14-rc1, we don't call it for the extra requests generated when
we need to split a bio.
When this happens the counter goes negative, any resync/recovery will
never start, and "mdadm --stop" will hang.
Reported-by: Chris Murphy <lists(a)colorremedies.com>
Fixes: 20d0189b1012a37d2533a87fb451f7852f2418d1
Cc: Kent Overstreet <kmo(a)daterainc.com>
Signed-off-by: NeilBrown <neilb(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
____________________________________________________________________________________________
Am 03.06.2014 21:10, schrieb Reindl Harald:
> https://bugzilla.redhat.com/show_bug.cgi?id=1096414
> https://bugzilla.redhat.com/show_bug.cgi?id=1092937
>
> *both* seems to be fixed with 3.14.5-200.fc20.x86_64
> while i am unable to find the relevant change in
> the kernel-upstream-changelog
>
> would be nice to know that it is fixed for a reason
> and not by random as it came - *maybe* the change
> to "data=ordered" instead "data=writeback" is
> responsible but i don't want to test that since
> there where enough data-damages by that freezes
>
> however, rebootet my workstation 40 times after the
> update from koji and 4 raid-check runs without any
> freeze on two different machines
>
> Am 08.05.2014 11:10, schrieb Reindl Harald:
>> Am 02.05.2014 11:09, schrieb Reindl Harald:
>>> Am 01.05.2014 15:06, schrieb Reindl Harald:
>>>> Am 01.05.2014 14:55, schrieb Bruno Wolff III:
>>>>> The bug I reported to upstream is:
>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=68061
>>>>>
>>>>> That was for 3.13, so if you were running into a varient of the
problem I was seeing, you should have seen it in
>>>>> 3.13. I did not see the problem with 3.14 or 3.15 pre-release
kernels. I'm using raid 1 instead of raid 10
>>>>
>>>> different problem class
>>>> you where able to look at cat/proc/mdstat
>>>>
>>>> in my case the machine is just dead and don't react on any
>>>> input including ACPI powerbutton, this morning i saw a frozen
>>>> KDE desktop with high CPU load from the past in monitoring
>>>> widgets, last week it froze while login (after enter username
>>>> and password in KDM the first black screen before build the
>>>> desktop appeared and any operatins stopped)
>>>>
>>>> i will wait some hours for possible feedback here and than
>>>> file a bugreport, sadly there is not much constrcutive i
>>>> can report caused by the complete system freeze and no logs
>>>> or anything after hard power off and boot again
>>>
>>> ok, it's not only raid-check, 15 minutes ago it happened again
>>> freeze number 3 - i fear a bugreport makes not much sense
>>> because "system freezes once or two per week before lunch"
>>> is not that much helpful, most likely that will not hit
>>> only me and get away with a following 3.14.x update
>>>
>>> Apr 21 23:34:54 Installed: kernel-3.14.1-200.fc20.x86_64
>>> Apr 28 20:50:54 Installed: kernel-3.14.2-200.fc20.x86_64
>>
>> 3.14.3-200.fc20.x86_64 and sadly today the same on two
>> machines - the only thing i can say for sure that after
>> whatever happens in the background *any* write to disks
>> hangs forever
>>
>> * woke up -> no music
>> * turn on screen, move the mouse, KDM login screen
>> * try to enter password
>> * see the first asterisk and followed input ignored
>> * move the mousepointer still works
>> * STRG+ALT+F3 -> thank god there is a active root session
>> * type "sync" -> no disk activity, no response
>> * well, power off hard
>> _____________________________________________
>>
>> second machine in the office:
>>
>> * KDM hangs
>> * login on TTY3 by luck possible
>> * dmesg -> only the usual lines about starting raid-check
>> and delay the two other raid devices
>> * nothing else in dmesg or syslog
>> * also here: any write to disk stalls
4:11 a.m.
New subject: :-( Re: F20 Kernel 3.14.x / raid-check and freezes
On Fri, Jun 6, 2014 at 1:28 AM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
sadly both re-opened today, after some hours of
running shutdown and raid-check with 3.14 is a
pain and taht is *for sure* 3.14.x because my
co-developer stayed at the last 3.13 until i
thought it's fine now, had never that problems
and both 3.14.x shutdowns freezed with mdraid
I can confirm the above on two machines w/ MD RAID10 (and boot on MD RAID1).
Thus far, I've yet to see machines w/ RAID5 or RAID6 exhibit the same crash.
- Gilboa
5 p.m.
On 08.06.2014 11:11, Gilboa Davara wrote:
On Fri, Jun 6, 2014 at 1:28 AM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
>
> sadly both re-opened today, after some hours of
> running shutdown and raid-check with 3.14 is a
> pain and taht is *for sure* 3.14.x because my
> co-developer stayed at the last 3.13 until i
> thought it's fine now, had never that problems
> and both 3.14.x shutdowns freezed with mdraid
I can confirm the above on two machines w/ MD RAID10 (and boot on MD RAID1).
Thus far, I've yet to see machines w/ RAID5 or RAID6 exhibit the same crash.
- Gilboa
According[1] to NeilBrown it's resolved and applied in the 3.14.6[2].
If the problem is still present, you can continue the discussion on
linux-raid(a)vger.kernel.org[3].
Don't forget to CC here, or vice versa.
poma
[1] http://marc.info/?l=linux-raid&m=140062838306788
[2] https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.14.6
[3] http://vger.kernel.org/vger-lists.html#linux-raid
5:05 p.m.
Am 11.06.2014 00:00, schrieb poma:
On 08.06.2014 11:11, Gilboa Davara wrote:
> On Fri, Jun 6, 2014 at 1:28 AM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
>>
>> sadly both re-opened today, after some hours of
>> running shutdown and raid-check with 3.14 is a
>> pain and taht is *for sure* 3.14.x because my
>> co-developer stayed at the last 3.13 until i
>> thought it's fine now, had never that problems
>> and both 3.14.x shutdowns freezed with mdraid
>
> I can confirm the above on two machines w/ MD RAID10 (and boot on MD RAID1).
>
> Thus far, I've yet to see machines w/ RAID5 or RAID6 exhibit the same crash.
>
> - Gilboa
According[1] to NeilBrown it's resolved and applied in the 3.14.6[2].
If the problem is still present, you can continue the discussion on
linux-raid(a)vger.kernel.org[3].
Don't forget to CC here, or vice versa.
i really stressed my office-machine over the last few days by
move many gigabytes of data while raid-ckechk was running and
*both* issues (the frezze at raid-check and hang at shutdown)
seems to be fixed with 3.14.6
well, since i closed both reported bugs with 3.14.5 followed by
re-open both with a few hours i will look at that a few days
however, since 3.13 was EOL there was nothing really wrong with
the updates push given the the security relevant fixes and using
kernels from koji over years the first time with real troubles
is not that bad
1:27 a.m.
New subject: :-( Re: F20 Kernel 3.14.x / raid-check and freezes
On Sun, Jun 8, 2014 at 12:11 PM, Gilboa Davara <gilboad(a)gmail.com> wrote:
On Fri, Jun 6, 2014 at 1:28 AM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
>
> sadly both re-opened today, after some hours of
> running shutdown and raid-check with 3.14 is a
> pain and taht is *for sure* 3.14.x because my
> co-developer stayed at the last 3.13 until i
> thought it's fine now, had never that problems
> and both 3.14.x shutdowns freezed with mdraid
I can confirm the above on two machines w/ MD RAID10 (and boot on MD RAID1).
Thus far, I've yet to see machines w/ RAID5 or RAID6 exhibit the same crash.
- Gilboa
I'm currently running a full RAID check on 8TB RAID10 volume w/ 3.14.6.
Thus far, everything seems to be working just fine (knock wood).
- Gilboa
3598
days inactive
3641
days old
kernel@lists.fedoraproject.org
13 comments
4 participants
participants (4)
-
Bruno Wolff III -
Gilboa Davara -
poma -
Reindl Harald