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

Mon Jun 18 01:33:05 EDT 2012

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?