FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux General Discussion

 
 
LinkBack Thread Tools
 
Old 06-16-2012, 05:00 PM
Victor Silva
 
Default Shutdown and reboot not working after last weekend update

2012/6/15 Victor Silva <vfbsilva@gmail.com>

>
>
> 2012/6/15 Don deJuan <donjuansjiz@gmail.com>
>
>> On 06/15/2012 02:48 PM, Victor Silva wrote:
>>
>>> 2012/6/15 Don deJuan <donjuansjiz@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?
 
Old 06-16-2012, 05:00 PM
Victor Silva
 
Default Shutdown and reboot not working after last weekend update

2012/6/15 Victor Silva <vfbsilva@gmail.com>

>
>
> 2012/6/15 Don deJuan <donjuansjiz@gmail.com>
>
>> On 06/15/2012 02:48 PM, Victor Silva wrote:
>>
>>> 2012/6/15 Don deJuan <donjuansjiz@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?
 
Old 06-16-2012, 10:40 PM
Victor Silva
 
Default Shutdown and reboot not working after last weekend update

2012/6/16 Victor Silva <vfbsilva@gmail.com>

> 2012/6/15 Victor Silva <vfbsilva@gmail.com>
>
>>
>>
>> 2012/6/15 Don deJuan <donjuansjiz@gmail.com>
>>
>>> On 06/15/2012 02:48 PM, Victor Silva wrote:
>>>
>>>> 2012/6/15 Don deJuan <donjuansjiz@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
 
Old 06-16-2012, 10:40 PM
Victor Silva
 
Default Shutdown and reboot not working after last weekend update

2012/6/16 Victor Silva <vfbsilva@gmail.com>

> 2012/6/15 Victor Silva <vfbsilva@gmail.com>
>
>>
>>
>> 2012/6/15 Don deJuan <donjuansjiz@gmail.com>
>>
>>> On 06/15/2012 02:48 PM, Victor Silva wrote:
>>>
>>>> 2012/6/15 Don deJuan <donjuansjiz@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
 
Old 06-16-2012, 10:40 PM
Victor Silva
 
Default Shutdown and reboot not working after last weekend update

2012/6/16 Victor Silva <vfbsilva@gmail.com>

> 2012/6/15 Victor Silva <vfbsilva@gmail.com>
>
>>
>>
>> 2012/6/15 Don deJuan <donjuansjiz@gmail.com>
>>
>>> On 06/15/2012 02:48 PM, Victor Silva wrote:
>>>
>>>> 2012/6/15 Don deJuan <donjuansjiz@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
 
Old 06-16-2012, 10:40 PM
Victor Silva
 
Default Shutdown and reboot not working after last weekend update

2012/6/16 Victor Silva <vfbsilva@gmail.com>

> 2012/6/15 Victor Silva <vfbsilva@gmail.com>
>
>>
>>
>> 2012/6/15 Don deJuan <donjuansjiz@gmail.com>
>>
>>> On 06/15/2012 02:48 PM, Victor Silva wrote:
>>>
>>>> 2012/6/15 Don deJuan <donjuansjiz@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
 
Old 06-18-2012, 05:33 AM
Victor Silva
 
Default Shutdown and reboot not working after last weekend update

2012/6/16 Victor Silva <vfbsilva@gmail.com>

>
>
> 2012/6/16 Victor Silva <vfbsilva@gmail.com>
>
>> 2012/6/15 Victor Silva <vfbsilva@gmail.com>
>>
>>>
>>>
>>> 2012/6/15 Don deJuan <donjuansjiz@gmail.com>
>>>
>>>> On 06/15/2012 02:48 PM, Victor Silva wrote:
>>>>
>>>>> 2012/6/15 Don deJuan <donjuansjiz@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?
 
Old 06-18-2012, 06:51 AM
Victor Silva
 
Default Shutdown and reboot not working after last weekend update

2012/6/18 Victor Silva <vfbsilva@gmail.com>

>
>
> 2012/6/16 Victor Silva <vfbsilva@gmail.com>
>
>>
>>
>> 2012/6/16 Victor Silva <vfbsilva@gmail.com>
>>
>>> 2012/6/15 Victor Silva <vfbsilva@gmail.com>
>>>
>>>>
>>>>
>>>> 2012/6/15 Don deJuan <donjuansjiz@gmail.com>
>>>>
>>>>> On 06/15/2012 02:48 PM, Victor Silva wrote:
>>>>>
>>>>>> 2012/6/15 Don deJuan <donjuansjiz@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.
 
Old 06-20-2012, 02:40 AM
Victor Silva
 
Default Shutdown and reboot not working after last weekend update

2012/6/18 Victor Silva <vfbsilva@gmail.com>

>
>
> 2012/6/18 Victor Silva <vfbsilva@gmail.com>
>
>>
>>
>> 2012/6/16 Victor Silva <vfbsilva@gmail.com>
>>
>>>
>>>
>>> 2012/6/16 Victor Silva <vfbsilva@gmail.com>
>>>
>>>> 2012/6/15 Victor Silva <vfbsilva@gmail.com>
>>>>
>>>>>
>>>>>
>>>>> 2012/6/15 Don deJuan <donjuansjiz@gmail.com>
>>>>>
>>>>>> On 06/15/2012 02:48 PM, Victor Silva wrote:
>>>>>>
>>>>>>> 2012/6/15 Don deJuan <donjuansjiz@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?
 
Old 07-01-2012, 03:56 PM
Victor Silva
 
Default Shutdown and reboot not working after last weekend update

2012/6/19 Victor Silva <vfbsilva@gmail.com>

>
>
> 2012/6/18 Victor Silva <vfbsilva@gmail.com>
>
>>
>>
>> 2012/6/18 Victor Silva <vfbsilva@gmail.com>
>>
>>>
>>>
>>> 2012/6/16 Victor Silva <vfbsilva@gmail.com>
>>>
>>>>
>>>>
>>>> 2012/6/16 Victor Silva <vfbsilva@gmail.com>
>>>>
>>>>> 2012/6/15 Victor Silva <vfbsilva@gmail.com>
>>>>>
>>>>>>
>>>>>>
>>>>>> 2012/6/15 Don deJuan <donjuansjiz@gmail.com>
>>>>>>
>>>>>>> On 06/15/2012 02:48 PM, Victor Silva wrote:
>>>>>>>
>>>>>>>> 2012/6/15 Don deJuan <donjuansjiz@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
 

Thread Tools




All times are GMT. The time now is 01:31 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org