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