[arch-general] Shutdown and reboot not working after last weekend update

Sun Jul 1 12:09:34 EDT 2012

2012/7/1 Victor Silva <vfbsilva at gmail.com>

>
>
> 2012/6/19 Victor Silva <vfbsilva at gmail.com>
>
>>
>>
>> 2012/6/18 Victor Silva <vfbsilva at gmail.com>
>>
>>>
>>>
>>> 2012/6/18 Victor Silva <vfbsilva at gmail.com>
>>>
>>>>
>>>>
>>>> 2012/6/16 Victor Silva <vfbsilva at gmail.com>
>>>>
>>>>>
>>>>>
>>>>> 2012/6/16 Victor Silva <vfbsilva at gmail.com>
>>>>>
>>>>>> 2012/6/15 Victor Silva <vfbsilva at gmail.com>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2012/6/15 Don deJuan <donjuansjiz at gmail.com>
>>>>>>>
>>>>>>>> On 06/15/2012 02:48 PM, Victor Silva wrote:
>>>>>>>>
>>>>>>>>> 2012/6/15 Don deJuan <donjuansjiz at gmail.com>
>>>>>>>>>
>>>>>>>>>  On 06/15/2012 08:29 AM, David C. Rankin wrote:
>>>>>>>>>>
>>>>>>>>>>  On 06/14/2012 03:12 PM, Victor Silva wrote:
>>>>>>>>>>>
>>>>>>>>>>>  I have no shares. Can I somehow try to umount everything in
>>>>>>>>>>>> mtab? I'm not
>>>>>>>>>>>> familiar with the internal workings of mtab. I will read a bit.
>>>>>>>>>>>> Also the
>>>>>>>>>>>> only thing I assume could be hanging is my external HD which I
>>>>>>>>>>>> disconnected
>>>>>>>>>>>> having no effect on the problem behavior. Still I reported that
>>>>>>>>>>>> my /boot
>>>>>>>>>>>> partition was being mounted and listed on kde file manager
>>>>>>>>>>>> (forgot its
>>>>>>>>>>>> name) which was not default behavior. So could be the case that
>>>>>>>>>>>> /boot is
>>>>>>>>>>>> hanging my shoutdown? I don't get the reason umount -a &&
>>>>>>>>>>>> shutdown -h now
>>>>>>>>>>>> did not do the trick.
>>>>>>>>>>>>
>>>>>>>>>>>> I ask gently again if you could inform me why did the "magic
>>>>>>>>>>>> reboot" did
>>>>>>>>>>>> work while shutdown did not.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Victor
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> Victor,
>>>>>>>>>>>
>>>>>>>>>>>   I am no expert in the shutdown logic that Arch uses, but it is
>>>>>>>>>>> fairly
>>>>>>>>>>> easy to follow. During shutdown, /etc/rc.shutdown is called and
>>>>>>>>>>> the
>>>>>>>>>>> 'umount_all' command is supposed to take care of unmounting all
>>>>>>>>>>> non-api
>>>>>>>>>>> filesystems. If you have specific commands you need run in
>>>>>>>>>>> _addition to_
>>>>>>>>>>> what is done by rc.shutdown, then you can put those commands in
>>>>>>>>>>> /etc/rc.local.shutdown. The /etc/rc.local.shutdown must be
>>>>>>>>>>> executable to
>>>>>>>>>>> be called (chmod +x) or (chmod 0755). The rc.local.shutdown file
>>>>>>>>>>> is
>>>>>>>>>>> called close to the beginning of rc.shutdown.
>>>>>>>>>>>
>>>>>>>>>>>   Looking at your mtab file and comparing to mine, I do not have
>>>>>>>>>>> any
>>>>>>>>>>> usb drives connected to my system. Somebody more familiar with
>>>>>>>>>>> issues
>>>>>>>>>>> related to usb drives will need to comment. You might want to try
>>>>>>>>>>> Guillermo's shutdown modified as follows:
>>>>>>>>>>>
>>>>>>>>>>> umount -arfl -t usbfs,fuseblk
>>>>>>>>>>>
>>>>>>>>>>>   I don't know if that will do it, but you have 5 fuseblk
>>>>>>>>>>> filesystems
>>>>>>>>>>> and 1 usbfs mounted. I don't know how Arch handles their
>>>>>>>>>>> unmounting.
>>>>>>>>>>>
>>>>>>>>>>>   Lastly, I do not use the gnome gvfs-fuse-daemon. That is
>>>>>>>>>>> another
>>>>>>>>>>> entry to look at and make sure it isn't the issue. Maybe try your
>>>>>>>>>>> rc.local.shutdown with:
>>>>>>>>>>>
>>>>>>>>>>> umount -arfl -t usbfs,fuseblk
>>>>>>>>>>> killall gvfs-fuse-daemon  # or whatever that process actually
>>>>>>>>>>> runs as
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  Well just tried reinstalling made no difference. So I guess I
>>>>>>>>>> will be
>>>>>>>>>> looking it why it is starting that way. It may or may not be
>>>>>>>>>> related to the
>>>>>>>>>> shutdown issues. But other than this one thing my symptoms seem
>>>>>>>>>> to match
>>>>>>>>>> this minus the screen turning red when freezing. I will post back
>>>>>>>>>> here if I
>>>>>>>>>> sort anything out that may help this problem.
>>>>>>>>>>
>>>>>>>>>> I wil try this at home but I'1m at work atm,
>>>>>>>>>>
>>>>>>>>> https://bugs.archlinux.org/**task/30136<https://bugs.archlinux.org/task/30136>
>>>>>>>>> ry this kernel paramether reboot=pci
>>>>>>>>> More info:
>>>>>>>>> http://intosimple.blogspot.**com.br/2012/06/reboot-on-dell-**
>>>>>>>>> latitude-e6520-with-arch.html<http://intosimple.blogspot.com.br/2012/06/reboot-on-dell-latitude-e6520-with-arch.html>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> After reading more into that parameter I found this
>>>>>>>> http://linux.koolsolutions.**com/2009/08/04/howto-fix-**
>>>>>>>> linux-hangfreeze-during-**reboots-and-restarts/<http://linux.koolsolutions.com/2009/08/04/howto-fix-linux-hangfreeze-during-reboots-and-restarts/>
>>>>>>>>
>>>>>>>> They show more options. I am going to try the one you suggested
>>>>>>>> shortly and if that does not work do the other suggested option in the link
>>>>>>>> I posted. Thanks for pointing out your findings.
>>>>>>>>
>>>>>>>> A new kernel update was avaliable fo me today. I hoped it could fix
>>>>>>> some of the issues we were facing. In fact now I have tons of errors, dbus
>>>>>>> seems screwd and many other things, among the problems I have now is that X
>>>>>>> fails with no screen found (both nv and nvidia drivers)  and I have no
>>>>>>> network interfaces I fail to get eth0 up. So
>>>>>>> *DO NOT UPDATE YOUR KERNELS
>>>>>>> *I'm quite sad as this is a even bigger mistake than the last one.
>>>>>>> So I think I need to chroot again rever to the old kernel...
>>>>>>> Anyone else expecting this kind of problem?
>>>>>>> Btw the reboor parameters for the kernel (which I've tested before
>>>>>>> the upgrade) also did not work.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Victor
>>>>>>>
>>>>>>> I solved many issues still when I try to boot now I get the
>>>>>> following errors:
>>>>>>
>>>>>> *Jun 16 13:55:48 localhost kernel: [   10.463651] microcode: failed
>>>>>> to load file amd-ucode/microcode_amd.bin
>>>>>> Jun 16 13:55:48 localhost kernel: [   10.464913] microcode: failed to
>>>>>> load file amd-ucode/microcode_amd.bin
>>>>>> Jun 16 13:55:48 localhost kernel: [   10.466051] microcode: failed to
>>>>>> load file amd-ucode/microcode_amd.bin
>>>>>> Jun 16 13:55:48 localhost kernel: [   10.467189] microcode: failed to
>>>>>> load file amd-ucode/microcode_amd.bin
>>>>>> Jun 16 13:55:48 localhost kernel: [   10.468305] microcode: failed to
>>>>>> load file amd-ucode/microcode_amd.bin
>>>>>> Jun 16 13:55:48 localhost kernel: [   10.469389] microcode: failed to
>>>>>> load file amd-ucode/microcode_amd.bin
>>>>>> Jun 16 13:55:48 localhost kernel: [   11.920779] sd 6:0:0:0: [sdc] No
>>>>>> Caching mode page present
>>>>>> Jun 16 13:55:48 localhost kernel: [   11.920880] sd 6:0:0:0: [sdc]
>>>>>> Assuming drive cache: write through
>>>>>> Jun 16 13:55:48 localhost kernel: [   11.924824] sd 6:0:0:0: [sdc] No
>>>>>> Caching mode page present
>>>>>> Jun 16 13:55:48 localhost kernel: [   11.924924] sd 6:0:0:0: [sdc]
>>>>>> Assuming drive cache: write through
>>>>>> Jun 16 13:55:48 localhost kernel: [   11.931887] sd 6:0:0:0: [sdc] No
>>>>>> Caching mode page present
>>>>>> Jun 16 13:55:48 localhost kernel: [   11.931982] sd 6:0:0:0: [sdc]
>>>>>> Assuming drive cache: write through
>>>>>> *
>>>>>> Are my kernel sources messed? I'm still unable the shutdown. Anyone
>>>>>> got any ideas which can help? :(
>>>>>>
>>>>> I've solved this issue by adding microcode to modules array in rc.conf
>>>>> thou I've never used this before. Still I'm unable to shutdown.
>>>>>
>>>>> Regards,
>>>>> Victor
>>>>>
>>>> Folks I'm still investigating the issue. After I try to reboot kernel
>>>> log gave me this hint:
>>>> Jun 18 02:30:48 localhost kernel: [  600.432301] "echo 0 >
>>>> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>>>> Jun 18 02:30:48 localhost kernel: [  600.432303] shutdown        D
>>>> 0000000000000001     0  2902   2897 0x00000000
>>>> Jun 18 02:30:48 localhost kernel: [  600.432305]  ffff8801c39fbe30
>>>> 0000000000000086 ffff8801ca2cafa0 ffff8801c39fbfd8
>>>> Jun 18 02:30:48 localhost kernel: [  600.432308]  ffff8801c39fbfd8
>>>> ffff8801c39fbfd8 ffff880199ae07f0 ffff8801ca2cafa0
>>>> Jun 18 02:30:48 localhost kernel: [  600.432310]  0007ffffffffffff
>>>> ffff880222b0ee00 0000000000000000 0000000000000000
>>>> Jun 18 02:30:48 localhost kernel: [  600.432312] Call Trace:
>>>> Jun 18 02:30:48 localhost kernel: [  600.432315]  [<ffffffff81084c22>]
>>>> ? default_wake_function+0x12/0x20
>>>> Jun 18 02:30:48 localhost kernel: [  600.432317]  [<ffffffff8119c3b0>]
>>>> ? __sync_filesystem+0x90/0x90
>>>> Jun 18 02:30:48 localhost kernel: [  600.432319]  [<ffffffff81222f38>]
>>>> ? blk_finish_plug+0x18/0x50
>>>> Jun 18 02:30:48 localhost kernel: [  600.432321]  [<ffffffff814689c9>]
>>>> schedule+0x29/0x70
>>>> Jun 18 02:30:48 localhost kernel: [  600.432323]  [<ffffffff81469455>]
>>>> rwsem_down_failed_common+0xc5/0x160
>>>> Jun 18 02:30:48 localhost kernel: [  600.432325]  [<ffffffff81117d22>]
>>>> ? do_writepages+0x22/0x50
>>>> Jun 18 02:30:48 localhost kernel: [  600.432327]  [<ffffffff8119c3b0>]
>>>> ? __sync_filesystem+0x90/0x90
>>>> Jun 18 02:30:48 localhost kernel: [  600.432329]  [<ffffffff81469525>]
>>>> rwsem_down_read_failed+0x15/0x17
>>>> Jun 18 02:30:48 localhost kernel: [  600.432331]  [<ffffffff8124afc4>]
>>>> call_rwsem_down_read_failed+0x14/0x30
>>>> Jun 18 02:30:48 localhost kernel: [  600.432333]  [<ffffffff814678a7>]
>>>> ? down_read+0x17/0x20
>>>> Jun 18 02:30:48 localhost kernel: [  600.432335]  [<ffffffff81171db0>]
>>>> iterate_supers+0x80/0xf0
>>>> Jun 18 02:30:48 localhost kernel: [  600.432337]  [<ffffffff8119c4e0>]
>>>> sys_sync+0x30/0x70
>>>> Jun 18 02:30:48 localhost kernel: [  600.432338]  [<ffffffff8146a7a9>]
>>>> system_call_fastpath+0x16/0x1b
>>>>
>>>> Google came up with:
>>>> http://www.gossamer-threads.com/lists/linux/kernel/1306758
>>>>
>>>> Can it be the same semaphore issue?
>>>>
>>>
>>> A guy pinpointed to a pattern on the forums:
>>> *
>>> *
>>> *arti74 wrote:*
>>>
>>> *What I've noticed yet - htop shows 100% CPU usage on that command:
>>> /bin/mount -o realtime /dev/sda4 /mnt/usbhd-sda4  - I can't kill it,
>>> shutdown or reboot can't kill it either.
>>> Interesting thing is, that I don't have sda4 partition at all. My fstab:
>>> *
>>>
>>> *# /etc/fstab: static file system information.
>>> #
>>> # <file system> <mount point>   <type>  <options>       <dump>  <pass>*
>>>
>>> *devpts    /dev/pts    devpts    defaults    0    0
>>> /dev/sda2    /            ext4            defaults    0    1
>>> /dev/sda6    /home    ext4            defaults    0    1
>>> /dev/sdb1    /mnt/FA    auto
>>>  defaults,nosuid,nodev,uhelper=udisks,uid=1000,gid=100,dmask=0077,fmask=0177
>>>   0    0
>>> /dev/sda3    /var            reiserfs    defaults    0    1
>>> shm    /dev/shm            tmpfs    nodev,nosuid    0    0*
>>>
>>> *uname -r
>>> 3.4.2-2-ARCH*
>>>
>>> I have the SAME problem so it seems we discovered what is wrong. No
>>> ideas about how to fix thou.
>>>
>> Has the new kernel update fixed the issue?
>>
> After the last update with 3.4.4-2-ARCH #1 SMP PREEMPT Sun Jun 24 18:59:47
> CEST 2012 x86_64 GNU/Linux
>
> rules seem to be working again :)
>
It works but again I have a core stuck in 100% use. renice did not solve
the trick. Any ideas?