[opensuse] Segmentation fault
Today after a big update, I was surprised with a segmentation fault after I started Software Management in Yast. The information shown is: YaST got signal 11 at YCP file /usr/share/YaST2/clients/sw_single.ycp:138 /sbin/yast2: line 431: 4549 Segmentation fault $ybindir/y2base $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2UI_ARGS Also every zypper command ends with segmentation fault. Could somebody show me a way to solve this problem? -- Linux User 183145 using KDE4 on a Pentium IV , powered by openSUSE 12.3 (i586) Kernel: 3.7.10-1.4-default KDE Development Platform: 4.10.3 "release 1" 20:49pm up 0:25, 3 users, load average: 0.64, 1.07, 1.08 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Constant Brouerius van Nidek wrote:
Today after a big update, I was surprised with a segmentation fault after I started Software Management in Yast. The information shown is:
YaST got signal 11 at YCP file /usr/share/YaST2/clients/sw_single.ycp:138 /sbin/yast2: line 431: 4549 Segmentation fault $ybindir/y2base $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2UI_ARGS
Also every zypper command ends with segmentation fault.
Could somebody show me a way to solve this problem?
To begin with, which openSUSE version are you running? -- Per Jessen, Zürich (0.0°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Saturday, June 22, 2013 04:50:08 PM Per Jessen wrote:
Constant Brouerius van Nidek wrote:
Today after a big update, I was surprised with a segmentation fault after I started Software Management in Yast. The information shown is:
YaST got signal 11 at YCP file /usr/share/YaST2/clients/sw_single.ycp:138 /sbin/yast2: line 431: 4549 Segmentation fault $ybindir/y2base $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2UI_ARGS
Also every zypper command ends with segmentation fault.
Could somebody show me a way to solve this problem?
To begin with, which openSUSE version are you running?
openSUSE 12.3 (i586) Kernel: 3.7.10-1.4-default KDE Development Platform: 4.10.3 "release 1" -- Linux User 183145 using KDE4 on a Pentium IV , powered by openSUSE 12.3 (i586) Kernel: 3.7.10-1.4-default KDE Development Platform: 4.10.3 "release 1" 22:52pm up 0:45, 3 users, load average: 0.45, 0.46, 0.45 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Saturday, June 22, 2013 04:40:25 PM Cristian Rodríguez wrote:
El 22/06/13 10:06, Constant Brouerius van Nidek escribió:
Today after a big update,
From where you updated exactly ?
Zypper up from: zypper lr # | Alias | Name | Enabled | Refresh ---+-----------------------------------+-----------------------------------------+---------+-------- 1 | download.opensuse.org-Extra | openSUSE BuildService - KDE:Extra | Yes | Yes 2 | download.opensuse.org-Stable | openSUSE BuildService - LibreOffice | Yes | Yes 3 | download.opensuse.org-UpdatedApps | openSUSE BuildService - KDE:UpdatedApps | Yes | Yes 4 | download.opensuse.org-games | openSUSE BuildService - Games | Yes | Yes 5 | download.opensuse.org-lxde | openSUSE BuildService - LXDE | Yes | Yes 6 | ftp.gwdg.de-suse | Packman Repository | Yes | Yes 7 | openSUSE-12.3-1.7 | openSUSE-12.3-1.7 | No | No 8 | repo-debug | openSUSE-12.3-Debug | No | No 9 | repo-debug-update | openSUSE-12.3-Update-Debug | No | No 10 | repo-debug-update-non-oss | openSUSE-12.3-Update-Debug-Non-Oss | No | No 11 | repo-non-oss | openSUSE-12.3-Non-Oss | Yes | Yes 12 | repo-oss | openSUSE-12.3-Oss | Yes | Yes 13 | repo-source | openSUSE-12.3-Source | No | No 14 | repo-update | openSUSE-12.3-Update | Yes | Yes 15 | repo-update-non-oss | openSUSE-12.3-Update-Non-Oss | Yes | Yes -- Linux User 183145 using KDE4 and LXDE on a Pentium IV , powered by openSUSE 12.3 (i586) Kernel: 3.7.10-1.16-default KDE Development Platform: 4.10.3 "release 1" 10:28am up 0:19, 3 users, load average: 3.06, 3.86, 2.92 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Saturday, June 22, 2013 04:40:25 PM Cristian Rodríguez wrote:
El 22/06/13 10:06, Constant Brouerius van Nidek escribió:
Today after a big update,
From where you updated exactly ?
Additional info. Just got the following reaction from zypper up. Left the KDE GUI and produced information beginning with BUG: unable to handle kernel paging request at 76beb088 Ctrl Alt Del brought me back to init 3 and no further damage seem to be done. -- Linux User 183145 using KDE4 and LXDE on a Pentium IV , powered by openSUSE 12.3 (i586) Kernel: 3.7.10-1.16-default KDE Development Platform: 4.10.3 "release 1" 10:30am up 0:22, 3 users, load average: 2.69, 3.37, 2.86 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 22/06/13 23:36, Constant Brouerius van Nidek escribió:
BUG: unable to handle kernel paging request at 76beb088
That explains it.. there are two possibilities here: a) In the last round of updates, you got a buggy kernel update with a regression or .. b) if there was no kernel update, your system's RAM is likely broken, to discard this possibility run memtest. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sunday, June 23, 2013 12:23:47 AM Cristian Rodríguez wrote:
El 22/06/13 23:36, Constant Brouerius van Nidek escribió:
BUG: unable to handle kernel paging request at 76beb088
That explains it.. there are two possibilities here:
a) In the last round of updates, you got a buggy kernel update with a regression or ..
b) if there was no kernel update, your system's RAM is likely broken, to discard this possibility run memtest.
It seems to be indeed my system RAM. Ran the memtest and it remained stuck at test 5 telling me that it found : "Unexpected Interrupt-Halting". Do not know what that exactly means and what has gone bad. Memory or the main board? What to do next to find the precise reason of the segfaulting? -- Linux User 183145 using KDE4 and LXDE on a Pentium IV , powered by openSUSE 12.3 (i586) Kernel: 3.7.10-1.16-default KDE Development Platform: 4.10.3 "release 1" 13:14pm up 0:26, 2 users, load average: 1.00, 0.75, 0.82 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/23/2013 02:23 AM, Constant Brouerius van Nidek wrote:
Memory or the main board?
Hard to tell from here, if you can test the memory in a different box .. My bet the problem is not on the motherboard though. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/23/2013 08:23 AM, Constant Brouerius van Nidek wrote:
Memory or the main board?
i'd suspect RAM first
What to do next to find the precise reason of the segfaulting?
1. boot from a known good Linux live CD. if it boots and runs ok for a half-hour or so (do some browsing, video watching, etc) you probably do not have a hardware problem.. but, if that same disk/medium will boot and run on another system then you probably do have some sort of hardware flake (maybe RAM, maybe not).. [note: successfully booting and running any version is MS-Windows will _not_ prove a lot about faulty RAM] 2. you have not described your hardware, but if it is not a laptop and you can (and are competent to) disconnect the power, [before proceeding read the caveat in my sig!] remove cabinet side(s) top/bottom (etc) as required to access the RAM sticks... GROUND yourself to the chassis and then unlock and remove the RAM sticks (how many do you have?) a. carefully use a soft pencil eraser to 'polish' the gold colored contacts of the RAM stick(s), and then without touching them again with your bare fingers, soft cloth wipe to remove all vestiges of eraser bits and then reinstall the RAM stick(s) into the motherboard slots. b. run Memtest again.. (hmmmm...i think i recall the 12.2 install media had a buggy Memtest, if you used that one, DON'T! use 12.3 or 12.1 or any other Linux boot disk..) if it has not thrown an error in about 12 hours you have probably solved your "RAM problem" c. but, if Memtest errors then remove all but one RAM stick and leave that one in slot #1 (see owner manual), and run Memtest again.. d. if that errors, then remove that RAM stick, lay it aside as a possible bad stick and put another in the same #1 slot..and run memtest again.. e. do that until you find one RAM stick that does not error during (12 hours of) Memtest OR all of the memory sticks are in the suspected RAM pile--in which case the problem is _probably_ either the #1 slot or the motherboard.. f. read your owner manual to learn if the machine should run with only the (say) #2 (or other) slot filled....if so, populate that other slot only and run memtest g. if all RAM sticks also seem to fail in the #2 slot you are (i think) pretty much assured you have a hardware problem more serious than just "bad RAM" and a qualified technician/shop is probably your next best step. dd http://tinyurl.com/DD-Caveat -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sunday, June 23, 2013 08:55:43 AM DenverD wrote:
On 06/23/2013 08:23 AM, Constant Brouerius van Nidek wrote:
Memory or the main board?
i'd suspect RAM first
What to do next to find the precise reason of the segfaulting?
1. boot from a known good Linux live CD. if it boots and runs ok for a half-hour or so (do some browsing, video watching, etc) you probably do not have a hardware problem..
All my live cd's seem to have gone bad. The only dvd and cd that boot are a net 12.3 cd and the 12.3 dvd. Booth have the memtest86= VERSION 4.20 which I used.
but, if that same disk/medium will boot and run on another system then you probably do have some sort of hardware flake (maybe RAM, maybe not).. [note: successfully booting and running any version is MS-Windows will _not_ prove a lot about faulty RAM]
2. you have not described your hardware, but if it is not a laptop and you can (and are competent to) disconnect the power, [before proceeding read the caveat in my sig!] remove cabinet side(s) top/bottom (etc) as required to access the RAM sticks... GROUND yourself to the chassis and then unlock and remove the RAM sticks (how many do you have?)
Asrock motherboard with two memory slots and two sticks, 512 and 10xx M
a. carefully use a soft pencil eraser to 'polish' the gold colored contacts of the RAM stick(s), and then without touching them again with your bare fingers, soft cloth wipe to remove all vestiges of eraser bits and then reinstall the RAM stick(s) into the motherboard slots.
Used the pencil eraser and cleaned the bar ram. Reinstalled and ran the memtest again. Result, bad ram beginning at 1024 up to above 1080. No time today to wait for the end address :(.
b. run Memtest again.. (hmmmm...i think i recall the 12.2 install media had a buggy Memtest, if you used that one, DON'T! use 12.3 or 12.1 or any other Linux boot disk..) if it has not thrown an error in about 12 hours you have probably solved your "RAM problem"
Could download and burn on a rewritable cd the memtest86+ iso. But which version should I look for? 4.20 seems to be the latest. Version 5 is in beta.
c. but, if Memtest errors then remove all but one RAM stick and leave that one in slot #1 (see owner manual), and run Memtest again..
d. if that errors, then remove that RAM stick, lay it aside as a possible bad stick and put another in the same #1 slot..and run memtest again..
e. do that until you find one RAM stick that does not error during (12 hours of) Memtest OR all of the memory sticks are in the suspected RAM pile--in which case the problem is _probably_ either the #1 slot or the motherboard..
f. read your owner manual to learn if the machine should run with only the (say) #2 (or other) slot filled....if so, populate that other slot only and run memtest
Owner manual is not specific about the slot.
g. if all RAM sticks also seem to fail in the #2 slot you are (i think) pretty much assured you have a hardware problem more serious than just "bad RAM" and a qualified technician/shop is probably your next best step.
Qualification is problematic where I live. Could try to exchange the bad stick at the seller but I doubt that they will be open to that suggestion. Think of a lifetime guarantee as valid up to installation in your computer ;). Would like to first look into Badram and Memmap solutions. The DDR1 sticks are not that easy to get here and the supply will be at least time consuming.
Like your DD-Caveat :) -- Linux User 183145 using KDE4 and LXDE on a Pentium IV , powered by openSUSE 12.3 (i586) Kernel: 3.9.6-13.g8ead728-default KDE Development Platform: 4.10.3 "release 1" 14:34pm up 1:57, 3 users, load average: 0.72, 0.46, 0.42 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/24/2013 09:56 AM, C. Brouerius van Nidek wrote:
All my live cd's seem to have gone bad.
that might indicate you have a DVD/CD reader writer which is going bad...they DO wear out. if in a smokey or dusty environment it might be helpful to use a commercially available cleaning disk, using the wetting solution provided with the disk.
The only dvd and cd that boot are a net 12.3 cd and the 12.3 dvd. Booth have the memtest86= VERSION 4.20 which I used.
those are GOOD to use.
remove the RAM sticks (how many do you have?)
Asrock motherboard with two memory slots and two sticks, 512 and 10xx M
that does not sound good to me, and it _may_ be your problem.. i've not had a Asrock motherboard in a while but when i did it required _matched_ RAM sticks, that is TWO 512s, or TWO 1 Gigs, etc..
Used the pencil eraser and cleaned the bar ram. Reinstalled and ran the memtest again. Result, bad ram beginning at 1024 up to above 1080. No time today to wait for the end address :(.
so, what happens if you run just ONE of the sticks? and, then run the other, alone?
Qualification is problematic where I live. Could try to exchange the bad stick at the seller
have you identified "the bad stick"? it may not be 'bad' but rather just 'wrong' not every stick which will fit in the slot can be used--you must read the owner manual to know precisely which sticks of which sizes and speeds will work correctly with your motherboard.....and, as mentioned above, you might have two perfectly good sticks if used alone, but which will not work together!
Would like to first look into Badram and Memmap solutions.
do as you wish with those, i know nothing about them. in my opinion, based on the info you have provided so far i would guess the problem is likely to be mis-matched ram sticks...the motherboard owner manual should precisely identify what sticks are usable, and in what combinations. dd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Monday, June 24, 2013 11:14:37 AM you wrote:
On 06/24/2013 09:56 AM, C. Brouerius van Nidek wrote:
All my live cd's seem to have gone bad.
that might indicate you have a DVD/CD reader writer which is going bad...they DO wear out. if in a smokey or dusty environment it might be helpful to use a commercially available cleaning disk, using the wetting solution provided with the disk.
As a vivid cigar smoker I know the effects of a smokey environment :) , just did that but no success. Perhaps some cheapo cd's.
The only dvd and cd that boot are a net 12.3 cd and the 12.3 dvd. Booth have the memtest86= VERSION 4.20 which I used.
those are GOOD to use.
remove the RAM sticks (how many do you have?)
Asrock motherboard with two memory slots and two sticks, 512 and 10xx M
that does not sound good to me, and it _may_ be your problem.. i've not had a Asrock motherboard in a while but when i did it required _matched_ RAM sticks, that is TWO 512s, or TWO 1 Gigs, etc..
The manual expressively informs the user that if you want to use dual channel memory technology, two identical sticks (same brand, speed, size and chip- type) should be used. Otherwise the computer will operate at single channel mode.
Used the pencil eraser and cleaned the bar ram. Reinstalled and ran the memtest again. Result, bad ram beginning at 1024 up to above 1080. No time today to wait for the end address :(.
so, what happens if you run just ONE of the sticks? and, then run the other, alone?
Qualification is problematic where I live. Could try to exchange the bad stick at the seller
have you identified "the bad stick"?
it may not be 'bad' but rather just 'wrong' not every stick which will fit in the slot can be used--you must read the owner manual to know precisely which sticks of which sizes and speeds will work correctly with your motherboard.....and, as mentioned above, you might have two perfectly good sticks if used alone, but which will not work together!
I have in the mean time run memtest in slot 1 and 2 with the 3 chips I have and they turn out to be all okay. If I put the 1M chip in slot 1, add the 500K in slot 2 the memtest stops and hangs at test 5. It seems these 2 chips do not cooperate very well. Now put a 250K in slot 2 and memtest sees no problems whatsoever. Will run memtest the night over and see if something new pops up. Segfaults have gone and the system seems to work for now. Thanks for the help, Constant -- Linux User 183145 using KDE4 and LXDE on a Pentium IV , powered by openSUSE 12.3 (i586) Kernel: 3.9.6-13.g8ead728-default KDE Development Platform: 4.10.3 "release 1" 20:47pm up 0:23, 4 users, load average: 0.66, 0.56, 0.59 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/24/2013 04:08 PM, C. Brouerius van Nidek wrote:
Segfaults have gone and the system seems to work for now. Thanks for the help,
happy to be helpful.. dd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 6/24/2013 7:08 AM, C. Brouerius van Nidek wrote:
As a vivid cigar smoker
I assume you meant avid, because if you meant vivid I would be tempted to ask you just what is in those cigars... -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Monday, June 24, 2013 10:41:52 AM John Andersen wrote:
On 6/24/2013 7:08 AM, C. Brouerius van Nidek wrote:
As a vivid cigar smoker
I assume you meant avid, because if you meant vivid I would be tempted to ask you just what is in those cigars...
You are absolute right :) Had to look it up in a dictionary though. Was planning to write "passionate" but being in a lazy mood I made the wrong choice of words. It is pure local tabacco :( -- Linux User 183145 using KDE4 and LXDE on a Pentium IV , powered by openSUSE 12.3 (i586) Kernel: 3.9.7-14.gfccf19c-default KDE Development Platform: 4.10.3 "release 1" 16:48pm up 12:06, 3 users, load average: 1.08, 0.53, 0.46 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/24/2013 01:41 PM, John Andersen pecked at the keyboard and wrote:
On 6/24/2013 7:08 AM, C. Brouerius van Nidek wrote:
As a vivid cigar smoker
I assume you meant avid, because if you meant vivid I would be tempted to ask you just what is in those cigars...
And where they were purchased. :-) -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tuesday, June 25, 2013 01:17:41 PM Ken Schneider - openSUSE wrote:
On 06/24/2013 01:41 PM, John Andersen pecked at the keyboard and wrote:
On 6/24/2013 7:08 AM, C. Brouerius van Nidek wrote:
As a vivid cigar smoker
I assume you meant avid, because if you meant vivid I would be tempted to ask you just what is in those cigars...
And where they were purchased. :-)
Home production :D -- Linux User 183145 using KDE4 and LXDE on a Pentium IV , powered by openSUSE 12.3 (i586) Kernel: 3.7.10-1.16-default KDE Development Platform: 4.10.3 "release 1" 21:32pm up 7:48, 2 users, load average: 0.40, 0.42, 0.46 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Cristian Rodr�������������������������������� wrote:
El 22/06/13 23:36, Constant Brouerius van Nidek escribi�:
BUG: unable to handle kernel paging request at 76beb088
That explains it.. there are two possibilities here:
a) In the last round of updates, you got a buggy kernel update with a regression or ..
b) if there was no kernel update, your system's RAM is likely broken, to discard this possibility run memtest.
I just got a kernel fault today as well but mine was an unspecified error in one of the disk subsystems First got a message one of the worker threads was hung and all the things that locks were in: [25586.642767] INFO: task kworker/9:2:821 blocked for more than 120 seconds. [25586.649641] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [25586.657593] kworker/9:2 D ffff880613e28000 4744 821 2 0x00000000 [25586.657604] ffff88060c393c68 0000000000000046 ffff88060c393fd8 00000000001d3a00 [25586.657609] ffff88060c393fd8 00000000001d3a00 ffff8806124222f0 ffff880617bcfc20 [25586.657626] ffff8806101781a8 [25586.657627] ffff8806124222f0 [25586.657628] 0000000000000000 [25586.657628] 0000000000000009 [25586.657630] Call Trace: [25586.657639] [<ffffffff815d2834>] schedule+0x24/0x70 [25586.657648] [<ffffffff81292360>] _xfs_log_force_lsn+0x2f0/0x330 [25586.657655] [<ffffffff810742c0>] ? try_to_wake_up+0x350/0x350 [25586.657660] [<ffffffff8128e6db>] xfs_trans_commit+0x24b/0x260 [25586.657666] [<ffffffff8123d9cb>] xfs_fs_log_dummy+0x5b/0x70 [25586.657672] [<ffffffff81292060>] xfs_log_worker+0x40/0x50 [25586.657682] [<ffffffff8105bb48>] process_one_work+0x1f8/0x570 [25586.657686] [<ffffffff8105bae6>] ? process_one_work+0x196/0x570 [25586.657690] [<ffffffff8105d49b>] worker_thread+0x11b/0x3b0 [25586.657693] [<ffffffff8105d380>] ? manage_workers+0x370/0x370 [25586.657698] [<ffffffff81062279>] kthread+0xd9/0xe0 [25586.657702] [<ffffffff810621a0>] ? kthread_stop+0x160/0x160 [25586.657705] [<ffffffff815db46c>] ret_from_fork+0x7c/0xb0 [25586.657728] [<ffffffff810621a0>] ? kthread_stop+0x160/0x160 [25586.657732] 2 locks held by kworker/9:2/821: [25586.657743] #0: (xfs-log/%s){......}, at: [<ffffffff8105bae6>] process_one_work+0x196/0x570 [25586.657755] #1: ((&(&log->l_work)->work)){......}, at: [<ffffffff8105bae6>] process_one_work+0x196/0x 570 [25586.657775] INFO: task smbd:3469 blocked for more than 120 seconds. [25586.657777] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [25586.657785] smbd D ffffffff81a10440 2848 3469 3292 0x00000000 [25586.657799] ffff880bfcd0d730 0000000000000046 ffff880bfcd0dfd8 00000000001d3a00 [25586.657811] ffff880bfcd0dfd8 00000000001d3a00 ffff880c11c3c5e0 7fffffffffffffff [25586.657818] ffff8805fb171930 0000000000000002 0000000000000000 ffff880c11c3c5e0 [25586.657819] Call Trace: [25586.657821] [<ffffffff815d2834>] schedule+0x24/0x70 [25586.657824] [<ffffffff815cf539>] schedule_timeout+0x229/0x320 Ishtar:law> dmesg|grep 25586 >/tmp/file Ishtar:law> cat /tmp/file [25586.642767] INFO: task kworker/9:2:821 blocked for more than 120 seconds. [25586.649641] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [25586.657593] kworker/9:2 D ffff880613e28000 4744 821 2 0x00000000 [25586.657604] ffff88060c393c68 0000000000000046 ffff88060c393fd8 00000000001d3a00 [25586.657609] ffff88060c393fd8 00000000001d3a00 ffff8806124222f0 ffff880617bcfc20 [25586.657626] ffff8806101781a8 [25586.657627] ffff8806124222f0 [25586.657628] 0000000000000000 [25586.657628] 0000000000000009 [25586.657630] Call Trace: [25586.657639] [<ffffffff815d2834>] schedule+0x24/0x70 [25586.657648] [<ffffffff81292360>] _xfs_log_force_lsn+0x2f0/0x330 [25586.657655] [<ffffffff810742c0>] ? try_to_wake_up+0x350/0x350 [25586.657660] [<ffffffff8128e6db>] xfs_trans_commit+0x24b/0x260 [25586.657666] [<ffffffff8123d9cb>] xfs_fs_log_dummy+0x5b/0x70 [25586.657672] [<ffffffff81292060>] xfs_log_worker+0x40/0x50 [25586.657682] [<ffffffff8105bb48>] process_one_work+0x1f8/0x570 [25586.657686] [<ffffffff8105bae6>] ? process_one_work+0x196/0x570 [25586.657690] [<ffffffff8105d49b>] worker_thread+0x11b/0x3b0 [25586.657693] [<ffffffff8105d380>] ? manage_workers+0x370/0x370 [25586.657698] [<ffffffff81062279>] kthread+0xd9/0xe0 [25586.657702] [<ffffffff810621a0>] ? kthread_stop+0x160/0x160 [25586.657705] [<ffffffff815db46c>] ret_from_fork+0x7c/0xb0 [25586.657728] [<ffffffff810621a0>] ? kthread_stop+0x160/0x160 [25586.657732] 2 locks held by kworker/9:2/821: [25586.657743] #0: (xfs-log/%s){......}, at: [<ffffffff8105bae6>] process_one_work+0x196/0x570 [25586.657755] #1: ((&(&log->l_work)->work)){......}, at: [<ffffffff8105bae6>] process_one_work+0x196/0x570 [25586.657775] INFO: task smbd:3469 blocked for more than 120 seconds. [25586.657777] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [25586.657785] smbd D ffffffff81a10440 2848 3469 3292 0x00000000 [25586.657799] ffff880bfcd0d730 0000000000000046 ffff880bfcd0dfd8 00000000001d3a00 [25586.657811] ffff880bfcd0dfd8 00000000001d3a00 ffff880c11c3c5e0 7fffffffffffffff [25586.657818] ffff8805fb171930 0000000000000002 0000000000000000 ffff880c11c3c5e0 [25586.657819] Call Trace: [25586.657821] [<ffffffff815d2834>] schedule+0x24/0x70 [25586.657824] [<ffffffff815cf539>] schedule_timeout+0x229/0x320 [25586.657827] [<ffffffff81092e3e>] ? put_lock_stats.isra.22+0xe/0x40 [25586.657829] [<ffffffff81092fae>] ? lock_release_holdtime.part.23+0x13e/0x180 [25586.657831] [<ffffffff81071fad>] ? get_parent_ip+0xd/0x50 [25586.657833] [<ffffffff815d1110>] __down_common+0xa5/0xf8 [25586.657836] [<ffffffff81236525>] ? _xfs_buf_find+0x165/0x2e0 [25586.657837] [<ffffffff815d11c2>] __down+0x18/0x1a [25586.657839] [<ffffffff81067ecc>] down+0x3c/0x50 [25586.657841] [<ffffffff812362a7>] xfs_buf_lock+0x37/0x150 [25586.657842] [<ffffffff81236525>] _xfs_buf_find+0x165/0x2e0 [25586.657844] [<ffffffff812366c5>] xfs_buf_get_map+0x25/0x250 [25586.657847] [<ffffffff812977b1>] xfs_trans_get_buf_map+0x111/0x1d0 [25586.657849] [<ffffffff8126f0fc>] xfs_da_get_buf+0x8c/0xc0 [25586.657852] [<ffffffff81255853>] xfs_attr_leaf_create+0x43/0x180 [25586.657854] [<ffffffff812589a5>] xfs_attr_shortform_to_leaf+0x185/0x310 [25586.657855] [<ffffffff8124d1a7>] ? kmem_zone_alloc+0x67/0xf0 [25586.657857] [<ffffffff8124d256>] ? kmem_zone_zalloc+0x26/0x30 [25586.657859] [<ffffffff81254aaa>] xfs_attr_set_int+0x35a/0x430 [25586.657860] [<ffffffff81254bff>] xfs_attr_set+0x7f/0x90 [25586.657862] [<ffffffff8129b2c4>] xfs_set_acl+0xb4/0x200 [25586.657864] [<ffffffff8129ba38>] xfs_inherit_acl+0x98/0xc0 [25586.657866] [<ffffffff81243e5a>] xfs_vn_mknod+0xda/0x1a0 [25586.657868] [<ffffffff81243f4e>] xfs_vn_create+0xe/0x10 [25586.657871] [<ffffffff81163835>] vfs_create+0x95/0xd0 [25586.657872] [<ffffffff811640a3>] do_last.isra.52+0x833/0xd00 [25586.657874] [<ffffffff81165dba>] path_openat.isra.53+0xaa/0x4d0 [25586.657876] [<ffffffff810943bf>] ? __lock_acquire.isra.30+0x30f/0xa70 [25586.657878] [<ffffffff810943bf>] ? __lock_acquire.isra.30+0x30f/0xa70 [25586.657880] [<ffffffff81076475>] ? sched_clock_cpu+0xb5/0x100 [25586.657882] [<ffffffff81167483>] do_filp_open+0x33/0x80 [25586.657884] [<ffffffff815d3ddc>] ? _raw_spin_unlock+0x2c/0x50 [25586.657887] [<ffffffff811747bf>] ? __alloc_fd+0x10f/0x140 [25586.657889] [<ffffffff811578b0>] do_sys_open+0xe0/0x1c0 [25586.657891] [<ffffffff811579ac>] sys_open+0x1c/0x20 [25586.657892] [<ffffffff815db512>] system_call_fastpath+0x16/0x1b [25586.657893] 4 locks held by smbd/3469: [25586.657898] #0: (sb_writers#3){......}, at: [<ffffffff8117690f>] mnt_want_write+0x1f/0x50 [25586.657901] #1: (&type->i_mutex_dir_key){......}, at: [<ffffffff81163b6f>] do_last.isra.52+0x2ff/0xd00 [25586.657904] #2: (sb_internal){......}, at: [<ffffffff8128d69f>] xfs_trans_alloc+0x1f/0x40 [25586.657908] #3: (&(&ip->i_lock)->mr_lock){......}, at: [<ffffffff8127f312>] xfs_ilock+0x112/0x140 [25586.657912] INFO: task squid:5743 blocked for more than 120 seconds. [25586.657913] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [25586.657916] squid D ffff880c1320c5e0 4480 5743 5741 0x00000000 [25586.657918] ffff880bf8fd7b00 0000000000000046 ffff880bf8fd7fd8 00000000001d3a00 [25586.657920] ffff880bf8fd7fd8 00000000001d3a00 ffff880bfbff22f0 7fffffffffffffff [25586.657922] ffff88060cb02330 0000000000000002 0000000000000000 ffff880bfbff22f0 [25586.657922] Call Trace: [25586.657924] [<ffffffff815d2834>] schedule+0x24/0x70 [25586.657926] [<ffffffff815cf539>] schedule_timeout+0x229/0x320 [25586.657928] [<ffffffff81092e3e>] ? put_lock_stats.isra.22+0xe/0x40 [25586.657929] [<ffffffff81092fae>] ? lock_release_holdtime.part.23+0x13e/0x180 [25586.657931] [<ffffffff81071fad>] ? get_parent_ip+0xd/0x50 [25586.657932] [<ffffffff815d1110>] __down_common+0xa5/0xf8 [25586.657934] [<ffffffff81236525>] ? _xfs_buf_find+0x165/0x2e0 [25586.657935] [<ffffffff815d11c2>] __down+0x18/0x1a [25586.657937] [<ffffffff81067ecc>] down+0x3c/0x50 [25586.657938] [<ffffffff812362a7>] xfs_buf_lock+0x37/0x150 [25586.657940] [<ffffffff81236525>] _xfs_buf_find+0x165/0x2e0 [25586.657942] [<ffffffff812366c5>] xfs_buf_get_map+0x25/0x250 [25586.657943] [<ffffffff81237597>] xfs_buf_read_map+0x27/0x1b0 [25586.657945] [<ffffffff81297cb9>] xfs_trans_read_buf_map+0x2b9/0x540 [25586.657946] [<ffffffff8126f550>] xfs_da_read_buf+0xb0/0x200 [25586.657948] [<ffffffff810764ff>] ? local_clock+0x3f/0x50 [25586.657950] [<ffffffff8127287b>] xfs_dir2_block_read+0x2b/0x30 [25586.657952] [<ffffffff8127349e>] xfs_dir2_block_getdents+0x5e/0x1e0 [25586.657953] [<ffffffff81169fa0>] ? filldir64+0xf0/0xf0 [25586.657955] [<ffffffff81169fa0>] ? filldir64+0xf0/0xf0 [25586.657956] [<ffffffff81271ea8>] xfs_readdir+0x118/0x160 [25586.657958] [<ffffffff81169fa0>] ? filldir64+0xf0/0xf0 [25586.657959] [<ffffffff8123abe0>] xfs_file_readdir+0x30/0x40 [25586.657961] [<ffffffff81169da2>] vfs_readdir+0xa2/0xe0 [25586.657963] [<ffffffff8116a181>] sys_getdents+0x81/0x100 [25586.657964] [<ffffffff815db512>] system_call_fastpath+0x16/0x1b [25586.657965] 1 lock held by squid/5743: [25586.657968] #0: (&type->i_mutex_dir_key){......}, at: [<ffffffff81169d6a>] vfs_readdir+0x6a/0xe0 [25586.657985] INFO: task find:34976 blocked for more than 120 seconds. [25586.657986] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [25586.657989] find D ffff880c131f22f0 5096 34976 34971 0x00000000 [25586.657991] ffff8806089b78e0 0000000000000046 ffff8806089b7fd8 00000000001d3a00 [25586.657993] ffff8806089b7fd8 00000000001d3a00 ffff8806084545e0 7fffffffffffffff [25586.657994] ffff880608544188 ffff880608544180 ffff8806084545e0 ffff8806121d2840 [25586.657995] Call Trace: [25586.657997] [<ffffffff815d2834>] schedule+0x24/0x70 [25586.657998] [<ffffffff815cf539>] schedule_timeout+0x229/0x320 [25586.658000] [<ffffffff81092e3e>] ? put_lock_stats.isra.22+0xe/0x40 [25586.658002] [<ffffffff81092fae>] ? lock_release_holdtime.part.23+0x13e/0x180 [25586.658003] [<ffffffff81071fad>] ? get_parent_ip+0xd/0x50 [25586.658005] [<ffffffff815d1a74>] wait_for_completion+0x94/0x110 [25586.658007] [<ffffffff810742c0>] ? try_to_wake_up+0x350/0x350 [25586.658008] [<ffffffff81237562>] ? _xfs_buf_read+0x32/0x40 [25586.658010] [<ffffffff8123736e>] xfs_buf_iowait+0x2e/0x130 [25586.658012] [<ffffffff81297cb9>] ? xfs_trans_read_buf_map+0x2b9/0x540 [25586.658013] [<ffffffff81237562>] _xfs_buf_read+0x32/0x40 [25586.658015] [<ffffffff81237689>] xfs_buf_read_map+0x119/0x1b0 [25586.658016] [<ffffffff81297cb9>] xfs_trans_read_buf_map+0x2b9/0x540 [25586.658018] [<ffffffff8127fd09>] xfs_imap_to_bp+0x59/0xc0 [25586.658020] [<ffffffff81283675>] xfs_iread+0x65/0x160 [25586.658021] [<ffffffff8123f0ac>] xfs_iget+0x34c/0x990 [25586.658023] [<ffffffff8123ee94>] ? xfs_iget+0x134/0x990 [25586.658025] [<ffffffff8124b226>] xfs_lookup+0x106/0x130 [25586.658026] [<ffffffff81244159>] xfs_vn_lookup+0x49/0x90 [25586.658028] [<ffffffff81161a28>] lookup_real+0x18/0x50 [25586.658030] [<ffffffff811624be>] __lookup_hash+0x2e/0x40 [25586.658032] [<ffffffff815cb36f>] lookup_slow+0x3f/0xa4 [25586.658033] [<ffffffff81166a59>] path_lookupat+0x779/0x7e0 [25586.658036] [<ffffffff8112345d>] ? handle_pte_fault+0x8d/0x850 [25586.658040] [<ffffffff811496e8>] ? kmem_cache_alloc+0x28/0x160 [25586.658041] [<ffffffff8116304d>] ? final_putname+0x1d/0x40 [25586.658043] [<ffffffff81166ae1>] filename_lookup.isra.44+0x21/0x60 [25586.658044] [<ffffffff811673ff>] user_path_at_empty+0x4f/0x90 [25586.658047] [<ffffffff815d772c>] ? __do_page_fault+0x1ec/0x5f0 [25586.658049] [<ffffffff8106a233>] ? lg_local_unlock+0x33/0x60 [25586.658051] [<ffffffff8116744c>] user_path_at+0xc/0x10 [25586.658052] [<ffffffff8115cc9d>] vfs_fstatat+0x4d/0xa0 [25586.658054] [<ffffffff8115d225>] sys_newfstatat+0x15/0x40 [25586.658057] [<ffffffff81300a3e>] ? trace_hardirqs_on_thunk+0x3a/0x3f [25586.658059] [<ffffffff815db512>] system_call_fastpath+0x16/0x1b [25586.658060] 1 lock held by find/34976: [25586.658062] #0: (&type->i_mutex_dir_key){......}, at: [<ffffffff815cb360>] lookup_slow+0x30/0xa4 =============================== That caused everything on the system to lockup... and caused a reset to the controller on sda: [25632.193805] sd 0:2:0:0: [sda] megasas: RESET cmd=8a retries=0 [25632.193812] megasas: [ 0]waiting for 1 commands to complete [25633.195216] megaraid_sas: no pending cmds after reset [25633.195222] megasas: reset successful [25633.204745] smbd (3469) used greatest stack depth: 2848 bytes left --- Then sys went back to normal. I just upgraded from 3.9.6 -> 3.9.7 (linux kernel). Didn't bother to wonder about it until I saw this message. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (8)
-
C. Brouerius van Nidek -
Constant Brouerius van Nidek -
Cristian Rodríguez -
DenverD -
John Andersen -
Ken Schneider - openSUSE -
Linda Walsh -
Per Jessen