2012/7/1 Victor Silva <vfbsilva@xxxxxxxxx> > > > 2012/6/19 Victor Silva <vfbsilva@xxxxxxxxx> > >> >> >> 2012/6/18 Victor Silva <vfbsilva@xxxxxxxxx> >> >>> >>> >>> 2012/6/18 Victor Silva <vfbsilva@xxxxxxxxx> >>> >>>> >>>> >>>> 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? >>>> >>> >>> A guy pinpointed to a pattern on the forums: >>> * >>> * >>> *arti74 wrote:* >>> >>> *What I've noticed yet - htop shows 100% CPU usage on that command: >>> /bin/mount -o realtime /dev/sda4 /mnt/usbhd-sda4 - I can't kill it, >>> shutdown or reboot can't kill it either. >>> Interesting thing is, that I don't have sda4 partition at all. My fstab: >>> * >>> >>> *# /etc/fstab: static file system information. >>> # >>> # <file system> <mount point> <type> <options> <dump> <pass>* >>> >>> *devpts /dev/pts devpts defaults 0 0 >>> /dev/sda2 / ext4 defaults 0 1 >>> /dev/sda6 /home ext4 defaults 0 1 >>> /dev/sdb1 /mnt/FA auto >>> defaults,nosuid,nodev,uhelper=udisks,uid=1000,gid=100,dmask=0077,fmask=0177 >>> 0 0 >>> /dev/sda3 /var reiserfs defaults 0 1 >>> shm /dev/shm tmpfs nodev,nosuid 0 0* >>> >>> *uname -r >>> 3.4.2-2-ARCH* >>> >>> I have the SAME problem so it seems we discovered what is wrong. No >>> ideas about how to fix thou. >>> >> Has the new kernel update fixed the issue? >> > After the last update with 3.4.4-2-ARCH #1 SMP PREEMPT Sun Jun 24 18:59:47 > CEST 2012 x86_64 GNU/Linux > > rules seem to be working again :) > It works but again I have a core stuck in 100% use. renice did not solve the trick. Any ideas?
