[arch-general] Shutdown and reboot not working after last weekend update
Victor Silva
vfbsilva at gmail.com
Mon Jun 18 02:51:27 EDT 2012
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.
More information about the arch-general
mailing list