3.15-rc1: Endless "Disabling PPGTT because VT-d is on" messages in /var/log/messages
[hoping I persuaded gmail to get my old text-only email settings back, grrr] Noticed that my root fs was filling up, and found out that /var/log/messages was approaching 2GB of space, most of which were as per $subject. To give an idea of the magnitude, here's a snippet from a saved sample of /var/log/messages: [root@xbox log]# grep "Disabling PP" messages.save.head |head -1 Apr 15 03:44:10 xbox kernel: [3.115126] [drm] Disabling PPGTT because VT-d is on [root@xbox log]# grep "Disabling PP" messages.save.head |tail -1 Apr 15 03:45:50 xbox kernel: [ 130.165219] [drm] Disabling PPGTT because VT-d is on [root@xbox log]# grep -c "Disabling PP" messages.save.head 610 Or from the dmesg ring: [root@xbox log]# dmesg|head [22446.690572] [drm] Disabling PPGTT because VT-d is on [22446.690616] [drm] Disabling PPGTT because VT-d is on [22446.704560] [drm] Disabling PPGTT because VT-d is on [22446.706747] [drm] Disabling PPGTT because VT-d is on [22446.720202] [drm] Disabling PPGTT because VT-d is on [22446.722447] [drm] Disabling PPGTT because VT-d is on [22446.724850] [drm] Disabling PPGTT because VT-d is on [22446.727268] [drm] Disabling PPGTT because VT-d is on [22446.733052] [drm] Disabling PPGTT because VT-d is on [22446.735319] [drm] Disabling PPGTT because VT-d is on Are there patches for this issue, or is a workaround available to prevent a filesystem full condition on my root fs? This is on a Dell Latitude E6420 laptop, Fedora 19 x86_64, onboard Intel video card... yes, I have an old A08 BIOS, but I've never seen this issue while regularly updating my mainline kernel weekly or so... Available for more details if needed, thanks in advance, --alessandro "don't underestimate the things that I will do" (Adele, "Rolling In The Deep") -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
3.15-rc1: Endless Disabling PPGTT because VT-d is on messages in /var/log/messages
[hoping I persuaded gmail to get my old text-only email settings back, grrr] Noticed that my root fs was filling up, and found out that /var/log/messages was approaching 2GB of space, most of which were as per $subject. To give an idea of the magnitude, here's a snippet from a saved sample of /var/log/messages: [root@xbox log]# grep Disabling PP messages.save.head |head -1 Apr 15 03:44:10 xbox kernel: [3.115126] [drm] Disabling PPGTT because VT-d is on [root@xbox log]# grep Disabling PP messages.save.head |tail -1 Apr 15 03:45:50 xbox kernel: [ 130.165219] [drm] Disabling PPGTT because VT-d is on [root@xbox log]# grep -c Disabling PP messages.save.head 610 Or from the dmesg ring: [root@xbox log]# dmesg|head [22446.690572] [drm] Disabling PPGTT because VT-d is on [22446.690616] [drm] Disabling PPGTT because VT-d is on [22446.704560] [drm] Disabling PPGTT because VT-d is on [22446.706747] [drm] Disabling PPGTT because VT-d is on [22446.720202] [drm] Disabling PPGTT because VT-d is on [22446.722447] [drm] Disabling PPGTT because VT-d is on [22446.724850] [drm] Disabling PPGTT because VT-d is on [22446.727268] [drm] Disabling PPGTT because VT-d is on [22446.733052] [drm] Disabling PPGTT because VT-d is on [22446.735319] [drm] Disabling PPGTT because VT-d is on Are there patches for this issue, or is a workaround available to prevent a filesystem full condition on my root fs? This is on a Dell Latitude E6420 laptop, Fedora 19 x86_64, onboard Intel video card... yes, I have an old A08 BIOS, but I've never seen this issue while regularly updating my mainline kernel weekly or so... Available for more details if needed, thanks in advance, --alessandro don't underestimate the things that I will do (Adele, Rolling In The Deep) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2: wpa_supplicant BUGs kernel in rwlock recursion
On Feb 17, 2008 12:18 AM, Guillaume Chazarain <[EMAIL PROTECTED]> wrote: > On Feb 16, 2008 6:14 PM, Alessandro Suardi <[EMAIL PROTECTED]> wrote: > > Feb 16 16:51:49 sandman kernel: BUG: rwlock recursion on CPU#0, > > Same thing here, bisected it to: > > commit 45b503548210fe6f23e92b856421c2a3f05fd034 > Author: Laszlo Attila Toth balabit.hu> > Date: Tue Feb 12 22:42:09 2008 -0800 > > [RTNETLINK]: Send a single notification on device state changes. > > The revert applies cleanly and fixes the problem. > Rafael has more details in http://lkml.org/lkml/2008/2/15/542. Thanks Guillaume, I can confirm that the revert of the rtnetlink.c changes does indeed fix the problem for me. Second time in a couple of week I hit the same bugs as Rafael, will keep an eye on his new findings ;) --alessandro "We act as though comfort and luxury were the chief requirements of life, when all that we need to make us really happy is something to be enthusiastic about." (Charles Kingsley) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2: wpa_supplicant BUGs kernel in rwlock recursion
On Feb 16, 2008 6:14 PM, Alessandro Suardi <[EMAIL PROTECTED]> wrote: > Fedora 8 / x86, Dell D610, ipw2200 > > testcase: Forgot to mention that this is 100% reproducable. > 1. boot into runlevel 3 > 2. log on as root on tty1 > 3. start wpa_supplicant > > 2.6.25-rc1-git4 is okay > 2.6.25-rc2 BUGs dumping stack on console, but nothing gets in > /var/log/messages > 2.6.25-rc2-git1 BUGs dumping stack on console, ONLY this in /var/log/messages: > > Feb 16 16:51:49 sandman kernel: BUG: rwlock recursion on CPU#0, > wpa_supplicant/2342, c0440220 > > Will now look for changes between -rc1-git4 and -rc2... .config files > are the same for the two kernels, and available if needed. > > I might be able to provide full stack via netconsole, but there's some work > to do to set it up. OK, here goes netconsole output, hoping GMail doesn't munge it too much... Feb 16 20:13:01 sandman kernel: BUG: rwlock recursion on CPU#0, wpa_supplicant/2243, c0440220 Feb 16 20:13:01 sandman kernel: Pid: 2243, comm: wpa_supplicant Not tainted 2.6.25-rc2-git1 #2 Feb 16 20:13:01 sandman kernel: [] rwlock_bug+0x36/0x40 Feb 16 20:13:01 sandman kernel: [] _raw_write_lock+0x2e/0x54 Feb 16 20:13:01 sandman kernel: [] _write_lock_bh+0x12/0x15 Feb 16 20:13:01 sandman kernel: [] do_setlink+0x2ad/0x325 Feb 16 20:13:01 sandman kernel: [] rtnl_setlink+0xc9/0xe7 Feb 16 20:13:01 sandman kernel: [] ? rtnl_setlink+0x0/0xe7 Feb 16 20:13:01 sandman kernel: [] rtnetlink_rcv_msg+0x195/0x1af Feb 16 20:13:01 sandman kernel: [] ? rtnetlink_rcv_msg+0x0/0x1af Feb 16 20:13:01 sandman kernel: [] netlink_rcv_skb+0x30/0x82 Feb 16 20:13:01 sandman kernel: [] rtnetlink_rcv+0x17/0x1f Feb 16 20:13:01 sandman kernel: [] netlink_unicast+0x1b8/0x21c Feb 16 20:13:01 sandman kernel: [] netlink_sendmsg+0x25b/0x268 Feb 16 20:13:01 sandman kernel: [] sock_sendmsg+0xdd/0xf8 Feb 16 20:13:01 sandman kernel: [] ? autoremove_wake_function+0x0/0x33 Feb 16 20:13:01 sandman kernel: [] ? __link_path_walk+0x97c/0xa96 Feb 16 20:13:01 sandman kernel: [] sys_sendto+0xa4/0xc3 Feb 16 20:13:01 sandman kernel: [] ? find_lock_page+0x6e/0x75 Feb 16 20:13:01 sandman kernel: [] ? filemap_fault+0x18f/0x2ee Feb 16 20:13:01 sandman kernel: [] ? unlock_page+0x24/0x27 Feb 16 20:13:01 sandman kernel: [] ? __do_fault+0x303/0x341 Feb 16 20:13:01 sandman kernel: [] ? generic_drop_inode+0x133/0x137 Feb 16 20:13:01 sandman kernel: [] sys_send+0x18/0x1a Feb 16 20:13:01 sandman kernel: [] sys_socketcall+0xe6/0x186 Feb 16 20:13:01 sandman kernel: [] syscall_call+0x7/0xb Feb 16 20:13:01 sandman kernel: === Feb 16 20:13:01 sandman kernel: BUG: sleeping function called from invalid context at mm/slab.c:3055 Feb 16 20:13:01 sandman kernel: in_atomic():1, irqs_disabled():0 Feb 16 20:13:01 sandman kernel: Pid: 2243, comm: wpa_supplicant Not tainted 2.6.25-rc2-git1 #2 Feb 16 20:13:01 sandman kernel: [] __might_sleep+0x97/0x9e Feb 16 20:13:01 sandman kernel: [] kmem_cache_alloc+0x22/0x8e Feb 16 20:13:01 sandman kernel: [] __alloc_skb+0x2c/0xf8 Feb 16 20:13:01 sandman kernel: [] rtmsg_ifinfo+0x36/0xb4 Feb 16 20:13:01 sandman kernel: [] netdev_state_change+0x29/0x2c Feb 16 20:13:01 sandman kernel: [] do_setlink+0x30e/0x325 Feb 16 20:13:01 sandman kernel: [] rtnl_setlink+0xc9/0xe7 Feb 16 20:13:01 sandman kernel: [] ? rtnl_setlink+0x0/0xe7 Feb 16 20:13:01 sandman kernel: [] rtnetlink_rcv_msg+0x195/0x1af Feb 16 20:13:01 sandman kernel: [] ? rtnetlink_rcv_msg+0x0/0x1af Feb 16 20:13:01 sandman kernel: [] netlink_rcv_skb+0x30/0x82 Feb 16 20:13:01 sandman kernel: [] rtnetlink_rcv+0x17/0x1f Feb 16 20:13:01 sandman kernel: [] netlink_unicast+0x1b8/0x21c Feb 16 20:13:01 sandman kernel: [] netlink_sendmsg+0x25b/0x268 Feb 16 20:13:01 sandman kernel: [] sock_sendmsg+0xdd/0xf8 Feb 16 20:13:01 sandman kernel: [] ? autoremove_wake_function+0x0/0x33 Feb 16 20:13:01 sandman kernel: [] ? __link_path_walk+0x97c/0xa96 Feb 16 20:13:01 sandman kernel: [] sys_sendto+0xa4/0xc3 Feb 16 20:13:01 sandman kernel: [] ? find_lock_page+0x6e/0x75 Feb 16 20:13:01 sandman kernel: [] ? filemap_fault+0x18f/0x2ee Feb 16 20:13:01 sandman kernel: [] ? unlock_page+0x24/0x27 Feb 16 20:13:01 sandman kernel: [] ? __do_fault+0x303/0x341 Feb 16 20:13:01 sandman kernel: [] ? generic_drop_inode+0x133/0x137 Feb 16 20:13:01 sandman kernel: [] sys_send+0x18/0x1a Feb 16 20:13:01 sandman kernel: [] sys_socketcall+0xe6/0x186 Feb 16 20:13:01 sandman kernel: [] syscall_call+0x7/0xb Feb 16 20:13:01 sandman kernel: === Feb 16 20:13:01 sandman kernel: BUG: scheduling while atomic: wpa_supplicant/2243/0x1200 Feb 16 20:13:01 sandman kernel: Pid: 2243, comm: wpa_supplicant Not tainted 2.6.25-rc2-git1 #2 Feb 16 20:13:01 sandman kernel: [] __schedule_bug+0x42/0x47 Feb 16 20:13:01 sandman kernel: [] schedule+0x42/0x24c Feb 16 20:13:01 sandman kernel: [] __cond_resched+0x25/0x3b Feb 16 20:13:01 sandman
2.6.25-rc2: wpa_supplicant BUGs kernel in rwlock recursion
Fedora 8 / x86, Dell D610, ipw2200 testcase: 1. boot into runlevel 3 2. log on as root on tty1 3. start wpa_supplicant 2.6.25-rc1-git4 is okay 2.6.25-rc2 BUGs dumping stack on console, but nothing gets in /var/log/messages 2.6.25-rc2-git1 BUGs dumping stack on console, ONLY this in /var/log/messages: Feb 16 16:51:49 sandman kernel: BUG: rwlock recursion on CPU#0, wpa_supplicant/2342, c0440220 Will now look for changes between -rc1-git4 and -rc2... .config files are the same for the two kernels, and available if needed. I might be able to provide full stack via netconsole, but there's some work to do to set it up. thanks, --alessandro "We act as though comfort and luxury were the chief requirements of life, when all that we need to make us really happy is something to be enthusiastic about." (Charles Kingsley) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.25-rc2: wpa_supplicant BUGs kernel in rwlock recursion
Fedora 8 / x86, Dell D610, ipw2200 testcase: 1. boot into runlevel 3 2. log on as root on tty1 3. start wpa_supplicant 2.6.25-rc1-git4 is okay 2.6.25-rc2 BUGs dumping stack on console, but nothing gets in /var/log/messages 2.6.25-rc2-git1 BUGs dumping stack on console, ONLY this in /var/log/messages: Feb 16 16:51:49 sandman kernel: BUG: rwlock recursion on CPU#0, wpa_supplicant/2342, c0440220 Will now look for changes between -rc1-git4 and -rc2... .config files are the same for the two kernels, and available if needed. I might be able to provide full stack via netconsole, but there's some work to do to set it up. thanks, --alessandro We act as though comfort and luxury were the chief requirements of life, when all that we need to make us really happy is something to be enthusiastic about. (Charles Kingsley) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2: wpa_supplicant BUGs kernel in rwlock recursion
On Feb 16, 2008 6:14 PM, Alessandro Suardi [EMAIL PROTECTED] wrote: Fedora 8 / x86, Dell D610, ipw2200 testcase: Forgot to mention that this is 100% reproducable. 1. boot into runlevel 3 2. log on as root on tty1 3. start wpa_supplicant 2.6.25-rc1-git4 is okay 2.6.25-rc2 BUGs dumping stack on console, but nothing gets in /var/log/messages 2.6.25-rc2-git1 BUGs dumping stack on console, ONLY this in /var/log/messages: Feb 16 16:51:49 sandman kernel: BUG: rwlock recursion on CPU#0, wpa_supplicant/2342, c0440220 Will now look for changes between -rc1-git4 and -rc2... .config files are the same for the two kernels, and available if needed. I might be able to provide full stack via netconsole, but there's some work to do to set it up. OK, here goes netconsole output, hoping GMail doesn't munge it too much... Feb 16 20:13:01 sandman kernel: BUG: rwlock recursion on CPU#0, wpa_supplicant/2243, c0440220 Feb 16 20:13:01 sandman kernel: Pid: 2243, comm: wpa_supplicant Not tainted 2.6.25-rc2-git1 #2 Feb 16 20:13:01 sandman kernel: [c01df8e8] rwlock_bug+0x36/0x40 Feb 16 20:13:01 sandman kernel: [c01dfbe2] _raw_write_lock+0x2e/0x54 Feb 16 20:13:01 sandman kernel: [c032857f] _write_lock_bh+0x12/0x15 Feb 16 20:13:01 sandman kernel: [c02b5506] do_setlink+0x2ad/0x325 Feb 16 20:13:01 sandman kernel: [c02b6505] rtnl_setlink+0xc9/0xe7 Feb 16 20:13:01 sandman kernel: [c02b643c] ? rtnl_setlink+0x0/0xe7 Feb 16 20:13:01 sandman kernel: [c02b62b4] rtnetlink_rcv_msg+0x195/0x1af Feb 16 20:13:01 sandman kernel: [c02b611f] ? rtnetlink_rcv_msg+0x0/0x1af Feb 16 20:13:01 sandman kernel: [c02bb98c] netlink_rcv_skb+0x30/0x82 Feb 16 20:13:01 sandman kernel: [c02b6117] rtnetlink_rcv+0x17/0x1f Feb 16 20:13:01 sandman kernel: [c02bb76f] netlink_unicast+0x1b8/0x21c Feb 16 20:13:01 sandman kernel: [c02bbf3a] netlink_sendmsg+0x25b/0x268 Feb 16 20:13:01 sandman kernel: [c02a4801] sock_sendmsg+0xdd/0xf8 Feb 16 20:13:01 sandman kernel: [c0125a15] ? autoremove_wake_function+0x0/0x33 Feb 16 20:13:01 sandman kernel: [c01604e3] ? __link_path_walk+0x97c/0xa96 Feb 16 20:13:01 sandman kernel: [c02a503d] sys_sendto+0xa4/0xc3 Feb 16 20:13:01 sandman kernel: [c013d06b] ? find_lock_page+0x6e/0x75 Feb 16 20:13:01 sandman kernel: [c013ec28] ? filemap_fault+0x18f/0x2ee Feb 16 20:13:01 sandman kernel: [c013cf3c] ? unlock_page+0x24/0x27 Feb 16 20:13:01 sandman kernel: [c01471c5] ? __do_fault+0x303/0x341 Feb 16 20:13:01 sandman kernel: [c016897e] ? generic_drop_inode+0x133/0x137 Feb 16 20:13:01 sandman kernel: [c02a5074] sys_send+0x18/0x1a Feb 16 20:13:01 sandman kernel: [c02a576e] sys_socketcall+0xe6/0x186 Feb 16 20:13:01 sandman kernel: [c0103c32] syscall_call+0x7/0xb Feb 16 20:13:01 sandman kernel: === Feb 16 20:13:01 sandman kernel: BUG: sleeping function called from invalid context at mm/slab.c:3055 Feb 16 20:13:01 sandman kernel: in_atomic():1, irqs_disabled():0 Feb 16 20:13:01 sandman kernel: Pid: 2243, comm: wpa_supplicant Not tainted 2.6.25-rc2-git1 #2 Feb 16 20:13:01 sandman kernel: [c01116cc] __might_sleep+0x97/0x9e Feb 16 20:13:01 sandman kernel: [c0155d14] kmem_cache_alloc+0x22/0x8e Feb 16 20:13:01 sandman kernel: [c02a99b2] __alloc_skb+0x2c/0xf8 Feb 16 20:13:01 sandman kernel: [c02b5e80] rtmsg_ifinfo+0x36/0xb4 Feb 16 20:13:01 sandman kernel: [c02ae11f] netdev_state_change+0x29/0x2c Feb 16 20:13:01 sandman kernel: [c02b5567] do_setlink+0x30e/0x325 Feb 16 20:13:01 sandman kernel: [c02b6505] rtnl_setlink+0xc9/0xe7 Feb 16 20:13:01 sandman kernel: [c02b643c] ? rtnl_setlink+0x0/0xe7 Feb 16 20:13:01 sandman kernel: [c02b62b4] rtnetlink_rcv_msg+0x195/0x1af Feb 16 20:13:01 sandman kernel: [c02b611f] ? rtnetlink_rcv_msg+0x0/0x1af Feb 16 20:13:01 sandman kernel: [c02bb98c] netlink_rcv_skb+0x30/0x82 Feb 16 20:13:01 sandman kernel: [c02b6117] rtnetlink_rcv+0x17/0x1f Feb 16 20:13:01 sandman kernel: [c02bb76f] netlink_unicast+0x1b8/0x21c Feb 16 20:13:01 sandman kernel: [c02bbf3a] netlink_sendmsg+0x25b/0x268 Feb 16 20:13:01 sandman kernel: [c02a4801] sock_sendmsg+0xdd/0xf8 Feb 16 20:13:01 sandman kernel: [c0125a15] ? autoremove_wake_function+0x0/0x33 Feb 16 20:13:01 sandman kernel: [c01604e3] ? __link_path_walk+0x97c/0xa96 Feb 16 20:13:01 sandman kernel: [c02a503d] sys_sendto+0xa4/0xc3 Feb 16 20:13:01 sandman kernel: [c013d06b] ? find_lock_page+0x6e/0x75 Feb 16 20:13:01 sandman kernel: [c013ec28] ? filemap_fault+0x18f/0x2ee Feb 16 20:13:01 sandman kernel: [c013cf3c] ? unlock_page+0x24/0x27 Feb 16 20:13:01 sandman kernel: [c01471c5] ? __do_fault+0x303/0x341 Feb 16 20:13:01 sandman kernel: [c016897e] ? generic_drop_inode+0x133/0x137 Feb 16 20:13:01 sandman kernel: [c02a5074] sys_send+0x18/0x1a Feb 16 20:13:01 sandman kernel: [c02a576e] sys_socketcall+0xe6/0x186 Feb 16 20:13:01 sandman kernel: [c0103c32] syscall_call+0x7/0xb Feb 16 20:13:01 sandman kernel: === Feb 16 20:13:01 sandman kernel: BUG: scheduling while atomic: wpa_supplicant/2243/0x1200
Re: 2.6.25-rc2: wpa_supplicant BUGs kernel in rwlock recursion
On Feb 17, 2008 12:18 AM, Guillaume Chazarain [EMAIL PROTECTED] wrote: On Feb 16, 2008 6:14 PM, Alessandro Suardi [EMAIL PROTECTED] wrote: Feb 16 16:51:49 sandman kernel: BUG: rwlock recursion on CPU#0, Same thing here, bisected it to: commit 45b503548210fe6f23e92b856421c2a3f05fd034 Author: Laszlo Attila Toth panther at balabit.hu Date: Tue Feb 12 22:42:09 2008 -0800 [RTNETLINK]: Send a single notification on device state changes. The revert applies cleanly and fixes the problem. Rafael has more details in http://lkml.org/lkml/2008/2/15/542. Thanks Guillaume, I can confirm that the revert of the rtnetlink.c changes does indeed fix the problem for me. Second time in a couple of week I hit the same bugs as Rafael, will keep an eye on his new findings ;) --alessandro We act as though comfort and luxury were the chief requirements of life, when all that we need to make us really happy is something to be enthusiastic about. (Charles Kingsley) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git2: Oracle 11g VKTM process enters R state on startup and is unkillable [still broken in 2.6.25-rc1]
On Feb 12, 2008 2:44 PM, Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > On Tue, 2008-02-12 at 00:12 +0100, Rafael J. Wysocki wrote: > > On Monday, 11 of February 2008, Ingo Molnar wrote: > > > > > > * Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > > > > no, they were not lost, they just didnt pass QA here (they crashed on > > > > a particularly hard to debug 8-way box i have) and Peter worked on > > > > that queue of fixes up until today to get it really correct. Could you > > > > check: > > > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched.git > > > > > > > > combo patch below as well - whichever you prefer. The shortlog can be > > > > found below as well - but i dont yet consider this pullable, i'd like > > > > it to see pass a full night of randconfig tests on my test-systems. > > > > > > ok, we just found the reason for the 8-way crash, the delta fix from > > > Peter is below if any of you have tried the previous combo patch. > > > Updated sched.git as well, new HEAD is > > > fec13e45305d69fd0bd23b30bd05a0a42cf341f8. > > > > With the previous patch and this patch applied, the issue is not > > reproducible > > here. > > Did you enable CONFIG_RT_GROUP_SCHED (it defaults to n)? > > If you didn't, could you try with it set to y? I just rebuilt 2.6.25-rc1-git2 with Ingo's patch and your patch on top, and the Oracle VKTM issue is still gone even with [EMAIL PROTECTED] ~]$ grep GROUP_SCHED /share/src/linux-2.6.25-rc1-git2-orafix/.config CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_RT_GROUP_SCHED=y # CONFIG_CGROUP_SCHED is not set so it's good for me. Or is it necessary to also enable CONFIG_CGROUP_SCHED and retest ? --alessandro "We act as though comfort and luxury were the chief requirements of life, when all that we need to make us really happy is something to be enthusiastic about." (Charles Kingsley) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git2: Oracle 11g VKTM process enters R state on startup and is unkillable [still broken in 2.6.25-rc1]
On Feb 12, 2008 2:44 PM, Peter Zijlstra [EMAIL PROTECTED] wrote: On Tue, 2008-02-12 at 00:12 +0100, Rafael J. Wysocki wrote: On Monday, 11 of February 2008, Ingo Molnar wrote: * Ingo Molnar [EMAIL PROTECTED] wrote: no, they were not lost, they just didnt pass QA here (they crashed on a particularly hard to debug 8-way box i have) and Peter worked on that queue of fixes up until today to get it really correct. Could you check: git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched.git combo patch below as well - whichever you prefer. The shortlog can be found below as well - but i dont yet consider this pullable, i'd like it to see pass a full night of randconfig tests on my test-systems. ok, we just found the reason for the 8-way crash, the delta fix from Peter is below if any of you have tried the previous combo patch. Updated sched.git as well, new HEAD is fec13e45305d69fd0bd23b30bd05a0a42cf341f8. With the previous patch and this patch applied, the issue is not reproducible here. Did you enable CONFIG_RT_GROUP_SCHED (it defaults to n)? If you didn't, could you try with it set to y? I just rebuilt 2.6.25-rc1-git2 with Ingo's patch and your patch on top, and the Oracle VKTM issue is still gone even with [EMAIL PROTECTED] ~]$ grep GROUP_SCHED /share/src/linux-2.6.25-rc1-git2-orafix/.config CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_RT_GROUP_SCHED=y # CONFIG_CGROUP_SCHED is not set so it's good for me. Or is it necessary to also enable CONFIG_CGROUP_SCHED and retest ? --alessandro We act as though comfort and luxury were the chief requirements of life, when all that we need to make us really happy is something to be enthusiastic about. (Charles Kingsley) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git2: Oracle 11g VKTM process enters R state on startup and is unkillable [still broken in 2.6.25-rc1]
On Feb 12, 2008 12:12 AM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> On Monday, 11 of February 2008, Ingo Molnar wrote:
> >
> > * Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > > no, they were not lost, they just didnt pass QA here (they crashed on
> > > a particularly hard to debug 8-way box i have) and Peter worked on
> > > that queue of fixes up until today to get it really correct. Could you
> > > check:
> > >
> > >git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched.git
> > >
> > > combo patch below as well - whichever you prefer. The shortlog can be
> > > found below as well - but i dont yet consider this pullable, i'd like
> > > it to see pass a full night of randconfig tests on my test-systems.
> >
> > ok, we just found the reason for the 8-way crash, the delta fix from
> > Peter is below if any of you have tried the previous combo patch.
> > Updated sched.git as well, new HEAD is
> > fec13e45305d69fd0bd23b30bd05a0a42cf341f8.
>
> With the previous patch and this patch applied, the issue is not reproducible
> here.
>
> Thanks,
> Rafael
The problem is fixed for me as well with the previous patch + the patch
below, VKTM now enters S state and Oracle shuts down properly again.
Thanks !
> > Index: linux-2.6/kernel/sched.c
> > ===
> > --- linux-2.6.orig/kernel/sched.c
> > +++ linux-2.6/kernel/sched.c
> > @@ -219,6 +219,10 @@ static void start_rt_bandwidth(struct rt
> > if (rt_b->rt_runtime == RUNTIME_INF)
> > return;
> >
> > + if (hrtimer_active(_b->rt_period_timer))
> > + return;
> > +
> > + spin_lock(_b->rt_runtime_lock);
> > for (;;) {
> > if (hrtimer_active(_b->rt_period_timer))
> > break;
> > @@ -229,6 +233,7 @@ static void start_rt_bandwidth(struct rt
> > rt_b->rt_period_timer.expires,
> > HRTIMER_MODE_ABS);
> > }
> > + spin_unlock(_b->rt_runtime_lock);
> > }
> >
> > #ifdef CONFIG_RT_GROUP_SCHED
--alessandro
"We act as though comfort and luxury were the chief requirements
of life, when all that we need to make us really happy is
something to be enthusiastic about."
(Charles Kingsley)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git2: Oracle 11g VKTM process enters R state on startup and is unkillable [still broken in 2.6.25-rc1]
On Feb 9, 2008 6:10 PM, Alessandro Suardi <[EMAIL PROTECTED]> wrote: > I finally had a bit of time to try out different kernel versions to find > out where this began... and it's in 2.6.24-git2. > > What happens: Oracle 11g starts up and forks a number of so > called background processes. Starting in 2.6.24-git2 the VKTM > process never fully completes its initialization but gets in R state, > never accumulating CPU, and can't be straced/gdb'd/killed. > > Sysrq-T reports for VKTM looks like this > > Feb 9 16:10:46 sandman kernel: === > Feb 9 16:10:46 sandman kernel: oracleR running 2684 2258 1 > Feb 9 16:10:46 sandman kernel:f591dfb0 00200086 f6bbc3c4 > f6863cc0 c010547a b794f62c b7b70600 > Feb 9 16:10:46 sandman kernel:b79453dc f591d000 c0103caa > b794f62c b7943708 b79453e4 b7b70600 b79453dc > Feb 9 16:10:46 sandman kernel:bfb0dd5c b79500b0 007b > 007b c032 0e072d7a 0073 > Feb 9 16:10:46 sandman kernel: Call Trace: > Feb 9 16:10:46 sandman kernel: [] ? do_IRQ+0xac/0xc1 > Feb 9 16:10:46 sandman kernel: [] work_resched+0x5/0x16 > Feb 9 16:10:46 sandman kernel: [] ? pci_setup+0xb3/0x104 > Feb 9 16:10:46 sandman kernel: === > > > 2.6.24-git1 is okay > 2.6.24-git2 is bad > ... > 2.6.24-git20 is bad > > Only differences in kernel .config between -git1 and -git2 are > > [EMAIL PROTECTED] src]$ diff .config-2.6.24-git[12] > 3,4c3,4 > < # Linux kernel version: 2.6.24-git1 > < # Sat Jan 26 01:04:43 2008 > --- > > # Linux kernel version: 2.6.24-git2 > > # Sat Jan 26 12:10:15 2008 > 121a122,123 > > CONFIG_CLASSIC_RCU=y > > # CONFIG_PREEMPT_RCU is not set > 187a190 > > # CONFIG_RCU_TRACE is not set > 230a234 > > # CONFIG_SCHED_HRTICK is not set > 755a760 > > # CONFIG_PATA_NINJA32 is not set > 1807a1813 > > # CONFIG_LATENCYTOP is not set > > Symptom is similar to what Rafael reported here > > http://www.ussg.iu.edu/hypermail/linux/kernel/0801.3/4114.html > > and similarly VKTM attempts to run at elevated priority as normal > user process (Oracle kernel binary is not setuid root). > > > Peter Zijlstra's patches mentioned in the above thread, at > > http://programming.kicks-ass.net/kernel-patches/sched-rt-group , > > do not appear to be in -git20 yet. > > > I'm available for further testing. Thanks, ciao, Only to add that 2.6.25-rc1 is still broken. thanks, --alessandro "We act as though comfort and luxury were the chief requirements of life, when all that we need to make us really happy is something to be enthusiastic about." (Charles Kingsley) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git2: Oracle 11g VKTM process enters R state on startup and is unkillable [still broken in 2.6.25-rc1]
On Feb 12, 2008 12:12 AM, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Monday, 11 of February 2008, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
no, they were not lost, they just didnt pass QA here (they crashed on
a particularly hard to debug 8-way box i have) and Peter worked on
that queue of fixes up until today to get it really correct. Could you
check:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched.git
combo patch below as well - whichever you prefer. The shortlog can be
found below as well - but i dont yet consider this pullable, i'd like
it to see pass a full night of randconfig tests on my test-systems.
ok, we just found the reason for the 8-way crash, the delta fix from
Peter is below if any of you have tried the previous combo patch.
Updated sched.git as well, new HEAD is
fec13e45305d69fd0bd23b30bd05a0a42cf341f8.
With the previous patch and this patch applied, the issue is not reproducible
here.
Thanks,
Rafael
The problem is fixed for me as well with the previous patch + the patch
below, VKTM now enters S state and Oracle shuts down properly again.
Thanks !
Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c
+++ linux-2.6/kernel/sched.c
@@ -219,6 +219,10 @@ static void start_rt_bandwidth(struct rt
if (rt_b-rt_runtime == RUNTIME_INF)
return;
+ if (hrtimer_active(rt_b-rt_period_timer))
+ return;
+
+ spin_lock(rt_b-rt_runtime_lock);
for (;;) {
if (hrtimer_active(rt_b-rt_period_timer))
break;
@@ -229,6 +233,7 @@ static void start_rt_bandwidth(struct rt
rt_b-rt_period_timer.expires,
HRTIMER_MODE_ABS);
}
+ spin_unlock(rt_b-rt_runtime_lock);
}
#ifdef CONFIG_RT_GROUP_SCHED
--alessandro
We act as though comfort and luxury were the chief requirements
of life, when all that we need to make us really happy is
something to be enthusiastic about.
(Charles Kingsley)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git2: Oracle 11g VKTM process enters R state on startup and is unkillable [still broken in 2.6.25-rc1]
On Feb 9, 2008 6:10 PM, Alessandro Suardi [EMAIL PROTECTED] wrote: I finally had a bit of time to try out different kernel versions to find out where this began... and it's in 2.6.24-git2. What happens: Oracle 11g starts up and forks a number of so called background processes. Starting in 2.6.24-git2 the VKTM process never fully completes its initialization but gets in R state, never accumulating CPU, and can't be straced/gdb'd/killed. Sysrq-T reports for VKTM looks like this Feb 9 16:10:46 sandman kernel: === Feb 9 16:10:46 sandman kernel: oracleR running 2684 2258 1 Feb 9 16:10:46 sandman kernel:f591dfb0 00200086 f6bbc3c4 f6863cc0 c010547a b794f62c b7b70600 Feb 9 16:10:46 sandman kernel:b79453dc f591d000 c0103caa b794f62c b7943708 b79453e4 b7b70600 b79453dc Feb 9 16:10:46 sandman kernel:bfb0dd5c b79500b0 007b 007b c032 0e072d7a 0073 Feb 9 16:10:46 sandman kernel: Call Trace: Feb 9 16:10:46 sandman kernel: [c010547a] ? do_IRQ+0xac/0xc1 Feb 9 16:10:46 sandman kernel: [c0103caa] work_resched+0x5/0x16 Feb 9 16:10:46 sandman kernel: [c032] ? pci_setup+0xb3/0x104 Feb 9 16:10:46 sandman kernel: === 2.6.24-git1 is okay 2.6.24-git2 is bad ... 2.6.24-git20 is bad Only differences in kernel .config between -git1 and -git2 are [EMAIL PROTECTED] src]$ diff .config-2.6.24-git[12] 3,4c3,4 # Linux kernel version: 2.6.24-git1 # Sat Jan 26 01:04:43 2008 --- # Linux kernel version: 2.6.24-git2 # Sat Jan 26 12:10:15 2008 121a122,123 CONFIG_CLASSIC_RCU=y # CONFIG_PREEMPT_RCU is not set 187a190 # CONFIG_RCU_TRACE is not set 230a234 # CONFIG_SCHED_HRTICK is not set 755a760 # CONFIG_PATA_NINJA32 is not set 1807a1813 # CONFIG_LATENCYTOP is not set Symptom is similar to what Rafael reported here http://www.ussg.iu.edu/hypermail/linux/kernel/0801.3/4114.html and similarly VKTM attempts to run at elevated priority as normal user process (Oracle kernel binary is not setuid root). Peter Zijlstra's patches mentioned in the above thread, at http://programming.kicks-ass.net/kernel-patches/sched-rt-group , do not appear to be in -git20 yet. I'm available for further testing. Thanks, ciao, Only to add that 2.6.25-rc1 is still broken. thanks, --alessandro We act as though comfort and luxury were the chief requirements of life, when all that we need to make us really happy is something to be enthusiastic about. (Charles Kingsley) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.24-git2: Oracle 11g VKTM process enters R state on startup and is unkillable
I finally had a bit of time to try out different kernel versions to find out where this began... and it's in 2.6.24-git2. What happens: Oracle 11g starts up and forks a number of so called background processes. Starting in 2.6.24-git2 the VKTM process never fully completes its initialization but gets in R state, never accumulating CPU, and can't be straced/gdb'd/killed. Sysrq-T reports for VKTM looks like this Feb 9 16:10:46 sandman kernel: === Feb 9 16:10:46 sandman kernel: oracleR running 2684 2258 1 Feb 9 16:10:46 sandman kernel:f591dfb0 00200086 f6bbc3c4 f6863cc0 c010547a b794f62c b7b70600 Feb 9 16:10:46 sandman kernel:b79453dc f591d000 c0103caa b794f62c b7943708 b79453e4 b7b70600 b79453dc Feb 9 16:10:46 sandman kernel:bfb0dd5c b79500b0 007b 007b c032 0e072d7a 0073 Feb 9 16:10:46 sandman kernel: Call Trace: Feb 9 16:10:46 sandman kernel: [] ? do_IRQ+0xac/0xc1 Feb 9 16:10:46 sandman kernel: [] work_resched+0x5/0x16 Feb 9 16:10:46 sandman kernel: [] ? pci_setup+0xb3/0x104 Feb 9 16:10:46 sandman kernel: === 2.6.24-git1 is okay 2.6.24-git2 is bad ... 2.6.24-git20 is bad Only differences in kernel .config between -git1 and -git2 are [EMAIL PROTECTED] src]$ diff .config-2.6.24-git[12] 3,4c3,4 < # Linux kernel version: 2.6.24-git1 < # Sat Jan 26 01:04:43 2008 --- > # Linux kernel version: 2.6.24-git2 > # Sat Jan 26 12:10:15 2008 121a122,123 > CONFIG_CLASSIC_RCU=y > # CONFIG_PREEMPT_RCU is not set 187a190 > # CONFIG_RCU_TRACE is not set 230a234 > # CONFIG_SCHED_HRTICK is not set 755a760 > # CONFIG_PATA_NINJA32 is not set 1807a1813 > # CONFIG_LATENCYTOP is not set Symptom is similar to what Rafael reported here http://www.ussg.iu.edu/hypermail/linux/kernel/0801.3/4114.html and similarly VKTM attempts to run at elevated priority as normal user process (Oracle kernel binary is not setuid root). Peter Zijlstra's patches mentioned in the above thread, at http://programming.kicks-ass.net/kernel-patches/sched-rt-group , do not appear to be in -git20 yet. I'm available for further testing. Thanks, ciao, --alessandro "We act as though comfort and luxury were the chief requirements of life, when all that we need to make us really happy is something to be enthusiastic about." (Charles Kingsley) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.24-git2: Oracle 11g VKTM process enters R state on startup and is unkillable
I finally had a bit of time to try out different kernel versions to find out where this began... and it's in 2.6.24-git2. What happens: Oracle 11g starts up and forks a number of so called background processes. Starting in 2.6.24-git2 the VKTM process never fully completes its initialization but gets in R state, never accumulating CPU, and can't be straced/gdb'd/killed. Sysrq-T reports for VKTM looks like this Feb 9 16:10:46 sandman kernel: === Feb 9 16:10:46 sandman kernel: oracleR running 2684 2258 1 Feb 9 16:10:46 sandman kernel:f591dfb0 00200086 f6bbc3c4 f6863cc0 c010547a b794f62c b7b70600 Feb 9 16:10:46 sandman kernel:b79453dc f591d000 c0103caa b794f62c b7943708 b79453e4 b7b70600 b79453dc Feb 9 16:10:46 sandman kernel:bfb0dd5c b79500b0 007b 007b c032 0e072d7a 0073 Feb 9 16:10:46 sandman kernel: Call Trace: Feb 9 16:10:46 sandman kernel: [c010547a] ? do_IRQ+0xac/0xc1 Feb 9 16:10:46 sandman kernel: [c0103caa] work_resched+0x5/0x16 Feb 9 16:10:46 sandman kernel: [c032] ? pci_setup+0xb3/0x104 Feb 9 16:10:46 sandman kernel: === 2.6.24-git1 is okay 2.6.24-git2 is bad ... 2.6.24-git20 is bad Only differences in kernel .config between -git1 and -git2 are [EMAIL PROTECTED] src]$ diff .config-2.6.24-git[12] 3,4c3,4 # Linux kernel version: 2.6.24-git1 # Sat Jan 26 01:04:43 2008 --- # Linux kernel version: 2.6.24-git2 # Sat Jan 26 12:10:15 2008 121a122,123 CONFIG_CLASSIC_RCU=y # CONFIG_PREEMPT_RCU is not set 187a190 # CONFIG_RCU_TRACE is not set 230a234 # CONFIG_SCHED_HRTICK is not set 755a760 # CONFIG_PATA_NINJA32 is not set 1807a1813 # CONFIG_LATENCYTOP is not set Symptom is similar to what Rafael reported here http://www.ussg.iu.edu/hypermail/linux/kernel/0801.3/4114.html and similarly VKTM attempts to run at elevated priority as normal user process (Oracle kernel binary is not setuid root). Peter Zijlstra's patches mentioned in the above thread, at http://programming.kicks-ass.net/kernel-patches/sched-rt-group , do not appear to be in -git20 yet. I'm available for further testing. Thanks, ciao, --alessandro We act as though comfort and luxury were the chief requirements of life, when all that we need to make us really happy is something to be enthusiastic about. (Charles Kingsley) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Regression] 2.6.24-git8 (and earlier): Multiple processes stuck in D states after logout from KDE
2008/1/31 Rafael J. Wysocki <[EMAIL PROTECTED]>: > Update. > > On Wednesday, 30 of January 2008, Rafael J. Wysocki wrote: > > Hi, > > > > Recently I've been observing problems with unmounting the /home fs on reboot > > and/or shutdown on two test boxes. > > > > After some more investigation I've found that this is due to some KDE > > processes > > stuck in D states after their owner has logged out. > > > > This happens 100% of the time if there's a suspend/resume cycle before the > > user > > logs out (ie. the user logs into KDE, works for some time, suspends the box > > to > > RAM and resmes one or more times and then logs out). Still, I also observe > > the > > symptoms on a box that's never suspended. > > > > I'm not sure how to debug this, so please advise. > > After reverting: > > commit 37bb6cb4097e29ffee970065b74499cbf10603a3 > Author: Peter Zijlstra <[EMAIL PROTECTED]> > Date: Fri Jan 25 21:08:32 2008 +0100 > > hrtimer: unlock hrtimer_wakeup > > I no longer get processes in the D state, but there still is a problem with > artswrapper (this is an openSUSE 10.3 system, x86-64). Namely, > after a suspend/resume cycle and logging out/logging in the user, > artswrapper gets stuck somewhere, apparently in the running (R) state. > For this reason it blocks any subsequent attempts to suspend. > > Here's the relevant trace (from show_state()): > > [ 522.474919] artswrapper R running task0 4805 1 > [ 522.474922] 810074cd1f70 0082 0296 > 810074cd1ed8 > [ 522.474926] 80311769 810074cd1f20 80701240 > 80701240 > [ 522.474930] 80701240 80701240 80701240 > 80701240 > [ 522.474933] Call Trace: > [ 522.474940] [] ? __up_read+0x8f/0x97 > [ 522.474963] [] retint_careful+0xd/0x21 > > where, according to gdb, > > (gdb) l *__up_read+0x8f > 0x80311769 is in __up_read > (/home/rafael/src/linux-2.6/lib/rwsem-spinlock.c:273). > 268 > 269 if (--sem->activity == 0 && !list_empty(>wait_list)) > 270 sem = __rwsem_wake_one_writer(sem); > 271 > 272 spin_unlock_irqrestore(>wait_lock, flags); > 273 } > 274 > 275 /* > 276 * release a write lock on the semaphore > 277 */ > > What gives? In recent kernels, I had a hard hang in -git6 on my Fedora8-based Dell D610 (x86, UP) - and since at least -git4 I can't shutdown my Oracle 11.1 instance, with the VKTM thread remaining in R state, while taking up no CPU at all: [EMAIL PROTECTED] ~]# ps ax | grep vktm 3211 ?Rs 0:00 ora_vktm_t111 additionally, VKTM is - non-straceable (strace hangs) - non-gdb'able (gdb hangs) - non-pstack'able (pstack returns empty) - non-killable (kill -9 doesn't kill it) echo'ing 't' in /proc/sysrq-trigger, I have (2.6.24-git8): Jan 31 20:04:31 sandman kernel: === Jan 31 20:04:31 sandman kernel: oracleR running 2668 3211 1 Jan 31 20:04:31 sandman kernel:f1462fb0 0082 f1f1aa54 f172dd80 c01055f6 0ef609ac bf8532ec Jan 31 20:04:31 sandman kernel: f1462000 c0103e26 0ef609ac bf853388 b79906a4 bf8532ec Jan 31 20:04:31 sandman kernel:bf850140 bf850068 007b 007b c032 08f53d02 0073 Jan 31 20:04:31 sandman kernel: Call Trace: Jan 31 20:04:31 sandman kernel: [] ? do_IRQ+0xac/0xc1 Jan 31 20:04:31 sandman kernel: [] work_resched+0x5/0x16 Jan 31 20:04:31 sandman kernel: [] ? tg3_init_one+0xe76/0x10e0 Jan 31 20:04:31 sandman kernel: === Once I'm done with a largish FTP I'll try and find out where this exactly began. --alessandro "We act as though comfort and luxury were the chief requirements of life, when all that we need to make us really happy is something to be enthusiastic about." (Charles Kingsley) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Regression] 2.6.24-git8 (and earlier): Multiple processes stuck in D states after logout from KDE
2008/1/31 Rafael J. Wysocki [EMAIL PROTECTED]: Update. On Wednesday, 30 of January 2008, Rafael J. Wysocki wrote: Hi, Recently I've been observing problems with unmounting the /home fs on reboot and/or shutdown on two test boxes. After some more investigation I've found that this is due to some KDE processes stuck in D states after their owner has logged out. This happens 100% of the time if there's a suspend/resume cycle before the user logs out (ie. the user logs into KDE, works for some time, suspends the box to RAM and resmes one or more times and then logs out). Still, I also observe the symptoms on a box that's never suspended. I'm not sure how to debug this, so please advise. After reverting: commit 37bb6cb4097e29ffee970065b74499cbf10603a3 Author: Peter Zijlstra [EMAIL PROTECTED] Date: Fri Jan 25 21:08:32 2008 +0100 hrtimer: unlock hrtimer_wakeup I no longer get processes in the D state, but there still is a problem with artswrapper (this is an openSUSE 10.3 system, x86-64). Namely, after a suspend/resume cycle and logging out/logging in the user, artswrapper gets stuck somewhere, apparently in the running (R) state. For this reason it blocks any subsequent attempts to suspend. Here's the relevant trace (from show_state()): [ 522.474919] artswrapper R running task0 4805 1 [ 522.474922] 810074cd1f70 0082 0296 810074cd1ed8 [ 522.474926] 80311769 810074cd1f20 80701240 80701240 [ 522.474930] 80701240 80701240 80701240 80701240 [ 522.474933] Call Trace: [ 522.474940] [80311769] ? __up_read+0x8f/0x97 [ 522.474963] [8020c5cf] retint_careful+0xd/0x21 where, according to gdb, (gdb) l *__up_read+0x8f 0x80311769 is in __up_read (/home/rafael/src/linux-2.6/lib/rwsem-spinlock.c:273). 268 269 if (--sem-activity == 0 !list_empty(sem-wait_list)) 270 sem = __rwsem_wake_one_writer(sem); 271 272 spin_unlock_irqrestore(sem-wait_lock, flags); 273 } 274 275 /* 276 * release a write lock on the semaphore 277 */ What gives? In recent kernels, I had a hard hang in -git6 on my Fedora8-based Dell D610 (x86, UP) - and since at least -git4 I can't shutdown my Oracle 11.1 instance, with the VKTM thread remaining in R state, while taking up no CPU at all: [EMAIL PROTECTED] ~]# ps ax | grep vktm 3211 ?Rs 0:00 ora_vktm_t111 additionally, VKTM is - non-straceable (strace hangs) - non-gdb'able (gdb hangs) - non-pstack'able (pstack returns empty) - non-killable (kill -9 doesn't kill it) echo'ing 't' in /proc/sysrq-trigger, I have (2.6.24-git8): Jan 31 20:04:31 sandman kernel: === Jan 31 20:04:31 sandman kernel: oracleR running 2668 3211 1 Jan 31 20:04:31 sandman kernel:f1462fb0 0082 f1f1aa54 f172dd80 c01055f6 0ef609ac bf8532ec Jan 31 20:04:31 sandman kernel: f1462000 c0103e26 0ef609ac bf853388 b79906a4 bf8532ec Jan 31 20:04:31 sandman kernel:bf850140 bf850068 007b 007b c032 08f53d02 0073 Jan 31 20:04:31 sandman kernel: Call Trace: Jan 31 20:04:31 sandman kernel: [c01055f6] ? do_IRQ+0xac/0xc1 Jan 31 20:04:31 sandman kernel: [c0103e26] work_resched+0x5/0x16 Jan 31 20:04:31 sandman kernel: [c032] ? tg3_init_one+0xe76/0x10e0 Jan 31 20:04:31 sandman kernel: === Once I'm done with a largish FTP I'll try and find out where this exactly began. --alessandro We act as though comfort and luxury were the chief requirements of life, when all that we need to make us really happy is something to be enthusiastic about. (Charles Kingsley) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
On 22 Dec 2007 16:52:56 -0600, Jason L Tibbitts III <[EMAIL PROTECTED]> wrote: > > "IM" == Ingo Molnar <[EMAIL PROTECTED]> writes: > > IM> Distros will likely pick SLUB if there's no performance worries > IM> and if it's the default. Fedora rawhide already uses SLUB. > > Actually, it seems to me that not only does Fedora rawhide use SLUB, > but Fedora 8 and 7 use it as well. They don't have /proc/slabinfo and > they all seem to have CONFIG_SLUB=y: > > > grep -r CONFIG_SLUB=y kernel > kernel/devel/config-generic:CONFIG_SLUB=y > kernel/F-7/configs/config-generic:CONFIG_SLUB=y > kernel/F-8/config-generic:CONFIG_SLUB=y Also true for at least recent versions of FC6 (which my bittorrent machine is still on), which currently run 2.6.22-14 based kernels. And no, I didn't notice - that box usually hits triple-digit uptime before I reboot; in fact, it's still running a 2.6.22-9 based kernel. --alessandro "Damaged people are dangerous. They know they can survive." (Anna Barton/Juliette Binoche, 'Damage') -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
On 22 Dec 2007 16:52:56 -0600, Jason L Tibbitts III [EMAIL PROTECTED] wrote: IM == Ingo Molnar [EMAIL PROTECTED] writes: IM Distros will likely pick SLUB if there's no performance worries IM and if it's the default. Fedora rawhide already uses SLUB. Actually, it seems to me that not only does Fedora rawhide use SLUB, but Fedora 8 and 7 use it as well. They don't have /proc/slabinfo and they all seem to have CONFIG_SLUB=y: grep -r CONFIG_SLUB=y kernel kernel/devel/config-generic:CONFIG_SLUB=y kernel/F-7/configs/config-generic:CONFIG_SLUB=y kernel/F-8/config-generic:CONFIG_SLUB=y Also true for at least recent versions of FC6 (which my bittorrent machine is still on), which currently run 2.6.22-14 based kernels. And no, I didn't notice - that box usually hits triple-digit uptime before I reboot; in fact, it's still running a 2.6.22-9 based kernel. --alessandro Damaged people are dangerous. They know they can survive. (Anna Barton/Juliette Binoche, 'Damage') -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
possible circular locking dependency detected in 2.6.24-rc3-git6
Only saw this once, but it's a relatively short time since I moved
to Fedora 8 (i686, UP) and began building my custom kernels
there... apparently starting my 11.1.0.6 Oracle instance caused
lockdep to trigger this (hoping GMail doesn't mangle the
text too badly):
===
[ INFO: possible circular locking dependency detected ]
2.6.24-rc3-git6 #7
---
oracle/4715 is trying to acquire lock:
(>mmap_sem){}, at: [] dio_get_page+0x4d/0x159
but task is already holding lock:
(jbd_handle){--..}, at: [] journal_start+0xc8/0xf5
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (jbd_handle){--..}:
[] __lock_acquire+0xa08/0xc06
[] lock_acquire+0x6f/0x88
[] journal_start+0xeb/0xf5
[] ext3_journal_start_sb+0x48/0x4a
[] ext3_dirty_inode+0x26/0x6b
[] __mark_inode_dirty+0x26/0x158
[] touch_atime+0xb7/0xbc
[] generic_file_mmap+0x2d/0x42
[] mmap_region+0x1d8/0x3a4
[] do_mmap_pgoff+0x257/0x2b6
[] sys_mmap2+0x9a/0xb4
[] syscall_call+0x7/0xb
[] 0x
-> #0 (>mmap_sem){}:
[] __lock_acquire+0x8f8/0xc06
[] lock_acquire+0x6f/0x88
[] down_read+0x3f/0x50
[] dio_get_page+0x4d/0x159
[] __blockdev_direct_IO+0x3f7/0xad1
[] ext3_direct_IO+0x10c/0x195
[] generic_file_direct_IO+0x124/0x139
[] generic_file_direct_write+0x56/0xed
[] __generic_file_aio_write_nolock+0x2f6/0x43e
[] generic_file_aio_write+0x58/0xb6
[] ext3_file_write+0x27/0x99
[] do_sync_write+0xc4/0x101
[] vfs_write+0xa8/0x131
[] sys_pwrite64+0x45/0x5c
[] syscall_call+0x7/0xb
[] 0x
other info that might help us debug this:
2 locks held by oracle/4715:
#0: (>s_type->i_mutex_key#7){--..}, at: []
generic_file_aio_write+0x45/0xb6
#1: (jbd_handle){--..}, at: [] journal_start+0xc8/0xf5
stack backtrace:
Pid: 4715, comm: oracle Not tainted 2.6.24-rc3-git6 #7
[] show_trace_log_lvl+0x1a/0x2f
[] show_trace+0x12/0x14
[] dump_stack+0x6a/0x70
[] print_circular_bug_tail+0x5e/0x67
[] __lock_acquire+0x8f8/0xc06
[] lock_acquire+0x6f/0x88
[] down_read+0x3f/0x50
[] dio_get_page+0x4d/0x159
[] __blockdev_direct_IO+0x3f7/0xad1
[] ext3_direct_IO+0x10c/0x195
[] generic_file_direct_IO+0x124/0x139
[] generic_file_direct_write+0x56/0xed
[] __generic_file_aio_write_nolock+0x2f6/0x43e
[] generic_file_aio_write+0x58/0xb6
[] ext3_file_write+0x27/0x99
[] do_sync_write+0xc4/0x101
[] vfs_write+0xa8/0x131
[] sys_pwrite64+0x45/0x5c
[] syscall_call+0x7/0xb
===
Let me know whether this is enough info or I should try
and hammer the thing further to see if this reproduces.
Thanks, ciao,
--alessandro
"Damaged people are dangerous. They know they can survive."
(Anna Barton/Juliette Binoche, 'Damage')
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
possible circular locking dependency detected in 2.6.24-rc3-git6
Only saw this once, but it's a relatively short time since I moved
to Fedora 8 (i686, UP) and began building my custom kernels
there... apparently starting my 11.1.0.6 Oracle instance caused
lockdep to trigger this (hoping GMail doesn't mangle the
text too badly):
===
[ INFO: possible circular locking dependency detected ]
2.6.24-rc3-git6 #7
---
oracle/4715 is trying to acquire lock:
(mm-mmap_sem){}, at: [c0182489] dio_get_page+0x4d/0x159
but task is already holding lock:
(jbd_handle){--..}, at: [c01a825e] journal_start+0xc8/0xf5
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
- #1 (jbd_handle){--..}:
[c01331e2] __lock_acquire+0xa08/0xc06
[c013344f] lock_acquire+0x6f/0x88
[c01a8281] journal_start+0xeb/0xf5
[c01a1220] ext3_journal_start_sb+0x48/0x4a
[c019cd75] ext3_dirty_inode+0x26/0x6b
[c017a1fe] __mark_inode_dirty+0x26/0x158
[c0172a83] touch_atime+0xb7/0xbc
[c0145266] generic_file_mmap+0x2d/0x42
[c01543fc] mmap_region+0x1d8/0x3a4
[c01548f3] do_mmap_pgoff+0x257/0x2b6
[c010728a] sys_mmap2+0x9a/0xb4
[c0103e7a] syscall_call+0x7/0xb
[] 0x
- #0 (mm-mmap_sem){}:
[c01330d2] __lock_acquire+0x8f8/0xc06
[c013344f] lock_acquire+0x6f/0x88
[c012bd13] down_read+0x3f/0x50
[c0182489] dio_get_page+0x4d/0x159
[c0182f73] __blockdev_direct_IO+0x3f7/0xad1
[c019cb6f] ext3_direct_IO+0x10c/0x195
[c0146367] generic_file_direct_IO+0x124/0x139
[c01463d2] generic_file_direct_write+0x56/0xed
[c0146c79] __generic_file_aio_write_nolock+0x2f6/0x43e
[c0146e19] generic_file_aio_write+0x58/0xb6
[c0198d13] ext3_file_write+0x27/0x99
[c0161283] do_sync_write+0xc4/0x101
[c0161a24] vfs_write+0xa8/0x131
[c0161fb6] sys_pwrite64+0x45/0x5c
[c0103e7a] syscall_call+0x7/0xb
[] 0x
other info that might help us debug this:
2 locks held by oracle/4715:
#0: (sb-s_type-i_mutex_key#7){--..}, at: [c0146e06]
generic_file_aio_write+0x45/0xb6
#1: (jbd_handle){--..}, at: [c01a825e] journal_start+0xc8/0xf5
stack backtrace:
Pid: 4715, comm: oracle Not tainted 2.6.24-rc3-git6 #7
[c010448a] show_trace_log_lvl+0x1a/0x2f
[c0104df7] show_trace+0x12/0x14
[c010568a] dump_stack+0x6a/0x70
[c01318a5] print_circular_bug_tail+0x5e/0x67
[c01330d2] __lock_acquire+0x8f8/0xc06
[c013344f] lock_acquire+0x6f/0x88
[c012bd13] down_read+0x3f/0x50
[c0182489] dio_get_page+0x4d/0x159
[c0182f73] __blockdev_direct_IO+0x3f7/0xad1
[c019cb6f] ext3_direct_IO+0x10c/0x195
[c0146367] generic_file_direct_IO+0x124/0x139
[c01463d2] generic_file_direct_write+0x56/0xed
[c0146c79] __generic_file_aio_write_nolock+0x2f6/0x43e
[c0146e19] generic_file_aio_write+0x58/0xb6
[c0198d13] ext3_file_write+0x27/0x99
[c0161283] do_sync_write+0xc4/0x101
[c0161a24] vfs_write+0xa8/0x131
[c0161fb6] sys_pwrite64+0x45/0x5c
[c0103e7a] syscall_call+0x7/0xb
===
Let me know whether this is enough info or I should try
and hammer the thing further to see if this reproduces.
Thanks, ciao,
--alessandro
Damaged people are dangerous. They know they can survive.
(Anna Barton/Juliette Binoche, 'Damage')
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ata4294967295: failed to start port (errno=-19)
On Nov 30, 2007 1:34 PM, Meelis Roos <[EMAIL PROTECTED]> wrote: > > Can you stick a stack trace in at that point ? That would help diagnose > > it a great deal quicker. > > Finally done - found out hard way that BUG() is too bad and > dump_st5ack() suits me better. > > libata version 3.00 loaded. > Pid: 661, comm: modprobe Not tainted 2.6.24-rc3 #3 > [] ata_host_start+0xf0/0x140 [libata] > [] ata_pci_init_one+0xee/0x2a0 [libata] > [] sysfs_create_link+0x77/0x100 > [] pacpi_init_one+0x17/0x20 [pata_acpi] > [] pci_device_probe+0x56/0x80 > [] driver_probe_device+0x87/0x190 > [] klist_next+0x51/0xb0 > [] __driver_attach+0x76/0x80 > [] bus_for_each_dev+0x3a/0x60 > [] driver_attach+0x16/0x20 > [] __driver_attach+0x0/0x80 > [] bus_add_driver+0x8b/0x1e0 > [] __pci_register_driver+0x4c/0x90 > [] sys_init_module+0x121/0x1550 > [] vma_prio_tree_insert+0x1f/0x50 > [] ata_std_prereset+0x0/0x160 [libata] > [] do_mmap_pgoff+0x298/0x320 > [] syscall_call+0x7/0xb > [] packet_setsockopt+0xf0/0x3b0 > === > ata4294967295: failed to start port (errno=-19) Mine is slightly different - I just put dump_stack(); before the ata_port_printk in libata-core.c: PCI: Setting latency timer of device :00:1f.2 to 64 Pid: 364, comm: insmod Not tainted 2.6.24-rc3-git5 #5 [] show_trace_log_lvl+0x1a/0x2f [] show_trace+0x12/0x14 [] dump_stack+0x6a/0x70 [] ata_host_start+0xb0/0x122 [] ata_pci_init_one+0xd3/0x252 [] pacpi_init_one+0x1c/0x1e [pata_acpi] [] pci_device_probe+0x39/0x5b [] driver_probe_device+0xe8/0x168 [] __driver_attach+0x74/0xab [] bus_for_each_dev+0x36/0x5b [] driver_attach+0x19/0x1b [] bus_add_driver+0x73/0x1aa [] driver_register+0x67/0x6c [] __pci_register_driver+0x56/0x83 [] pacpi_init+0x17/0x19 [pata_acpi] [] sys_init_module+0x1278/0x1391 [] sysenter_past_esp+0x5f/0xa5 === ata4294967295: failed to start port (errno=-19) --alessandro "Damaged people are dangerous. They know they can survive." (Anna Barton/Juliette Binoche, 'Damage') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ata4294967295: failed to start port (errno=-19)
On Nov 30, 2007 1:34 PM, Meelis Roos [EMAIL PROTECTED] wrote: Can you stick a stack trace in at that point ? That would help diagnose it a great deal quicker. Finally done - found out hard way that BUG() is too bad and dump_st5ack() suits me better. libata version 3.00 loaded. Pid: 661, comm: modprobe Not tainted 2.6.24-rc3 #3 [d48cac80] ata_host_start+0xf0/0x140 [libata] [d48d5f2e] ata_pci_init_one+0xee/0x2a0 [libata] [c01a6077] sysfs_create_link+0x77/0x100 [d4825037] pacpi_init_one+0x17/0x20 [pata_acpi] [c01d64e6] pci_device_probe+0x56/0x80 [c022dfd7] driver_probe_device+0x87/0x190 [c02b2191] klist_next+0x51/0xb0 [c022e216] __driver_attach+0x76/0x80 [c022d3ea] bus_for_each_dev+0x3a/0x60 [c022de56] driver_attach+0x16/0x20 [c022e1a0] __driver_attach+0x0/0x80 [c022d7ab] bus_add_driver+0x8b/0x1e0 [c01d667c] __pci_register_driver+0x4c/0x90 [c0139231] sys_init_module+0x121/0x1550 [c014eabf] vma_prio_tree_insert+0x1f/0x50 [d48d12f0] ata_std_prereset+0x0/0x160 [libata] [c0155648] do_mmap_pgoff+0x298/0x320 [c0104086] syscall_call+0x7/0xb [c02b] packet_setsockopt+0xf0/0x3b0 === ata4294967295: failed to start port (errno=-19) Mine is slightly different - I just put dump_stack(); before the ata_port_printk in libata-core.c: PCI: Setting latency timer of device :00:1f.2 to 64 Pid: 364, comm: insmod Not tainted 2.6.24-rc3-git5 #5 [c010448a] show_trace_log_lvl+0x1a/0x2f [c0104df7] show_trace+0x12/0x14 [c010568a] dump_stack+0x6a/0x70 [c027c36b] ata_host_start+0xb0/0x122 [c028649f] ata_pci_init_one+0xd3/0x252 [f882103a] pacpi_init_one+0x1c/0x1e [pata_acpi] [c01f298d] pci_device_probe+0x39/0x5b [c0254a87] driver_probe_device+0xe8/0x168 [c0254c2c] __driver_attach+0x74/0xab [c0253f7f] bus_for_each_dev+0x36/0x5b [c02548d3] driver_attach+0x19/0x1b [c025429e] bus_add_driver+0x73/0x1aa [c0254e19] driver_register+0x67/0x6c [c01f2aef] __pci_register_driver+0x56/0x83 [f8826017] pacpi_init+0x17/0x19 [pata_acpi] [c01390e5] sys_init_module+0x1278/0x1391 [c0103df2] sysenter_past_esp+0x5f/0xa5 === ata4294967295: failed to start port (errno=-19) --alessandro Damaged people are dangerous. They know they can survive. (Anna Barton/Juliette Binoche, 'Damage') - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ata4294967295: failed to start port (errno=-19)
On Nov 28, 2007 9:07 PM, Alan Cox <[EMAIL PROTECTED]> wrote: > > This message comes from 2.6.24-rc3 + todays git, version > > a531a141089714efe39eca89593524fdf05104f2. I did grep the logs and found > > that it first appeared in 2.6.24-rc1 (+ some git mayve) on Nov 3. > > I used 2.6.23 before that and it did not show this message. > > Can you stick a stack trace in at that point ? That would help diagnose > it a great deal quicker. I've also been seeing this for a while on my Dell Latitude D610, but stuff just works, so... I'm overloaded at this time, if nobody gets there first I'll give a go at tracing this next week. --alessandro "Damaged people are dangerous. They know they can survive." (Anna Barton/Juliette Binoche, 'Damage') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ata4294967295: failed to start port (errno=-19)
On Nov 28, 2007 9:07 PM, Alan Cox [EMAIL PROTECTED] wrote: This message comes from 2.6.24-rc3 + todays git, version a531a141089714efe39eca89593524fdf05104f2. I did grep the logs and found that it first appeared in 2.6.24-rc1 (+ some git mayve) on Nov 3. I used 2.6.23 before that and it did not show this message. Can you stick a stack trace in at that point ? That would help diagnose it a great deal quicker. I've also been seeing this for a while on my Dell Latitude D610, but stuff just works, so... I'm overloaded at this time, if nobody gets there first I'll give a go at tracing this next week. --alessandro Damaged people are dangerous. They know they can survive. (Anna Barton/Juliette Binoche, 'Damage') - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is there any word about this bug in gcc ?
On Nov 20, 2007 7:52 AM, Herbert Xu <[EMAIL PROTECTED]> wrote: > On Mon, Nov 19, 2007 at 10:47:59PM -0800, H. Peter Anvin wrote: > > > > This one is definitely messy. There is absolutely no way to know what > > gcc has miscompiled. It looks to me that both gcc 4.2 and 4.3 are > > affected, any others? > > I just tested it here and gcc 3.3 is also affected so presumably > everything in between is too. Gcc 2.95 is not affected. I don't > have the intervening versions to test. Fedora 7's 4.1.2-27 is also affected. --alessandro "you feel the sweet breath of time it's whispering, its truth not mine" (Interpol, 'No I In Threesome') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is there any word about this bug in gcc ?
On Nov 20, 2007 7:52 AM, Herbert Xu [EMAIL PROTECTED] wrote: On Mon, Nov 19, 2007 at 10:47:59PM -0800, H. Peter Anvin wrote: This one is definitely messy. There is absolutely no way to know what gcc has miscompiled. It looks to me that both gcc 4.2 and 4.3 are affected, any others? I just tested it here and gcc 3.3 is also affected so presumably everything in between is too. Gcc 2.95 is not affected. I don't have the intervening versions to test. Fedora 7's 4.1.2-27 is also affected. --alessandro you feel the sweet breath of time it's whispering, its truth not mine (Interpol, 'No I In Threesome') - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[possibly OT] for_each_netdev() in 2.6.23-gitX / 2.6.24-rc1-gitY breaks Cisco VPN client
It's been a while I noticed, but I thought someone would as usual cook up some fix, while I don't even see the issue been reported... if this isn't a Linux kernel/net issue just drop my email, thanks. Error message during cisco_vpn.ko build: /download/linux/net/vpnclient/interceptor.c:345:23: error: macro "for_each_netdev" requires 2 arguments, but only 1 given seems like for_each_netdev() now also uses init_net. If there is an alternative and somebody could point me to that, it'd be great, as understanding the issue is well out of my grasp. Patching up the vpnclient source to use init_net gets me to depmod complaining it's not allowed to use a GPL-only symbol (init_net) in a proprietary module. If this is meant to be - fine, and apologies for the waste of bandwidth; but if this is simply an unwanted side effect of the recent changes, perhaps it's a good idea to have it at least reported. --alessandro "you feel the sweet breath of time it's whispering, its truth not mine" (Interpol, 'No I In Threesome') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[possibly OT] for_each_netdev() in 2.6.23-gitX / 2.6.24-rc1-gitY breaks Cisco VPN client
It's been a while I noticed, but I thought someone would as usual cook up some fix, while I don't even see the issue been reported... if this isn't a Linux kernel/net issue just drop my email, thanks. Error message during cisco_vpn.ko build: /download/linux/net/vpnclient/interceptor.c:345:23: error: macro for_each_netdev requires 2 arguments, but only 1 given seems like for_each_netdev() now also uses init_net. If there is an alternative and somebody could point me to that, it'd be great, as understanding the issue is well out of my grasp. Patching up the vpnclient source to use init_net gets me to depmod complaining it's not allowed to use a GPL-only symbol (init_net) in a proprietary module. If this is meant to be - fine, and apologies for the waste of bandwidth; but if this is simply an unwanted side effect of the recent changes, perhaps it's a good idea to have it at least reported. --alessandro you feel the sweet breath of time it's whispering, its truth not mine (Interpol, 'No I In Threesome') - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git10 make bzImage problem
On 10/17/07, Sid Boyce <[EMAIL PROTECTED]> wrote: > When booted, it complains that kernel size is too big, but size OK for a > bzImage, not for zImage as is returned by the file command, -git9 was > OK, x86_64 SMP kernel on two 64x2 boxes. > I shall supplymy .config if needed, but they are the same as for -git9. > > # l arch/x86/boot/bzImage > -rw-r--r-- 1 root root 1761496 2007-10-16 22:45 arch/x86/boot/bzImage > > # file arch/x86_64/boot/bzImage > arch/x86_64/boot/bzImage: symbolic link to > `/usr/src/linux-2.6.23-git10/arch/x86/boot/bzImage' > > # file arch/x86/boot/bzImage > arch/x86/boot/bzImage: Linux/x86 Kernel, Setup Version 0x206, zImage, > RO-rootFS, root_dev 0x801, swap_dev 0x1, Prompt for Videomode Same here - but it -git13 seems to be back to proper behavior... [EMAIL PROTECTED] boot]$ file vmlinuz-2.6.23-git? vmlinuz-2.6.23-git?? vmlinuz-2.6.23-git3: Linux kernel x86 boot executable RO-rootFS, root_dev 0x807, swap_dev 0x1, Normal VGA vmlinuz-2.6.23-git6: Linux kernel x86 boot executable RO-rootFS, root_dev 0x807, swap_dev 0x1, Normal VGA vmlinuz-2.6.23-git10: Linux kernel x86 boot executable zImage, version 2.6.23-git10 ([EMAIL PROTECTED]) , RO-rootFS, root_dev 0x807, swap_dev 0x1, Prompt for Videomode vmlinuz-2.6.23-git13: Linux kernel x86 boot executable RO-rootFS, root_dev 0x807, swap_dev 0x1, Normal VGA --alessandro "you feel the sweet breath of time it's whispering, its truth not mine" (Interpol, 'No I In Threesome') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git10 make bzImage problem
On 10/17/07, Sid Boyce [EMAIL PROTECTED] wrote: When booted, it complains that kernel size is too big, but size OK for a bzImage, not for zImage as is returned by the file command, -git9 was OK, x86_64 SMP kernel on two 64x2 boxes. I shall supplymy .config if needed, but they are the same as for -git9. # l arch/x86/boot/bzImage -rw-r--r-- 1 root root 1761496 2007-10-16 22:45 arch/x86/boot/bzImage # file arch/x86_64/boot/bzImage arch/x86_64/boot/bzImage: symbolic link to `/usr/src/linux-2.6.23-git10/arch/x86/boot/bzImage' # file arch/x86/boot/bzImage arch/x86/boot/bzImage: Linux/x86 Kernel, Setup Version 0x206, zImage, RO-rootFS, root_dev 0x801, swap_dev 0x1, Prompt for Videomode Same here - but it -git13 seems to be back to proper behavior... [EMAIL PROTECTED] boot]$ file vmlinuz-2.6.23-git? vmlinuz-2.6.23-git?? vmlinuz-2.6.23-git3: Linux kernel x86 boot executable RO-rootFS, root_dev 0x807, swap_dev 0x1, Normal VGA vmlinuz-2.6.23-git6: Linux kernel x86 boot executable RO-rootFS, root_dev 0x807, swap_dev 0x1, Normal VGA vmlinuz-2.6.23-git10: Linux kernel x86 boot executable zImage, version 2.6.23-git10 ([EMAIL PROTECTED]) , RO-rootFS, root_dev 0x807, swap_dev 0x1, Prompt for Videomode vmlinuz-2.6.23-git13: Linux kernel x86 boot executable RO-rootFS, root_dev 0x807, swap_dev 0x1, Normal VGA --alessandro you feel the sweet breath of time it's whispering, its truth not mine (Interpol, 'No I In Threesome') - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git3 compilation broken, asm headers missing?
On 10/14/07, Patrizio Bassi <[EMAIL PROTECTED]> wrote: > Thomas Gleixner ha scritto: > > On Sat, 13 Oct 2007, Patrizio Bassi wrote: > > > >> include/linux/types.h:15:23: error: asm/types.h: No such file or directory > >> In file included from include/linux/prefetch.h:13, > >> from include/linux/list.h:8, > >> from include/linux/module.h:9, > >> from include/linux/crypto.h:21, > >> from arch/x86/kernel/asm-offsets_32.c:7, > >> from arch/x86/kernel/asm-offsets.c:2: > >> > >> full log attached. > >> > > > > That's a stale include/asm symlink. Can you save your .config file and do > > > > make mrproper > > > > please and check if it's solved. > > > > Thanks, > > > > tglx > > > > > > > seems ok now > > Thanks! Same issue here, and as well making mrproper fixes it. Thanks, ciao, --alessandro "you feel the sweet breath of time it's whispering, its truth not mine" (Interpol, 'No I In Threesome') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git3 compilation broken, asm headers missing?
On 10/14/07, Patrizio Bassi [EMAIL PROTECTED] wrote: Thomas Gleixner ha scritto: On Sat, 13 Oct 2007, Patrizio Bassi wrote: include/linux/types.h:15:23: error: asm/types.h: No such file or directory In file included from include/linux/prefetch.h:13, from include/linux/list.h:8, from include/linux/module.h:9, from include/linux/crypto.h:21, from arch/x86/kernel/asm-offsets_32.c:7, from arch/x86/kernel/asm-offsets.c:2: full log attached. That's a stale include/asm symlink. Can you save your .config file and do make mrproper please and check if it's solved. Thanks, tglx seems ok now Thanks! Same issue here, and as well making mrproper fixes it. Thanks, ciao, --alessandro you feel the sweet breath of time it's whispering, its truth not mine (Interpol, 'No I In Threesome') - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc5
On 9/3/07, Gabriel C <[EMAIL PROTECTED]> wrote: > Rafael J. Wysocki wrote: > > On Sunday, 2 September 2007 09:54, Prakash Punnoor wrote: > >> Hi, > >> > >> 2.6.23-rc5 locks up hard (Magic Syskeys won't even work) after a few > >> minutes > >> of work on x86_64. 2.6.23-rc4 was fine. I'll try git-bisect to find out > >> what > >> is causing trouble. Yes, I am using nvidia binary but it didn't make > >> troubles > >> since ages... When I found the bugger, I'll try whether it works w/o nvidia > >> binary. > > > > Just for the record, I'm running -rc5 on two x86_64 boxes without any > > visible > > issue. > > > > I don't use any binary graphics drivers, though. > > 2.6.23-rc5 dies here random[1] too .. on 2 Dell boxes ( i686 not x86_64 here > ) which I upgraded to rc5 yesterday. > > When dies 'Caps Lock and Scroll Lock' blinks and the box lockups hard .. rc4 > got an 7 days uptime on both with the same config , > kernel compiled with same gcc/glibc/binutils etc. [snip] This one has bitten many of us :) http://lkml.org/lkml/2007/9/2/219 --alessandro "I can't believe you if I can't hear you" (Editors, 'Smokers Outside The Hospital Doors') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc5
On 9/3/07, Gabriel C [EMAIL PROTECTED] wrote: Rafael J. Wysocki wrote: On Sunday, 2 September 2007 09:54, Prakash Punnoor wrote: Hi, 2.6.23-rc5 locks up hard (Magic Syskeys won't even work) after a few minutes of work on x86_64. 2.6.23-rc4 was fine. I'll try git-bisect to find out what is causing trouble. Yes, I am using nvidia binary but it didn't make troubles since ages... When I found the bugger, I'll try whether it works w/o nvidia binary. Just for the record, I'm running -rc5 on two x86_64 boxes without any visible issue. I don't use any binary graphics drivers, though. 2.6.23-rc5 dies here random[1] too .. on 2 Dell boxes ( i686 not x86_64 here ) which I upgraded to rc5 yesterday. When dies 'Caps Lock and Scroll Lock' blinks and the box lockups hard .. rc4 got an 7 days uptime on both with the same config , kernel compiled with same gcc/glibc/binutils etc. [snip] This one has bitten many of us :) http://lkml.org/lkml/2007/9/2/219 --alessandro I can't believe you if I can't hear you (Editors, 'Smokers Outside The Hospital Doors') - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hang in 2.6.23-rc5
On 9/3/07, Satyam Sharma <[EMAIL PROTECTED]> wrote: > > > On Mon, 3 Sep 2007, Alexey Dobriyan wrote: > > > > Try this from net-2.6 tree: > > > > --- a/net/ipv4/tcp_input.c > > +++ b/net/ipv4/tcp_input.c > > @@ -560,7 +560,7 @@ static u32 tcp_rto_min(struct sock *sk) > > struct dst_entry *dst = __sk_dst_get(sk); > > u32 rto_min = TCP_RTO_MIN; > > > > - if (dst_metric_locked(dst, RTAX_RTO_MIN)) > > + if (dst && dst_metric_locked(dst, RTAX_RTO_MIN)) > > rto_min = dst->metrics[RTAX_RTO_MIN-1]; > > return rto_min; > > } > > That's my impression as well. That's way too core/busy a codepath to have > a bug in. As I said earlier, almost anybody testing -rc5 is sure to hit > this within a few hours (probably less) -- sad, it greatly erodes from the > usefulness of -rc5 as a release candidate. > Well - when my box locked up I was also doing a 300MB scp through my ipw2200 wireless interface. But I did another today and nothing bad happened. In another email someone mentioned /var/log/messages - no, that was totally void of anything peculiar, despite the fact that I rebooted via Alt-SysRq T / P / S / U / B (this last did reboot the box). Upon restart however no, nothing in /var/log/messages. Didn't think it was the case to set up netconsole - only one occurrence AND with VMWare modules loaded... I will apply the above fix and will post again in case the hang issue pops up again. Thanks, ciao, --alessandro "I can't believe you if I can't hear you" (Editors, 'Smokers Outside The Hospital Doors') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hang in 2.6.23-rc5
On 9/2/07, charles gagalac <[EMAIL PROTECTED]> wrote: > On 9/2/07, daryll q wrote: > > Upgraded my kernel from 2.6.23-rc2 to 2.6.23-rc5. > > > > System hangs (caps lock and scroll lock leds are both flashing). > > > > It *randomly* happens but most of the time during after login to KDE. > > > > I have not investigated it yet because I have not tried doing it before. > > > > Also the system is really not responding so I can't do much.. Just > > hope it blue screen so I can send the error code easily :) > > i experienced hangs, with the flashing caps and scroll locks as you've > described, in a few of my later pulls prior to rc5. i couldn't > reproduce the hangs and my logs didn't show evidence of a problem. my > system under rc5, so far, hasn't hung on me. > > charles Oh, I thought I was the only one. I also had a single hang+flashing Caps & Scroll Lock with -rc5, but haven't had one since. I had VMWare Player modules loaded at the time though, and I recently rebuilt them with the any-any-patch-113 (earlier versions would not build with very recent kernels). -rc4-git2 and -git3 never hung even with VMWare modules loaded. So I disabled the autoload of VMWare stuff. The problem has not reproduced so far. My system is a Dell D610, running updated Fedora 7, with Intel 915GM video chipset. --alessandro "I can't believe you if I can't hear you" (Editors, 'Smokers Outside The Hospital Doors') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hang in 2.6.23-rc5
On 9/2/07, charles gagalac [EMAIL PROTECTED] wrote: On 9/2/07, daryll q wrote: Upgraded my kernel from 2.6.23-rc2 to 2.6.23-rc5. System hangs (caps lock and scroll lock leds are both flashing). It *randomly* happens but most of the time during after login to KDE. I have not investigated it yet because I have not tried doing it before. Also the system is really not responding so I can't do much.. Just hope it blue screen so I can send the error code easily :) i experienced hangs, with the flashing caps and scroll locks as you've described, in a few of my later pulls prior to rc5. i couldn't reproduce the hangs and my logs didn't show evidence of a problem. my system under rc5, so far, hasn't hung on me. charles Oh, I thought I was the only one. I also had a single hang+flashing Caps Scroll Lock with -rc5, but haven't had one since. I had VMWare Player modules loaded at the time though, and I recently rebuilt them with the any-any-patch-113 (earlier versions would not build with very recent kernels). -rc4-git2 and -git3 never hung even with VMWare modules loaded. So I disabled the autoload of VMWare stuff. The problem has not reproduced so far. My system is a Dell D610, running updated Fedora 7, with Intel 915GM video chipset. --alessandro I can't believe you if I can't hear you (Editors, 'Smokers Outside The Hospital Doors') - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hang in 2.6.23-rc5
On 9/3/07, Satyam Sharma [EMAIL PROTECTED] wrote: On Mon, 3 Sep 2007, Alexey Dobriyan wrote: Try this from net-2.6 tree: --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -560,7 +560,7 @@ static u32 tcp_rto_min(struct sock *sk) struct dst_entry *dst = __sk_dst_get(sk); u32 rto_min = TCP_RTO_MIN; - if (dst_metric_locked(dst, RTAX_RTO_MIN)) + if (dst dst_metric_locked(dst, RTAX_RTO_MIN)) rto_min = dst-metrics[RTAX_RTO_MIN-1]; return rto_min; } That's my impression as well. That's way too core/busy a codepath to have a bug in. As I said earlier, almost anybody testing -rc5 is sure to hit this within a few hours (probably less) -- sad, it greatly erodes from the usefulness of -rc5 as a release candidate. Well - when my box locked up I was also doing a 300MB scp through my ipw2200 wireless interface. But I did another today and nothing bad happened. In another email someone mentioned /var/log/messages - no, that was totally void of anything peculiar, despite the fact that I rebooted via Alt-SysRq T / P / S / U / B (this last did reboot the box). Upon restart however no, nothing in /var/log/messages. Didn't think it was the case to set up netconsole - only one occurrence AND with VMWare modules loaded... I will apply the above fix and will post again in case the hang issue pops up again. Thanks, ciao, --alessandro I can't believe you if I can't hear you (Editors, 'Smokers Outside The Hospital Doors') - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Touchpad loses sync with ACPI on.
On 8/2/07, Matthew Marshall <[EMAIL PROTECTED]> wrote: > I am having a problem with the touchpad and pointer stick on my HP compaq > nc6000 laptop. It only happens when using ACPI. > > Both pointing devices work for a while, but eventually start to 'stick'. The > cursor won't move for about a second, and then it jerks all over the screen, > clicking. > > This problem gradually increases in frequency, until eventually neither device > works at all. Even cat'ing the respective /dev/input/event* device doesn't > return anything, and I have to shut down or suspend the computer for > about 15 minutes before it will work again. (simply rebooting doesn't fix > it.) (Actually, it sometimes works if I press down REALLY hard... perhaps > that's due to some sensitivity threshold being automatically adjusted?) > > Everything works perfectly if I boot with acpi=off. > > (I also left Windows open all day once, and it didn't happen there either.) > > I'm using kubuntu, and have tested it with kernel 2.6.20, 2.6.22.1, and > 2.6.23-rc1. > > When the problem happens, I get lines like this from dmesg: > > psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 > > or sometimes like this: > > psmouse.c: TouchPad at isa0060/serio4/input0 lost synchronization, throwing 4 > bytes away. > > > From Google I have found a few other similar reports. For one person this > seems to happen under load. For me, it sometimes seems to happen right when > I start to compile or something, but it will also happen when I boot up the > computer and don't even touch it. (literally: I'll come back in a half an > hour and the TP doesn't work.) > > Someone else seemed to have the problem from reading ACPI states. I have not > been able to find any correlation in this respect. I booted up without the > battery panel applet and without starting acpid, and it still started > hiccuping after 5 minutes. > > There seems to be no correlation between how much I use it and how long it > lasts. Sometimes I can be using it constantly and it lasts an hour. > Sometimes I barely touch it and it lasts only 10 minutes. > > I'm attaching the output of dmesg, lshw, lsmod and lspci. > > So, what more can I do? Is there any more information I can provide? Are > there any patches I can try? I'm willing to help out any way I can. > > Thanks for reading, > Matthew Marshall > > P.S. I'm not subscribed, so please CC any replies. > > P.P.S. Sometimes it seems to be able to read my mind... Just when I think "wow > it's lasting a long time!" it will freeze up within two seconds. I > understand that this might be hard for others to reproduce. I had a total of three occurrences of a stuck touchpad on my Dell D610 since upgrading to Fedora 7, with custom kernels (FC6 was used up to 2.6.22-rc7-git2, never saw the issue): [EMAIL PROTECTED] ~]# grep -i psmouse /var/log/messages.1 /var/log/messages /var/log/messages.1:Jul 25 22:53:12 sandman kernel: psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 3 bytes away. /var/log/messages.1:Jul 25 22:53:13 sandman kernel: psmouse.c: resync failed, issuing reconnect request /var/log/messages.1:Jul 27 10:43:39 sandman kernel: psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 3 bytes away. /var/log/messages.1:Jul 27 10:43:40 sandman kernel: psmouse.c: resync failed, issuing reconnect request /var/log/messages:Jul 30 14:51:20 sandman kernel: psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 3 bytes away. /var/log/messages:Jul 30 14:51:21 sandman kernel: psmouse.c: resync failed, issuing reconnect request I always use the touchpad and never the stick, and actually found out that when the touchpad stops working with the cursor disappearing, it's a good workaround to move the stick to get the cursor back (I assume moving the stick is what actually causes the above messages). --alessandro "Did you get married but forgot to get divorced ?" (Danny and Dusty, 'The Good Old Days') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Touchpad loses sync with ACPI on.
On 8/2/07, Matthew Marshall [EMAIL PROTECTED] wrote: I am having a problem with the touchpad and pointer stick on my HP compaq nc6000 laptop. It only happens when using ACPI. Both pointing devices work for a while, but eventually start to 'stick'. The cursor won't move for about a second, and then it jerks all over the screen, clicking. This problem gradually increases in frequency, until eventually neither device works at all. Even cat'ing the respective /dev/input/event* device doesn't return anything, and I have to shut down or suspend the computer for about 15 minutes before it will work again. (simply rebooting doesn't fix it.) (Actually, it sometimes works if I press down REALLY hard... perhaps that's due to some sensitivity threshold being automatically adjusted?) Everything works perfectly if I boot with acpi=off. (I also left Windows open all day once, and it didn't happen there either.) I'm using kubuntu, and have tested it with kernel 2.6.20, 2.6.22.1, and 2.6.23-rc1. When the problem happens, I get lines like this from dmesg: psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 or sometimes like this: psmouse.c: TouchPad at isa0060/serio4/input0 lost synchronization, throwing 4 bytes away. From Google I have found a few other similar reports. For one person this seems to happen under load. For me, it sometimes seems to happen right when I start to compile or something, but it will also happen when I boot up the computer and don't even touch it. (literally: I'll come back in a half an hour and the TP doesn't work.) Someone else seemed to have the problem from reading ACPI states. I have not been able to find any correlation in this respect. I booted up without the battery panel applet and without starting acpid, and it still started hiccuping after 5 minutes. There seems to be no correlation between how much I use it and how long it lasts. Sometimes I can be using it constantly and it lasts an hour. Sometimes I barely touch it and it lasts only 10 minutes. I'm attaching the output of dmesg, lshw, lsmod and lspci. So, what more can I do? Is there any more information I can provide? Are there any patches I can try? I'm willing to help out any way I can. Thanks for reading, Matthew Marshall P.S. I'm not subscribed, so please CC any replies. P.P.S. Sometimes it seems to be able to read my mind... Just when I think wow it's lasting a long time! it will freeze up within two seconds. I understand that this might be hard for others to reproduce. I had a total of three occurrences of a stuck touchpad on my Dell D610 since upgrading to Fedora 7, with custom kernels (FC6 was used up to 2.6.22-rc7-git2, never saw the issue): [EMAIL PROTECTED] ~]# grep -i psmouse /var/log/messages.1 /var/log/messages /var/log/messages.1:Jul 25 22:53:12 sandman kernel: psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 3 bytes away. /var/log/messages.1:Jul 25 22:53:13 sandman kernel: psmouse.c: resync failed, issuing reconnect request /var/log/messages.1:Jul 27 10:43:39 sandman kernel: psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 3 bytes away. /var/log/messages.1:Jul 27 10:43:40 sandman kernel: psmouse.c: resync failed, issuing reconnect request /var/log/messages:Jul 30 14:51:20 sandman kernel: psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 3 bytes away. /var/log/messages:Jul 30 14:51:21 sandman kernel: psmouse.c: resync failed, issuing reconnect request I always use the touchpad and never the stick, and actually found out that when the touchpad stops working with the cursor disappearing, it's a good workaround to move the stick to get the cursor back (I assume moving the stick is what actually causes the above messages). --alessandro Did you get married but forgot to get divorced ? (Danny and Dusty, 'The Good Old Days') - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
On 7/23/07, Ismail Dönmez <[EMAIL PROTECTED]> wrote: On Monday 23 July 2007 19:43:56 Gabriel C wrote: > I get some ACPI Exception. > > ... > > [ 33.075429] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, > Evaluating _PTC [20070126] [ 33.075437] ACPI Exception > (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [ > 33.075490] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, > Evaluating _PTC [20070126] [ 33.075497] ACPI Exception > (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [ > 33.075529] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, > Evaluating _PTC [20070126] [ 33.075536] ACPI Exception > (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [ > 33.075563] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, > Evaluating _PTC [20070126] [ 33.075570] ACPI Exception > (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] > Same here, I was about to blame my holy Vaio, but latest ACPI merge is to blame instead. Add me too, Dell D610, 2.6.23-rc1 on top of Fedora 7. --alessandro "Did you get married but forgot to get divorced ?" (Danny and Dusty, 'The Good Old Days') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
On 7/23/07, Ismail Dönmez [EMAIL PROTECTED] wrote: On Monday 23 July 2007 19:43:56 Gabriel C wrote: I get some ACPI Exception. ... [ 33.075429] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating _PTC [20070126] [ 33.075437] ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [ 33.075490] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating _PTC [20070126] [ 33.075497] ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [ 33.075529] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating _PTC [20070126] [ 33.075536] ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [ 33.075563] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating _PTC [20070126] [ 33.075570] ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] Same here, I was about to blame my holy Vaio, but latest ACPI merge is to blame instead. Add me too, Dell D610, 2.6.23-rc1 on top of Fedora 7. --alessandro Did you get married but forgot to get divorced ? (Danny and Dusty, 'The Good Old Days') - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: clocksource change of behavior in 2.6.22 compared to 2.6.20 causes massive system clock slowdown
On 7/18/07, john stultz <[EMAIL PROTECTED]> wrote: On Wed, 2007-07-18 at 00:31 +0200, Alessandro Suardi wrote: > On 7/11/07, john stultz <[EMAIL PROTECTED]> wrote: > > On Wed, 2007-07-11 at 01:31 +0200, Alessandro Suardi wrote: > > > On 7/10/07, john stultz <[EMAIL PROTECTED]> wrote: > > > > On Tue, 2007-07-10 at 00:29 -0700, Andrew Morton wrote: > > > > > On Mon, 9 Jul 2007 16:27:59 +0200 "Alessandro Suardi" <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > My oldish AMD K7-800's clock began falling behind after > > > > > > rebooting from 2.6.20 (and 109 days uptime with a spotless > > > > > > clock) into 2.6.22; time lost is about four minutes each hour. > > > > > > > > > > > > Turns out that 2.6.22 marks my TSC as unstable and starts > > > > > > using PIT instead. Rebooting 2.6.22 with clocksource=tsc > > > > > > gets the original stable system time back. > > > > > > > > Alessandro, > > > > Can you send me dmesg output for 2.6.20 and 2.6.22 (without > > > > clocksource=tsc)? > > > > > > Actually, I lied a little bit - it was 2.6.22 with clock=tsc (which > > > warns on boot about clock= being deprecated in favor of > > > clocksource= ). I assume behavior is identical for now. > > > > > > Please find attached the dmesg ring (incomplete, as the > > > kernel ring size I have seems too small to hold the full > > > buffer, but it seems to have all the interesting stuff) of > > > 2.6.20, 2.6.22, 2.6.22 with clock=tsc. > > > > > > If you need more info, just ask. I'll be out of the country > > > from July 12 to the morning of July 16, and again from > > > July 17 to July 20, so if you'd rather get at this later on, > > > it's okay for me ;) > > > > You're dmesg output got chopped at the top. Please increase the kernel > > log buffer size. > > Done, please find attached both 2620 and 2622 full dmesg output, > with no clock= or clocksource= parameters. > > > Sounds like your PIT frequency is out of whack, and I'm guessing the > > generic clocksource watchdog blames the TSC and disqualifies it. > > > > Few things to check: > > 1) Make sure you're running the latest BIOS. > > I'm probably not, though I'm not sure I'd flash anything on such > an old machine - been running it since RedHat 9 with the > current BIOS. Plus, I removed the floppy drive to make room > for an extra IDE disk... it'd take me a little bit to find out whether > I still have the floppy drive around. > > > 2) See if booting w/ noapic changes anything > > Nope, 2622+noapic => PIT is still used and clock very quickly > lags behind. > > For the moment being I'll keep booting with clocksource=tsc. > Let me know whether you want me to test anything more... Hmm. One other thing to check: If you boot 2.6.20 w/ clocksource=pit, is it consistent w/ 2.6.22 and same slow timekeeping issue shows up? Yes, 2620+clocksource=pit is noticeably slow in timekeeping as well. From my laptop (Dell D610 running 2.6.22-git10 on top of Fedora7) I ssh'd into my K7-800 and with two terminal windows I ran the same simple bash loop, starting more or less at the same time: while :; do let i=i+1; echo $i; sleep 1; done When the laptop reached 60, the K7-800 was at 57. In order to eliminate any possible doubt about how I started the two sessions, I let the loop run; when the laptop reached 120, the K7-800 was displaying 114. So it's indeed a 3-second per minute loss with PIT in either 2620 or 2622. --alessandro "Did you get married but forgot to get divorced ?" (Danny and Dusty, 'The Good Old Days') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: clocksource change of behavior in 2.6.22 compared to 2.6.20 causes massive system clock slowdown
On 7/18/07, john stultz [EMAIL PROTECTED] wrote: On Wed, 2007-07-18 at 00:31 +0200, Alessandro Suardi wrote: On 7/11/07, john stultz [EMAIL PROTECTED] wrote: On Wed, 2007-07-11 at 01:31 +0200, Alessandro Suardi wrote: On 7/10/07, john stultz [EMAIL PROTECTED] wrote: On Tue, 2007-07-10 at 00:29 -0700, Andrew Morton wrote: On Mon, 9 Jul 2007 16:27:59 +0200 Alessandro Suardi [EMAIL PROTECTED] wrote: My oldish AMD K7-800's clock began falling behind after rebooting from 2.6.20 (and 109 days uptime with a spotless clock) into 2.6.22; time lost is about four minutes each hour. Turns out that 2.6.22 marks my TSC as unstable and starts using PIT instead. Rebooting 2.6.22 with clocksource=tsc gets the original stable system time back. Alessandro, Can you send me dmesg output for 2.6.20 and 2.6.22 (without clocksource=tsc)? Actually, I lied a little bit - it was 2.6.22 with clock=tsc (which warns on boot about clock= being deprecated in favor of clocksource= ). I assume behavior is identical for now. Please find attached the dmesg ring (incomplete, as the kernel ring size I have seems too small to hold the full buffer, but it seems to have all the interesting stuff) of 2.6.20, 2.6.22, 2.6.22 with clock=tsc. If you need more info, just ask. I'll be out of the country from July 12 to the morning of July 16, and again from July 17 to July 20, so if you'd rather get at this later on, it's okay for me ;) You're dmesg output got chopped at the top. Please increase the kernel log buffer size. Done, please find attached both 2620 and 2622 full dmesg output, with no clock= or clocksource= parameters. Sounds like your PIT frequency is out of whack, and I'm guessing the generic clocksource watchdog blames the TSC and disqualifies it. Few things to check: 1) Make sure you're running the latest BIOS. I'm probably not, though I'm not sure I'd flash anything on such an old machine - been running it since RedHat 9 with the current BIOS. Plus, I removed the floppy drive to make room for an extra IDE disk... it'd take me a little bit to find out whether I still have the floppy drive around. 2) See if booting w/ noapic changes anything Nope, 2622+noapic = PIT is still used and clock very quickly lags behind. For the moment being I'll keep booting with clocksource=tsc. Let me know whether you want me to test anything more... Hmm. One other thing to check: If you boot 2.6.20 w/ clocksource=pit, is it consistent w/ 2.6.22 and same slow timekeeping issue shows up? Yes, 2620+clocksource=pit is noticeably slow in timekeeping as well. From my laptop (Dell D610 running 2.6.22-git10 on top of Fedora7) I ssh'd into my K7-800 and with two terminal windows I ran the same simple bash loop, starting more or less at the same time: while :; do let i=i+1; echo $i; sleep 1; done When the laptop reached 60, the K7-800 was at 57. In order to eliminate any possible doubt about how I started the two sessions, I let the loop run; when the laptop reached 120, the K7-800 was displaying 114. So it's indeed a 3-second per minute loss with PIT in either 2620 or 2622. --alessandro Did you get married but forgot to get divorced ? (Danny and Dusty, 'The Good Old Days') - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: clocksource change of behavior in 2.6.22 compared to 2.6.20 causes massive system clock slowdown
On 7/11/07, john stultz <[EMAIL PROTECTED]> wrote: On Wed, 2007-07-11 at 01:31 +0200, Alessandro Suardi wrote: > On 7/10/07, john stultz <[EMAIL PROTECTED]> wrote: > > On Tue, 2007-07-10 at 00:29 -0700, Andrew Morton wrote: > > > On Mon, 9 Jul 2007 16:27:59 +0200 "Alessandro Suardi" <[EMAIL PROTECTED]> wrote: > > > > > > > My oldish AMD K7-800's clock began falling behind after > > > > rebooting from 2.6.20 (and 109 days uptime with a spotless > > > > clock) into 2.6.22; time lost is about four minutes each hour. > > > > > > > > Turns out that 2.6.22 marks my TSC as unstable and starts > > > > using PIT instead. Rebooting 2.6.22 with clocksource=tsc > > > > gets the original stable system time back. > > > > Alessandro, > > Can you send me dmesg output for 2.6.20 and 2.6.22 (without > > clocksource=tsc)? > > Actually, I lied a little bit - it was 2.6.22 with clock=tsc (which > warns on boot about clock= being deprecated in favor of > clocksource= ). I assume behavior is identical for now. > > Please find attached the dmesg ring (incomplete, as the > kernel ring size I have seems too small to hold the full > buffer, but it seems to have all the interesting stuff) of > 2.6.20, 2.6.22, 2.6.22 with clock=tsc. > > If you need more info, just ask. I'll be out of the country > from July 12 to the morning of July 16, and again from > July 17 to July 20, so if you'd rather get at this later on, > it's okay for me ;) You're dmesg output got chopped at the top. Please increase the kernel log buffer size. Done, please find attached both 2620 and 2622 full dmesg output, with no clock= or clocksource= parameters. Sounds like your PIT frequency is out of whack, and I'm guessing the generic clocksource watchdog blames the TSC and disqualifies it. Few things to check: 1) Make sure you're running the latest BIOS. I'm probably not, though I'm not sure I'd flash anything on such an old machine - been running it since RedHat 9 with the current BIOS. Plus, I removed the floppy drive to make room for an extra IDE disk... it'd take me a little bit to find out whether I still have the floppy drive around. 2) See if booting w/ noapic changes anything Nope, 2622+noapic => PIT is still used and clock very quickly lags behind. For the moment being I'll keep booting with clocksource=tsc. Let me know whether you want me to test anything more... thanks, ciao, --alessandro "Did you get married but forgot to get divorced ?" (Danny and Dusty, 'The Good Old Days') dmesg-2620.out Description: Binary data dmesg-2622.out Description: Binary data
Re: clocksource change of behavior in 2.6.22 compared to 2.6.20 causes massive system clock slowdown
On 7/11/07, john stultz [EMAIL PROTECTED] wrote: On Wed, 2007-07-11 at 01:31 +0200, Alessandro Suardi wrote: On 7/10/07, john stultz [EMAIL PROTECTED] wrote: On Tue, 2007-07-10 at 00:29 -0700, Andrew Morton wrote: On Mon, 9 Jul 2007 16:27:59 +0200 Alessandro Suardi [EMAIL PROTECTED] wrote: My oldish AMD K7-800's clock began falling behind after rebooting from 2.6.20 (and 109 days uptime with a spotless clock) into 2.6.22; time lost is about four minutes each hour. Turns out that 2.6.22 marks my TSC as unstable and starts using PIT instead. Rebooting 2.6.22 with clocksource=tsc gets the original stable system time back. Alessandro, Can you send me dmesg output for 2.6.20 and 2.6.22 (without clocksource=tsc)? Actually, I lied a little bit - it was 2.6.22 with clock=tsc (which warns on boot about clock= being deprecated in favor of clocksource= ). I assume behavior is identical for now. Please find attached the dmesg ring (incomplete, as the kernel ring size I have seems too small to hold the full buffer, but it seems to have all the interesting stuff) of 2.6.20, 2.6.22, 2.6.22 with clock=tsc. If you need more info, just ask. I'll be out of the country from July 12 to the morning of July 16, and again from July 17 to July 20, so if you'd rather get at this later on, it's okay for me ;) You're dmesg output got chopped at the top. Please increase the kernel log buffer size. Done, please find attached both 2620 and 2622 full dmesg output, with no clock= or clocksource= parameters. Sounds like your PIT frequency is out of whack, and I'm guessing the generic clocksource watchdog blames the TSC and disqualifies it. Few things to check: 1) Make sure you're running the latest BIOS. I'm probably not, though I'm not sure I'd flash anything on such an old machine - been running it since RedHat 9 with the current BIOS. Plus, I removed the floppy drive to make room for an extra IDE disk... it'd take me a little bit to find out whether I still have the floppy drive around. 2) See if booting w/ noapic changes anything Nope, 2622+noapic = PIT is still used and clock very quickly lags behind. For the moment being I'll keep booting with clocksource=tsc. Let me know whether you want me to test anything more... thanks, ciao, --alessandro Did you get married but forgot to get divorced ? (Danny and Dusty, 'The Good Old Days') dmesg-2620.out Description: Binary data dmesg-2622.out Description: Binary data
clocksource change of behavior in 2.6.22 compared to 2.6.20 causes massive system clock slowdown
My oldish AMD K7-800's clock began falling behind after rebooting from 2.6.20 (and 109 days uptime with a spotless clock) into 2.6.22; time lost is about four minutes each hour. Turns out that 2.6.22 marks my TSC as unstable and starts using PIT instead. Rebooting 2.6.22 with clocksource=tsc gets the original stable system time back. Not sure whether this is supposed to be the default way of fixing the issue on older machines, though; if anyone sees a problem with this, I'm up for providing more information. [EMAIL PROTECTED] ~]# cd /sys/devices/system/clocksource/clocksource0/ [EMAIL PROTECTED] clocksource0]# cat available_clocksource pit jiffies tsc [EMAIL PROTECTED] clocksource0]# cat current_clocksource tsc [EMAIL PROTECTED] clocksource0]# uname -a Linux donkey 2.6.22 #1 PREEMPT Mon Jul 9 13:26:38 CEST 2007 i686 athlon i386 GNU/Linux [EMAIL PROTECTED] clocksource0]# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 4 model name : AMD Athlon(tm) Processor stepping: 2 cpu MHz : 800.068 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips: 1603.17 clflush size: 32 thanks, ciao, --alessandro "Did you get married but forgot to get divorced ?" (Danny and Dusty, 'The Good Old Days') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
clocksource change of behavior in 2.6.22 compared to 2.6.20 causes massive system clock slowdown
My oldish AMD K7-800's clock began falling behind after rebooting from 2.6.20 (and 109 days uptime with a spotless clock) into 2.6.22; time lost is about four minutes each hour. Turns out that 2.6.22 marks my TSC as unstable and starts using PIT instead. Rebooting 2.6.22 with clocksource=tsc gets the original stable system time back. Not sure whether this is supposed to be the default way of fixing the issue on older machines, though; if anyone sees a problem with this, I'm up for providing more information. [EMAIL PROTECTED] ~]# cd /sys/devices/system/clocksource/clocksource0/ [EMAIL PROTECTED] clocksource0]# cat available_clocksource pit jiffies tsc [EMAIL PROTECTED] clocksource0]# cat current_clocksource tsc [EMAIL PROTECTED] clocksource0]# uname -a Linux donkey 2.6.22 #1 PREEMPT Mon Jul 9 13:26:38 CEST 2007 i686 athlon i386 GNU/Linux [EMAIL PROTECTED] clocksource0]# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 4 model name : AMD Athlon(tm) Processor stepping: 2 cpu MHz : 800.068 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips: 1603.17 clflush size: 32 thanks, ciao, --alessandro Did you get married but forgot to get divorced ? (Danny and Dusty, 'The Good Old Days') - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.22-rc1
On 5/13/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: Ok, the merge window has closed, and 2.6.22-rc1 is out there. [snip] I took a more careful look than with recent -gitXX, and for reporting's sake here's a few MODPOST warnings: MODPOST vmlinux WARNING: init/built-in.o - Section mismatch: reference to .init.text: from .text between 'rest_init' (at offset 0xfd) and 'try_name' WARNING: mm/built-in.o - Section mismatch: reference to .init.text: from .text between 'kmem_cache_create' (at offset 0x196e4) and 'cache_reap' WARNING: mm/built-in.o - Section mismatch: reference to .init.text: from .text between 'kmem_cache_create' (at offset 0x19716) and 'cache_reap Grepping in my recent kernel build logs, the rest_init one seems to be present since -git7 but wasn't in -git6. Googling around seems that this has already been looked into in the 2.6.20-rc series, with patches that may or may not have made it into mainline. I still have old .config files, so if there's anything useful I can do to provide more info, just holler. ciao, --alessandro "Did you get married but forgot to get divorced ?" (Danny and Dusty, 'The Good Old Days') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: upgrade linux kernel
On 5/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I am upgrading kernel from 2.4.20-8(default in RH9) to 2.6.xx. when I do "make" command it gives some output and finally get error saying that, "BFD: Warning: Writing section '.bss' to huge ( ie negative) file offset 0xc0244000. " "Objcopy: arch/i386/boot/compressed/vmlinux.bin: file truncated" "make[2]:***[ arch/i386/boot/compressed/vmlinux.bin] Error 1" "make[1]: ***[ arch/i386/boot/compressed/vmlinux] Error 2" "make: *** [bzImage] Error 2" A quick round of googling brings up this http://www.uwsg.iu.edu/hypermail/linux/kernel/0410.3/0205.html where the issue was that binutils were too old to compile the newer kernels. More generically, RH9 is now really ancient, and you'd probably make your life much easier by upgrading to more recent distributions. If you intend to stay on RH9, please have a look at the /usr/src/linux/Documentation/Changes file, it will give you a first idea of how much stuff you need to upgrade on RH9. --alessandro "Did you get married but forgot to get divorced ?" (Danny and Dusty, 'The Good Old Days') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: upgrade linux kernel
On 5/13/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I am upgrading kernel from 2.4.20-8(default in RH9) to 2.6.xx. when I do make command it gives some output and finally get error saying that, BFD: Warning: Writing section '.bss' to huge ( ie negative) file offset 0xc0244000. Objcopy: arch/i386/boot/compressed/vmlinux.bin: file truncated make[2]:***[ arch/i386/boot/compressed/vmlinux.bin] Error 1 make[1]: ***[ arch/i386/boot/compressed/vmlinux] Error 2 make: *** [bzImage] Error 2 A quick round of googling brings up this http://www.uwsg.iu.edu/hypermail/linux/kernel/0410.3/0205.html where the issue was that binutils were too old to compile the newer kernels. More generically, RH9 is now really ancient, and you'd probably make your life much easier by upgrading to more recent distributions. If you intend to stay on RH9, please have a look at the /usr/src/linux/Documentation/Changes file, it will give you a first idea of how much stuff you need to upgrade on RH9. --alessandro Did you get married but forgot to get divorced ? (Danny and Dusty, 'The Good Old Days') - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.22-rc1
On 5/13/07, Linus Torvalds [EMAIL PROTECTED] wrote: Ok, the merge window has closed, and 2.6.22-rc1 is out there. [snip] I took a more careful look than with recent -gitXX, and for reporting's sake here's a few MODPOST warnings: MODPOST vmlinux WARNING: init/built-in.o - Section mismatch: reference to .init.text: from .text between 'rest_init' (at offset 0xfd) and 'try_name' WARNING: mm/built-in.o - Section mismatch: reference to .init.text: from .text between 'kmem_cache_create' (at offset 0x196e4) and 'cache_reap' WARNING: mm/built-in.o - Section mismatch: reference to .init.text: from .text between 'kmem_cache_create' (at offset 0x19716) and 'cache_reap Grepping in my recent kernel build logs, the rest_init one seems to be present since -git7 but wasn't in -git6. Googling around seems that this has already been looked into in the 2.6.20-rc series, with patches that may or may not have made it into mainline. I still have old .config files, so if there's anything useful I can do to provide more info, just holler. ciao, --alessandro Did you get married but forgot to get divorced ? (Danny and Dusty, 'The Good Old Days') - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.21-git2] sk_buff changes break Cisco VPN client
On 4/29/07, David Miller <[EMAIL PROTECTED]> wrote: From: Roland Dreier <[EMAIL PROTECTED]> Date: Sat, 28 Apr 2007 14:05:27 -0700 > However I can suggest vpnc (http://www.unix-ag.uni-kl.de/~massar/vpnc/) > as an alternative. I'm not forced to use Cisco VPN access any more, > but when I tried it, vpnc was tons better than the Cisco product. Also, and I know this might be a COMPLETE SHOCK to some people, but we do have a full in-kernel IPSEC stack and using it with openswan to connect to VPNs works perfectly fine. I use it every day. It's quite amusing that people use a userland IPSEC implementation via VPNC, in spite of this. Have a look here https://lists.dulug.duke.edu/pipermail/dulug/2007-March/010792.html where someone seems to be in my same boat. No, openswan/IPSEC does not work in all configurations with Cisco VPN concentrators - and by Murphy's law, I'm in the non-working configuration. Hope this clarifies the reason I asked. And if anyone out there is in doubt about it, I absolutely hate having to rebuild an out of kernel module every time I build a kernel, crossing fingers it doesn't break (again). I would use *anything* else. --alessandro "Did you get married but forgot to get divorced ?" (Danny and Dusty, 'The Good Old Days') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.21-git2] sk_buff changes break Cisco VPN client
On 4/29/07, David Miller [EMAIL PROTECTED] wrote: From: Roland Dreier [EMAIL PROTECTED] Date: Sat, 28 Apr 2007 14:05:27 -0700 However I can suggest vpnc (http://www.unix-ag.uni-kl.de/~massar/vpnc/) as an alternative. I'm not forced to use Cisco VPN access any more, but when I tried it, vpnc was tons better than the Cisco product. Also, and I know this might be a COMPLETE SHOCK to some people, but we do have a full in-kernel IPSEC stack and using it with openswan to connect to VPNs works perfectly fine. I use it every day. It's quite amusing that people use a userland IPSEC implementation via VPNC, in spite of this. Have a look here https://lists.dulug.duke.edu/pipermail/dulug/2007-March/010792.html where someone seems to be in my same boat. No, openswan/IPSEC does not work in all configurations with Cisco VPN concentrators - and by Murphy's law, I'm in the non-working configuration. Hope this clarifies the reason I asked. And if anyone out there is in doubt about it, I absolutely hate having to rebuild an out of kernel module every time I build a kernel, crossing fingers it doesn't break (again). I would use *anything* else. --alessandro Did you get married but forgot to get divorced ? (Danny and Dusty, 'The Good Old Days') - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.21-git2] sk_buff changes break Cisco VPN client
On 4/28/07, Roland Dreier <[EMAIL PROTECTED]> wrote: This is really a problem for Cisco support, not the kernel people. (And despite my email address I really have no idea who looks after the VPN client). It's ok, I know it's "not a kernel issue". I just asked over here because I saw network code already converted to the new sk_buff code, and hoped someone could hint to a solution; I don't think it'd be extremely fruitful to ask Cisco since I'm already running a patched version of their latest official Linux release, which hasn't been updated for quite a while. However I can suggest vpnc (http://www.unix-ag.uni-kl.de/~massar/vpnc/) as an alternative. I'm not forced to use Cisco VPN access any more, but when I tried it, vpnc was tons better than the Cisco product. vpnc only started supporting hybrid-auth as of very, very recently; I used it before my company network turned to hybrid-auth-only several months ago. It's in my sights to go back to test vpnc-0.4.0 with the hybrid-auth support patch in the near future. But in the meantime I'll be stuck with the Cisco VPN client. After clarifying all this, I'll respectfully ask again whether anyone has an idea about how to go fixing the five or so lines of the skb stuff impacted by the kernel changes - and will of course take no offense if nobody can help, while happily ignoring those who can only contribute what I do already know, that is - this isn't a kernel issue. Thanks again in advance, ciao, --alessandro "Did you get married but forgot to get divorced ?" (Danny and Dusty, 'The Good Old Days') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.21-git2] sk_buff changes break Cisco VPN client
skb_set_timestamp I can figure out, but the rest is a bit too hard for me... if anyone has already an idea of how to fix this, I'd be most grateful. Cisco VPN client builds and works fine under 2.6.21 vanilla. thanks in advance for any input ! ciao, [EMAIL PROTECTED] ~]# ciscobuild make -C /share/src/linux-2.6.21-git2 SUBDIRS=/download/linux/net/vpnclient modules make[1]: Entering directory `/share/src/linux-2.6.21-git2' CC [M] /download/linux/net/vpnclient/linuxcniapi.o /download/linux/net/vpnclient/linuxcniapi.c: In function 'CniInjectReceive': /download/linux/net/vpnclient/linuxcniapi.c:299: warning: implicit declaration of function 'skb_set_timestamp' /download/linux/net/vpnclient/linuxcniapi.c:333: error: 'struct sk_buff' has no member named 'nh' /download/linux/net/vpnclient/linuxcniapi.c:334: error: 'struct sk_buff' has no member named 'mac' /download/linux/net/vpnclient/linuxcniapi.c: In function 'CniInjectSend': /download/linux/net/vpnclient/linuxcniapi.c:456: error: 'struct sk_buff' has no member named 'mac' /download/linux/net/vpnclient/linuxcniapi.c:457: error: 'struct sk_buff' has no member named 'nh' /download/linux/net/vpnclient/linuxcniapi.c:460: error: 'struct sk_buff' has no member named 'h' /download/linux/net/vpnclient/linuxcniapi.c:460: error: 'struct sk_buff' has no member named 'nh' make[2]: *** [/download/linux/net/vpnclient/linuxcniapi.o] Error 1 make[1]: *** [_module_/download/linux/net/vpnclient] Error 2 make[1]: Leaving directory `/share/src/linux-2.6.21-git2' make: *** [default] Error 2 --alessandro "Did you get married but forgot to get divorced ?" (Danny and Dusty, 'The Good Old Days') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.21-git2] sk_buff changes break Cisco VPN client
skb_set_timestamp I can figure out, but the rest is a bit too hard for me... if anyone has already an idea of how to fix this, I'd be most grateful. Cisco VPN client builds and works fine under 2.6.21 vanilla. thanks in advance for any input ! ciao, [EMAIL PROTECTED] ~]# ciscobuild make -C /share/src/linux-2.6.21-git2 SUBDIRS=/download/linux/net/vpnclient modules make[1]: Entering directory `/share/src/linux-2.6.21-git2' CC [M] /download/linux/net/vpnclient/linuxcniapi.o /download/linux/net/vpnclient/linuxcniapi.c: In function 'CniInjectReceive': /download/linux/net/vpnclient/linuxcniapi.c:299: warning: implicit declaration of function 'skb_set_timestamp' /download/linux/net/vpnclient/linuxcniapi.c:333: error: 'struct sk_buff' has no member named 'nh' /download/linux/net/vpnclient/linuxcniapi.c:334: error: 'struct sk_buff' has no member named 'mac' /download/linux/net/vpnclient/linuxcniapi.c: In function 'CniInjectSend': /download/linux/net/vpnclient/linuxcniapi.c:456: error: 'struct sk_buff' has no member named 'mac' /download/linux/net/vpnclient/linuxcniapi.c:457: error: 'struct sk_buff' has no member named 'nh' /download/linux/net/vpnclient/linuxcniapi.c:460: error: 'struct sk_buff' has no member named 'h' /download/linux/net/vpnclient/linuxcniapi.c:460: error: 'struct sk_buff' has no member named 'nh' make[2]: *** [/download/linux/net/vpnclient/linuxcniapi.o] Error 1 make[1]: *** [_module_/download/linux/net/vpnclient] Error 2 make[1]: Leaving directory `/share/src/linux-2.6.21-git2' make: *** [default] Error 2 --alessandro Did you get married but forgot to get divorced ? (Danny and Dusty, 'The Good Old Days') - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.21-git2] sk_buff changes break Cisco VPN client
On 4/28/07, Roland Dreier [EMAIL PROTECTED] wrote: This is really a problem for Cisco support, not the kernel people. (And despite my email address I really have no idea who looks after the VPN client). It's ok, I know it's not a kernel issue. I just asked over here because I saw network code already converted to the new sk_buff code, and hoped someone could hint to a solution; I don't think it'd be extremely fruitful to ask Cisco since I'm already running a patched version of their latest official Linux release, which hasn't been updated for quite a while. However I can suggest vpnc (http://www.unix-ag.uni-kl.de/~massar/vpnc/) as an alternative. I'm not forced to use Cisco VPN access any more, but when I tried it, vpnc was tons better than the Cisco product. vpnc only started supporting hybrid-auth as of very, very recently; I used it before my company network turned to hybrid-auth-only several months ago. It's in my sights to go back to test vpnc-0.4.0 with the hybrid-auth support patch in the near future. But in the meantime I'll be stuck with the Cisco VPN client. After clarifying all this, I'll respectfully ask again whether anyone has an idea about how to go fixing the five or so lines of the skb stuff impacted by the kernel changes - and will of course take no offense if nobody can help, while happily ignoring those who can only contribute what I do already know, that is - this isn't a kernel issue. Thanks again in advance, ciao, --alessandro Did you get married but forgot to get divorced ? (Danny and Dusty, 'The Good Old Days') - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in current -git tree causing dbus and gnome to chew up cpu time
On 2/14/07, Andreas Gruenbacher <[EMAIL PROTECTED]> wrote: Hi, I've described the problem and possible fixes in the "Re: [PATCH] Fix d_path for lazy unmounts" thread, Message-Id: [EMAIL PROTECTED] Yes, I saw that. But there isn't any patch for me to test, and my userspace remains broken. Please don't get me wrong - I'm not bitching about this, but I will effectively not be able to test newer snapshots until either a fix for this new bug gets in, or the commit that introduced the bug gets reverted. Thanks, --alessandro "but I thought that I should let you know the things that I don't always show might not be worth the time it took" (Steve Wynn, 'If My Life Was An Open Book') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in current -git tree causing dbus and gnome to chew up cpu time
On 2/13/07, Greg KH <[EMAIL PROTECTED]> wrote: Hi, I've used 'git bisect' to track down a change in the latest git tree that is causing dbus-daemon to sit and spin at the time GNOME launches, preventing nautlius from ever running. The bad commit is: commit eb3dfb0cb1f4a44e2d0553f89514ce9f2a9fcaf1 Author: Andreas Gruenbacher <[EMAIL PROTECTED]> Date: Mon Feb 12 00:51:47 2007 -0800 [PATCH] Fix d_path for lazy unmounts With that patch out, GNOME startup works just fine. I have a strace of the dbus process running showing the problem, if anyone thinks that will help out any. I'm running pretty new GNOME and dbus here: dbus 1.0.2 gnome 2.16.2 hal 0.5.7.1 nautilus 2.16.3 Any ideas of things I can test? Just to add a data point, I see the same problem (startx never completes, gnome-vfs-daemon keeps getting forked by dbus to no end) on 2.6.20-git9 while -git7 is fine, and my pieces are from FC6 updates as of two days ago or so: [EMAIL PROTECTED] ~]$ rpm -q dbus gnome-vfs2 hal nautilus dbus-1.0.1-9.fc6 gnome-vfs2-2.16.2-2.fc6 hal-0.5.8.1-6.fc6 nautilus-2.16.2-7.fc6 Since the patch breaks userspace in a deadly way, I guess it should be reverted until an usable version of the fix can be found. And yes, I'm up for testing of course. --alessandro "but I thought that I should let you know the things that I don't always show might not be worth the time it took" (Steve Wynn, 'If My Life Was An Open Book') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in current -git tree causing dbus and gnome to chew up cpu time
On 2/13/07, Greg KH [EMAIL PROTECTED] wrote: Hi, I've used 'git bisect' to track down a change in the latest git tree that is causing dbus-daemon to sit and spin at the time GNOME launches, preventing nautlius from ever running. The bad commit is: commit eb3dfb0cb1f4a44e2d0553f89514ce9f2a9fcaf1 Author: Andreas Gruenbacher [EMAIL PROTECTED] Date: Mon Feb 12 00:51:47 2007 -0800 [PATCH] Fix d_path for lazy unmounts With that patch out, GNOME startup works just fine. I have a strace of the dbus process running showing the problem, if anyone thinks that will help out any. I'm running pretty new GNOME and dbus here: dbus 1.0.2 gnome 2.16.2 hal 0.5.7.1 nautilus 2.16.3 Any ideas of things I can test? Just to add a data point, I see the same problem (startx never completes, gnome-vfs-daemon keeps getting forked by dbus to no end) on 2.6.20-git9 while -git7 is fine, and my pieces are from FC6 updates as of two days ago or so: [EMAIL PROTECTED] ~]$ rpm -q dbus gnome-vfs2 hal nautilus dbus-1.0.1-9.fc6 gnome-vfs2-2.16.2-2.fc6 hal-0.5.8.1-6.fc6 nautilus-2.16.2-7.fc6 Since the patch breaks userspace in a deadly way, I guess it should be reverted until an usable version of the fix can be found. And yes, I'm up for testing of course. --alessandro but I thought that I should let you know the things that I don't always show might not be worth the time it took (Steve Wynn, 'If My Life Was An Open Book') - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in current -git tree causing dbus and gnome to chew up cpu time
On 2/14/07, Andreas Gruenbacher [EMAIL PROTECTED] wrote: Hi, I've described the problem and possible fixes in the Re: [PATCH] Fix d_path for lazy unmounts thread, Message-Id: [EMAIL PROTECTED] Yes, I saw that. But there isn't any patch for me to test, and my userspace remains broken. Please don't get me wrong - I'm not bitching about this, but I will effectively not be able to test newer snapshots until either a fix for this new bug gets in, or the commit that introduced the bug gets reverted. Thanks, --alessandro but I thought that I should let you know the things that I don't always show might not be worth the time it took (Steve Wynn, 'If My Life Was An Open Book') - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Super Kernel Sunday!
On 2/4/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: In a widely anticipated move, Linux "headcase" Torvalds today announced the immediate availability of the most advanced Linux kernel to date, version 2.6.20. Before downloading the actual new kernel, most avid kernel hackers have been involved in a 2-hour pre-kernel-compilation count-down, with some even spending the preceding week doing typing exercises and reciting PI to a thousand decimal places. The half-time entertainment is provided by randomly inserted trivial syntax errors that nerds are expected to fix at home before completing the compile, but most people actually seem to mostly enjoy watching the compile warnings, sponsored by Anheuser-Busch, scroll past. As ICD head analyst Walter Dickweed put it: "Releasing a new kernel on Superbowl Sunday means that the important 'pasty white nerd' constituency finally has something to do while the rest of the country sits comatose in front of their 65" plasma screens". Walter was immediately attacked for his racist and insensitive remarks by Geeks without Borders representative Marilyn vos Savant, who pointed out that not all of their members are either pasty nor white. "Some of them even shower!" she added, claiming that the constant stereotyping hurts nerds' standing in society. Geeks outside the US were just confused about the whole issue, and were heard wondering what the big hoopla was all about. Some of the more culturally aware of them were heard snickering about balls that weren't even round. Ha. And you wouldn't have thought there was someone who - was born and raised and lives in old europe - builds and tests 100+ kernels a year - has already built 2.6.20 [EMAIL PROTECTED] ~]$ cat /proc/version Linux version 2.6.20 ([EMAIL PROTECTED]) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 Sun Feb 4 20:41:13 CET 2007 ...because... there's the SUPERBOWL to watch in front of a 32" LCD screen !! (yes, I took tomorrow off work of course ;) --alessandro "but I thought that I should let you know the things that I don't always show might not be worth the time it took" (Steve Wynn, 'If My Life Was An Open Book') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Super Kernel Sunday!
On 2/4/07, Linus Torvalds [EMAIL PROTECTED] wrote: In a widely anticipated move, Linux headcase Torvalds today announced the immediate availability of the most advanced Linux kernel to date, version 2.6.20. Before downloading the actual new kernel, most avid kernel hackers have been involved in a 2-hour pre-kernel-compilation count-down, with some even spending the preceding week doing typing exercises and reciting PI to a thousand decimal places. The half-time entertainment is provided by randomly inserted trivial syntax errors that nerds are expected to fix at home before completing the compile, but most people actually seem to mostly enjoy watching the compile warnings, sponsored by Anheuser-Busch, scroll past. As ICD head analyst Walter Dickweed put it: Releasing a new kernel on Superbowl Sunday means that the important 'pasty white nerd' constituency finally has something to do while the rest of the country sits comatose in front of their 65 plasma screens. Walter was immediately attacked for his racist and insensitive remarks by Geeks without Borders representative Marilyn vos Savant, who pointed out that not all of their members are either pasty nor white. Some of them even shower! she added, claiming that the constant stereotyping hurts nerds' standing in society. Geeks outside the US were just confused about the whole issue, and were heard wondering what the big hoopla was all about. Some of the more culturally aware of them were heard snickering about balls that weren't even round. Ha. And you wouldn't have thought there was someone who - was born and raised and lives in old europe - builds and tests 100+ kernels a year - has already built 2.6.20 [EMAIL PROTECTED] ~]$ cat /proc/version Linux version 2.6.20 ([EMAIL PROTECTED]) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 Sun Feb 4 20:41:13 CET 2007 ...because... there's the SUPERBOWL to watch in front of a 32 LCD screen !! (yes, I took tomorrow off work of course ;) --alessandro but I thought that I should let you know the things that I don't always show might not be worth the time it took (Steve Wynn, 'If My Life Was An Open Book') - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: qconf: reproducible segfault
On 1/5/07, Cyrill V. Gorcunov <[EMAIL PROTECTED]> wrote: On Friday 05 January 2007 00:16, you wrote: | On 1/4/07, Cyrill V. Gorcunov <[EMAIL PROTECTED]> wrote: | > Hi, | > there is SIGSEGV happens in qconf.cc:995 | > | > str += print_filter(sym->name); | > | > but sym points to 0x1. To reproduce the error just do: | > | > 1) make xconfig (with Options->Show Debug Info unchecked) | > 2) go to Networking->Networking Options->Network packet filtering framework (Netfilter)-> | >Network packet filtering framework (Netfilter) and the line "<| .." must be selected | >then just turn on Options->Show Debug info menu and you'll get: | > | > make[1]: *** [xconfig] Segmentation fault | > make: *** [xconfig] Error 2 | | Cyrill, Randy - I feel like an idiot but I can't really reproduce this :( | | I'm trimming lkml from the CC list to upload and attach two screenshots | where I enabled Show Debug Info at what I guess are the two possible | interpretations of where the Select highlight should be - and neither | cause a core dump for me. | | What am I mistaking ? | | Thanks, ciao, Hi Alessandro, see enveloped scrshot to keep in mind how the qconf is looking at moment we get SYGSEGV error - you just need to set Options->Show Debug and oops ;) I don't know may be QT dev version does handling such exceptions itself and if SYGSEVG happens it just ignore it... But the qconf really have the error :(. That's ok, apparently FC6's qt-devel-3.3.7 libs are capable of handling the problem (I can bring qconf to the exact screen you showed, Options->Show Debug Info does _not_ crash). And of course it's better to fix the problem in qconf.cc rather than letting qt libs handle it :) Thanks, --alessandro "but I thought that I should let you know the things that I don't always show might not be worth the time it took" (Steve Wynn, 'If My Life Was An Open Book') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: qconf: reproducible segfault
On 1/5/07, Cyrill V. Gorcunov [EMAIL PROTECTED] wrote: On Friday 05 January 2007 00:16, you wrote: | On 1/4/07, Cyrill V. Gorcunov [EMAIL PROTECTED] wrote: | Hi, | there is SIGSEGV happens in qconf.cc:995 | | str += print_filter(sym-name); | | but sym points to 0x1. To reproduce the error just do: | | 1) make xconfig (with Options-Show Debug Info unchecked) | 2) go to Networking-Networking Options-Network packet filtering framework (Netfilter)- | Network packet filtering framework (Netfilter) and the line | .. must be selected | then just turn on Options-Show Debug info menu and you'll get: | | make[1]: *** [xconfig] Segmentation fault | make: *** [xconfig] Error 2 | | Cyrill, Randy - I feel like an idiot but I can't really reproduce this :( | | I'm trimming lkml from the CC list to upload and attach two screenshots | where I enabled Show Debug Info at what I guess are the two possible | interpretations of where the Select highlight should be - and neither | cause a core dump for me. | | What am I mistaking ? | | Thanks, ciao, Hi Alessandro, see enveloped scrshot to keep in mind how the qconf is looking at moment we get SYGSEGV error - you just need to set Options-Show Debug and oops ;) I don't know may be QT dev version does handling such exceptions itself and if SYGSEVG happens it just ignore it... But the qconf really have the error :(. That's ok, apparently FC6's qt-devel-3.3.7 libs are capable of handling the problem (I can bring qconf to the exact screen you showed, Options-Show Debug Info does _not_ crash). And of course it's better to fix the problem in qconf.cc rather than letting qt libs handle it :) Thanks, --alessandro but I thought that I should let you know the things that I don't always show might not be worth the time it took (Steve Wynn, 'If My Life Was An Open Book') - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: qconf: reproducible segfault
On 1/3/07, Bauke Jan Douma <[EMAIL PROTECTED]> wrote:
Not a big deal (I just discovered 'make gconfig'), but I'm experiencing
a reproducible segfault in 'make xconfig', i.e. qconf.
I was wondering if anyone else can reproduce this:
1. QTDIR=/usr/local/lib/qt make xconfig
mine by default has all qconf options OFF ('Show Name', 'Show Range',
'Show Data', 'Show All Options', 'Show Debug Info')
2. from the kernel options, select:
Networking / Networking options / Network packet filtering (replaces
ipchains)
3. from the qconf options, now select 'Show Debug Info'
voila -> segfault
This is with qt-3.3.3:
I can't reproduce it with FC6's current qt-devel in 2.6.20-rc3-git3...
but point 2 is in my tree
Networking / Networking options / Network packet filtering framework (Netfilter)
hmm, curious - let me download 2.6.19.1 and apply it... ok, now I see
your point 2, but I still can't reproduce the problem (Show Debug Info
does indeed show, well, debug information).
[EMAIL PROTECTED] ~]# rpm -q qt-devel
qt-devel-3.3.7-0.1.fc6
ldd /usr/src/linux-2.6.19.1/scripts/kconfig/qconf
linux-gate.so.1 => (0xe000)
libqt-mt.so.3 => /usr/local/lib/qt/lib/libqt-mt.so.3 (0xb76c2000)
libdl.so.2 => /lib/libdl.so.2 (0xb76ad000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb75c9000)
libm.so.6 => /lib/libm.so.6 (0xb75a4000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb7598000)
libc.so.6 => /lib/libc.so.6 (0xb746f000)
libpng.so.3 => /usr/local/lib/libpng.so.3 (0xb7449000)
libz.so.1 => /lib/libz.so.1 (0xb7435000)
libGL.so.1 => /usr/lib/libGL.so.1 (0xb73a9000)
libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0xb7393000)
libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0xb738b000)
libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0xb7387000)
libXcursor.so.1 => /usr/X11R6/lib/libXcursor.so.1 (0xb737e000)
libXinerama.so.1 => /usr/X11R6/lib/libXinerama.so.1 (0xb737b000)
libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0xb7369000)
libfreetype.so.6 => /usr/local/lib/libfreetype.so.6 (0xb72e4000)
libfontconfig.so.1 => /usr/local/lib/libfontconfig.so.1 (0xb72a6000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb7298000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb71cb000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0xb71c2000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0xb71aa000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7192000)
/lib/ld-linux.so.2 (0xb7f1b000)
libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0xb690c000)
libnvidia-tls.so.1 => /usr/lib/tls/libnvidia-tls.so.1 (0xb690a000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0xb68b8000)
libexpat.so.0 => /usr/local/lib/libexpat.so.0 (0xb688c000)
libiconv.so.2 => /lib/libiconv.so.2 (0xb67b1000)
First I thought qconf window geometry and maybe font would make a
telling difference here, but I can resize the window all I want and
change fonts any which way I can, but the segfault persists.
I guess you'll have to try a more recent qt-devel version :)
FWIW, my initial geometry is 957x843, font is usually LuciduxSans 7.
Strace output didn't provide much of an apparent clue, just the
SIGSEGV.
Oh, kernel is 2.6.19.1 -- not important I'd say.
Thanks for your time.
Ciao,
--alessandro
"but I thought that I should let you know
the things that I don't always show
might not be worth the time it took"
(Steve Wynn, 'If My Life Was An Open Book')
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: qconf: reproducible segfault
On 1/3/07, Bauke Jan Douma [EMAIL PROTECTED] wrote:
Not a big deal (I just discovered 'make gconfig'), but I'm experiencing
a reproducible segfault in 'make xconfig', i.e. qconf.
I was wondering if anyone else can reproduce this:
1. QTDIR=/usr/local/lib/qt make xconfig
mine by default has all qconf options OFF ('Show Name', 'Show Range',
'Show Data', 'Show All Options', 'Show Debug Info')
2. from the kernel options, select:
Networking / Networking options / Network packet filtering (replaces
ipchains)
3. from the qconf options, now select 'Show Debug Info'
voila - segfault
This is with qt-3.3.3:
I can't reproduce it with FC6's current qt-devel in 2.6.20-rc3-git3...
but point 2 is in my tree
Networking / Networking options / Network packet filtering framework (Netfilter)
hmm, curious - let me download 2.6.19.1 and apply it... ok, now I see
your point 2, but I still can't reproduce the problem (Show Debug Info
does indeed show, well, debug information).
[EMAIL PROTECTED] ~]# rpm -q qt-devel
qt-devel-3.3.7-0.1.fc6
ldd /usr/src/linux-2.6.19.1/scripts/kconfig/qconf
linux-gate.so.1 = (0xe000)
libqt-mt.so.3 = /usr/local/lib/qt/lib/libqt-mt.so.3 (0xb76c2000)
libdl.so.2 = /lib/libdl.so.2 (0xb76ad000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0xb75c9000)
libm.so.6 = /lib/libm.so.6 (0xb75a4000)
libgcc_s.so.1 = /usr/lib/libgcc_s.so.1 (0xb7598000)
libc.so.6 = /lib/libc.so.6 (0xb746f000)
libpng.so.3 = /usr/local/lib/libpng.so.3 (0xb7449000)
libz.so.1 = /lib/libz.so.1 (0xb7435000)
libGL.so.1 = /usr/lib/libGL.so.1 (0xb73a9000)
libXmu.so.6 = /usr/X11R6/lib/libXmu.so.6 (0xb7393000)
libXrender.so.1 = /usr/X11R6/lib/libXrender.so.1 (0xb738b000)
libXrandr.so.2 = /usr/X11R6/lib/libXrandr.so.2 (0xb7387000)
libXcursor.so.1 = /usr/X11R6/lib/libXcursor.so.1 (0xb737e000)
libXinerama.so.1 = /usr/X11R6/lib/libXinerama.so.1 (0xb737b000)
libXft.so.2 = /usr/X11R6/lib/libXft.so.2 (0xb7369000)
libfreetype.so.6 = /usr/local/lib/libfreetype.so.6 (0xb72e4000)
libfontconfig.so.1 = /usr/local/lib/libfontconfig.so.1 (0xb72a6000)
libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0xb7298000)
libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0xb71cb000)
libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0xb71c2000)
libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0xb71aa000)
libpthread.so.0 = /lib/libpthread.so.0 (0xb7192000)
/lib/ld-linux.so.2 (0xb7f1b000)
libGLcore.so.1 = /usr/lib/libGLcore.so.1 (0xb690c000)
libnvidia-tls.so.1 = /usr/lib/tls/libnvidia-tls.so.1 (0xb690a000)
libXt.so.6 = /usr/X11R6/lib/libXt.so.6 (0xb68b8000)
libexpat.so.0 = /usr/local/lib/libexpat.so.0 (0xb688c000)
libiconv.so.2 = /lib/libiconv.so.2 (0xb67b1000)
First I thought qconf window geometry and maybe font would make a
telling difference here, but I can resize the window all I want and
change fonts any which way I can, but the segfault persists.
I guess you'll have to try a more recent qt-devel version :)
FWIW, my initial geometry is 957x843, font is usually LuciduxSans 7.
Strace output didn't provide much of an apparent clue, just the
SIGSEGV.
Oh, kernel is 2.6.19.1 -- not important I'd say.
Thanks for your time.
Ciao,
--alessandro
but I thought that I should let you know
the things that I don't always show
might not be worth the time it took
(Steve Wynn, 'If My Life Was An Open Book')
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))
On 1/2/07, Alan <[EMAIL PROTECTED]> wrote:
This is a slight variant on the patch I posted December 16th to fix
libata combined mode handling. The only real change is that we now
correctly also reserve BAR1,2,4. That is basically a neatness issue.
Jeff was unhappy about two things
1. That it didn't work in the case of one channel native one channel
legacy.
This is a silly complaint because the SFF layer in libata doesn't handle
this case yet anyway.
2. The case where combined mode is in use and IDE=n.
In this case the libata quirk code reserves the resources in question
correctly already.
Once the combined mode stuff is redone properly (2.6.21) then the entire
mess turns into a single pci_request_regions() for all cases and all the
ugly resource hackery goes away.
I'm sending this now rather than after running full test suites so that
it can get the maximal testing in a short time. I'll be running tests on
this after lunch.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
--- linux.vanilla-2.6.20-rc3/drivers/ata/libata-sff.c 2007-01-01
21:43:27.0 +
+++ linux-2.6.20-rc3/drivers/ata/libata-sff.c 2007-01-02 11:15:53.0
+
@@ -1027,13 +1027,15 @@
#endif
}
- rc = pci_request_regions(pdev, DRV_NAME);
- if (rc) {
- disable_dev_on_err = 0;
- goto err_out;
- }
-
- if (legacy_mode) {
+ if (!legacy_mode) {
+ rc = pci_request_regions(pdev, DRV_NAME);
+ if (rc) {
+ disable_dev_on_err = 0;
+ goto err_out;
+ }
+ } else {
+ /* Deal with combined mode hack. This side of the logic all
+ goes away once the combined mode hack is killed in 2.6.21 */
if (!request_region(ATA_PRIMARY_CMD, 8, "libata")) {
struct resource *conflict, res;
res.start = ATA_PRIMARY_CMD;
@@ -1071,6 +1073,13 @@
}
} else
legacy_mode |= ATA_PORT_SECONDARY;
+
+ if (legacy_mode & ATA_PORT_PRIMARY)
+ pci_request_region(pdev, 1, DRV_NAME);
+ if (legacy_mode & ATA_PORT_SECONDARY)
+ pci_request_region(pdev, 3, DRV_NAME);
+ /* If there is a DMA resource, allocate it */
+ pci_request_region(pdev, 4, DRV_NAME);
}
/* we have legacy mode, but all ports are unavailable */
@@ -1114,11 +1123,20 @@
err_out_ent:
kfree(probe_ent);
err_out_regions:
- if (legacy_mode & ATA_PORT_PRIMARY)
- release_region(ATA_PRIMARY_CMD, 8);
- if (legacy_mode & ATA_PORT_SECONDARY)
- release_region(ATA_SECONDARY_CMD, 8);
- pci_release_regions(pdev);
+ /* All this conditional stuff is needed for the combined mode hack
+ until 2.6.21 when it can go */
+ if (legacy_mode) {
+ pci_release_region(pdev, 4);
+ if (legacy_mode & ATA_PORT_PRIMARY) {
+ release_region(ATA_PRIMARY_CMD, 8);
+ pci_release_region(pdev, 1);
+ }
+ if (legacy_mode & ATA_PORT_SECONDARY) {
+ release_region(ATA_SECONDARY_CMD, 8);
+ pci_release_region(pdev, 3);
+ }
+ } else
+ pci_release_regions(pdev);
err_out:
if (disable_dev_on_err)
pci_disable_device(pdev);
Appears to work just fine here (compiles, boots and I'm
typing this email :). The build warnings below seem new
to me - but I guess they're harmless...
CC drivers/ata/libata-sff.o
drivers/ata/libata-sff.c: In function 'ata_pci_init_one':
drivers/ata/libata-sff.c:1078: warning: ignoring return value of
'pci_request_region', declared with attribute warn_unused_result
drivers/ata/libata-sff.c:1080: warning: ignoring return value of
'pci_request_region', declared with attribute warn_unused_result
drivers/ata/libata-sff.c:1082: warning: ignoring return value of
'pci_request_region', declared with attribute warn_unused_result
Thanks, ciao,
--alessandro
"but I thought that I should let you know
the things that I don't always show
might not be worth the time it took"
(Steve Wynn, 'If My Life Was An Open Book')
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))
On 1/2/07, Alan [EMAIL PROTECTED] wrote:
This is a slight variant on the patch I posted December 16th to fix
libata combined mode handling. The only real change is that we now
correctly also reserve BAR1,2,4. That is basically a neatness issue.
Jeff was unhappy about two things
1. That it didn't work in the case of one channel native one channel
legacy.
This is a silly complaint because the SFF layer in libata doesn't handle
this case yet anyway.
2. The case where combined mode is in use and IDE=n.
In this case the libata quirk code reserves the resources in question
correctly already.
Once the combined mode stuff is redone properly (2.6.21) then the entire
mess turns into a single pci_request_regions() for all cases and all the
ugly resource hackery goes away.
I'm sending this now rather than after running full test suites so that
it can get the maximal testing in a short time. I'll be running tests on
this after lunch.
Signed-off-by: Alan Cox [EMAIL PROTECTED]
--- linux.vanilla-2.6.20-rc3/drivers/ata/libata-sff.c 2007-01-01
21:43:27.0 +
+++ linux-2.6.20-rc3/drivers/ata/libata-sff.c 2007-01-02 11:15:53.0
+
@@ -1027,13 +1027,15 @@
#endif
}
- rc = pci_request_regions(pdev, DRV_NAME);
- if (rc) {
- disable_dev_on_err = 0;
- goto err_out;
- }
-
- if (legacy_mode) {
+ if (!legacy_mode) {
+ rc = pci_request_regions(pdev, DRV_NAME);
+ if (rc) {
+ disable_dev_on_err = 0;
+ goto err_out;
+ }
+ } else {
+ /* Deal with combined mode hack. This side of the logic all
+ goes away once the combined mode hack is killed in 2.6.21 */
if (!request_region(ATA_PRIMARY_CMD, 8, libata)) {
struct resource *conflict, res;
res.start = ATA_PRIMARY_CMD;
@@ -1071,6 +1073,13 @@
}
} else
legacy_mode |= ATA_PORT_SECONDARY;
+
+ if (legacy_mode ATA_PORT_PRIMARY)
+ pci_request_region(pdev, 1, DRV_NAME);
+ if (legacy_mode ATA_PORT_SECONDARY)
+ pci_request_region(pdev, 3, DRV_NAME);
+ /* If there is a DMA resource, allocate it */
+ pci_request_region(pdev, 4, DRV_NAME);
}
/* we have legacy mode, but all ports are unavailable */
@@ -1114,11 +1123,20 @@
err_out_ent:
kfree(probe_ent);
err_out_regions:
- if (legacy_mode ATA_PORT_PRIMARY)
- release_region(ATA_PRIMARY_CMD, 8);
- if (legacy_mode ATA_PORT_SECONDARY)
- release_region(ATA_SECONDARY_CMD, 8);
- pci_release_regions(pdev);
+ /* All this conditional stuff is needed for the combined mode hack
+ until 2.6.21 when it can go */
+ if (legacy_mode) {
+ pci_release_region(pdev, 4);
+ if (legacy_mode ATA_PORT_PRIMARY) {
+ release_region(ATA_PRIMARY_CMD, 8);
+ pci_release_region(pdev, 1);
+ }
+ if (legacy_mode ATA_PORT_SECONDARY) {
+ release_region(ATA_SECONDARY_CMD, 8);
+ pci_release_region(pdev, 3);
+ }
+ } else
+ pci_release_regions(pdev);
err_out:
if (disable_dev_on_err)
pci_disable_device(pdev);
Appears to work just fine here (compiles, boots and I'm
typing this email :). The build warnings below seem new
to me - but I guess they're harmless...
CC drivers/ata/libata-sff.o
drivers/ata/libata-sff.c: In function 'ata_pci_init_one':
drivers/ata/libata-sff.c:1078: warning: ignoring return value of
'pci_request_region', declared with attribute warn_unused_result
drivers/ata/libata-sff.c:1080: warning: ignoring return value of
'pci_request_region', declared with attribute warn_unused_result
drivers/ata/libata-sff.c:1082: warning: ignoring return value of
'pci_request_region', declared with attribute warn_unused_result
Thanks, ciao,
--alessandro
but I thought that I should let you know
the things that I don't always show
might not be worth the time it took
(Steve Wynn, 'If My Life Was An Open Book')
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Happy New Year (and v2.6.20-rc3 released)
On 1/1/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
In order to not get in trouble with MADR ("Mothers Against Drunk
Releases") I decided to cut the 2.6.20-rc3 release early rather than wait
for midnight, because it's bound to be new years _somewhere_ out there. So
here's to a happy 2007 for everybody.
The big thing at least for me personally is that nasty shared mmap
corruption fix, but there's a number of other changes in here, many of
them just documentation (and some media and network drivers). Shortlog and
diffstat appended..
The git trees have been updated, and the tar-tree and patches seem to have
finisged crawling out my poor DSL connection too.
As usual, mirroring might take a while, although the delay has not been
all that horrible lately, so it's probably going to be up-to-date by the
time the hangovers are mostly gone.
At which point the first thing on any self-respecting geek's mind should
obviously be: "is there a new kernel release for me to try?"
Right?
Right ! And this one is still broken in -rc3:
Subject: kernel panics on boot (libata-sff)
References : http://lkml.org/lkml/2006/12/3/99
http://lkml.org/lkml/2006/12/14/153
http://lkml.org/lkml/2006/12/24/33
Submitter : Alessandro Suardi <[EMAIL PROTECTED]>
Caused-By : Alan Cox <[EMAIL PROTECTED]>
commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f
Handled-By : Alan Cox <[EMAIL PROTECTED]>
Status : people are working on a fix
Happy 2007 everyone,
--alessandro
"...when I get it, I _get_ it"
(Lara Eidemiller)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Happy New Year (and v2.6.20-rc3 released)
On 1/1/07, Linus Torvalds [EMAIL PROTECTED] wrote: In order to not get in trouble with MADR (Mothers Against Drunk Releases) I decided to cut the 2.6.20-rc3 release early rather than wait for midnight, because it's bound to be new years _somewhere_ out there. So here's to a happy 2007 for everybody. The big thing at least for me personally is that nasty shared mmap corruption fix, but there's a number of other changes in here, many of them just documentation (and some media and network drivers). Shortlog and diffstat appended.. The git trees have been updated, and the tar-tree and patches seem to have finisged crawling out my poor DSL connection too. As usual, mirroring might take a while, although the delay has not been all that horrible lately, so it's probably going to be up-to-date by the time the hangovers are mostly gone. At which point the first thing on any self-respecting geek's mind should obviously be: is there a new kernel release for me to try? Right? Right ! And this one is still broken in -rc3: Subject: kernel panics on boot (libata-sff) References : http://lkml.org/lkml/2006/12/3/99 http://lkml.org/lkml/2006/12/14/153 http://lkml.org/lkml/2006/12/24/33 Submitter : Alessandro Suardi [EMAIL PROTECTED] Caused-By : Alan Cox [EMAIL PROTECTED] commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f Handled-By : Alan Cox [EMAIL PROTECTED] Status : people are working on a fix Happy 2007 everyone, --alessandro ...when I get it, I _get_ it (Lara Eidemiller) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: util-linux: orphan
On 12/27/06, Theodore Tso <[EMAIL PROTECTED]> wrote: On Tue, Dec 26, 2006 at 07:08:43PM -0800, H. Peter Anvin wrote: > >I saw that the current Fedora already dynamically links /bin/mount > >against /usr/lib/libblkid.so. This obviously does not work if > >/usr is a separate partition that needs to be mounted with /bin/mount. > >I also had problems with selinux claiming I had no right to access > >libblkid, which meant that the root fs could not be remounted r/w. > > > >I'd suggest that you make sure that mount always gets statically linked > >against libblkid to avoid these problems. > > That's a pretty silly statement. The real issue is that any library > needed by binaries in /bin or /sbin should live in /lib, not /usr/lib. From a Debian unstable system: think:~# ldd /bin/mount linux-gate.so.1 => (0xe000) libblkid.so.1 => /lib/libblkid.so.1 (0xb7f23000) libuuid.so.1 => /lib/libuuid.so.1 (0xb7f2) libc.so.6 => /lib/libc.so.6 (0xb7ddf000) libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0xb7dcd000) libselinux.so.1 => /lib/libselinux.so.1 (0xb7db8000) libsepol.so.1 => /lib/libsepol.so.1 (0xb7d77000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7d61000) /lib/ld-linux.so.2 (0xb7f3f000) libdl.so.2 => /lib/libdl.so.2 (0xb7d5d000) ... and in fact the e2fsprogs's configure program normally installs the critical libraries used by mount, fsck, e2fsck, including the blkid and uuid libraries, in /lib, not /usr/lib. If blkid is being installed in /usr/lib in Fedora, someone must have gone out of their way to override e2fsprogs' defaults, which are designed to do the right things by default. (Basically, because I generally don't trust the choices made by distributions' packaging engineers, having been burned more than once. :-) - Ted FC6-current for i386 has it right: [EMAIL PROTECTED] ~]# rpm -qf /bin/mount util-linux-2.13-0.45.3.fc6 [EMAIL PROTECTED] ~]# ldd /bin/mount linux-gate.so.1 => (0xb7f63000) libblkid.so.1 => /lib/libblkid.so.1 (0x4b607000) libuuid.so.1 => /lib/libuuid.so.1 (0x4b601000) libselinux.so.1 => /lib/libselinux.so.1 (0x49ce5000) libc.so.6 => /lib/libc.so.6 (0x00aec000) libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0x49cfe000) libdl.so.2 => /lib/libdl.so.2 (0x00c54000) libsepol.so.1 => /lib/libsepol.so.1 (0x4a603000) /lib/ld-linux.so.2 (0x0011d000) --alessandro "...when I get it, I _get_ it" (Lara Eidemiller) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: util-linux: orphan
On 12/27/06, Theodore Tso [EMAIL PROTECTED] wrote: On Tue, Dec 26, 2006 at 07:08:43PM -0800, H. Peter Anvin wrote: I saw that the current Fedora already dynamically links /bin/mount against /usr/lib/libblkid.so. This obviously does not work if /usr is a separate partition that needs to be mounted with /bin/mount. I also had problems with selinux claiming I had no right to access libblkid, which meant that the root fs could not be remounted r/w. I'd suggest that you make sure that mount always gets statically linked against libblkid to avoid these problems. That's a pretty silly statement. The real issue is that any library needed by binaries in /bin or /sbin should live in /lib, not /usr/lib. From a Debian unstable system: think:~# ldd /bin/mount linux-gate.so.1 = (0xe000) libblkid.so.1 = /lib/libblkid.so.1 (0xb7f23000) libuuid.so.1 = /lib/libuuid.so.1 (0xb7f2) libc.so.6 = /lib/libc.so.6 (0xb7ddf000) libdevmapper.so.1.02 = /lib/libdevmapper.so.1.02 (0xb7dcd000) libselinux.so.1 = /lib/libselinux.so.1 (0xb7db8000) libsepol.so.1 = /lib/libsepol.so.1 (0xb7d77000) libpthread.so.0 = /lib/libpthread.so.0 (0xb7d61000) /lib/ld-linux.so.2 (0xb7f3f000) libdl.so.2 = /lib/libdl.so.2 (0xb7d5d000) ... and in fact the e2fsprogs's configure program normally installs the critical libraries used by mount, fsck, e2fsck, including the blkid and uuid libraries, in /lib, not /usr/lib. If blkid is being installed in /usr/lib in Fedora, someone must have gone out of their way to override e2fsprogs' defaults, which are designed to do the right things by default. (Basically, because I generally don't trust the choices made by distributions' packaging engineers, having been burned more than once. :-) - Ted FC6-current for i386 has it right: [EMAIL PROTECTED] ~]# rpm -qf /bin/mount util-linux-2.13-0.45.3.fc6 [EMAIL PROTECTED] ~]# ldd /bin/mount linux-gate.so.1 = (0xb7f63000) libblkid.so.1 = /lib/libblkid.so.1 (0x4b607000) libuuid.so.1 = /lib/libuuid.so.1 (0x4b601000) libselinux.so.1 = /lib/libselinux.so.1 (0x49ce5000) libc.so.6 = /lib/libc.so.6 (0x00aec000) libdevmapper.so.1.02 = /lib/libdevmapper.so.1.02 (0x49cfe000) libdl.so.2 = /lib/libdl.so.2 (0x00c54000) libsepol.so.1 = /lib/libsepol.so.1 (0x4a603000) /lib/ld-linux.so.2 (0x0011d000) --alessandro ...when I get it, I _get_ it (Lara Eidemiller) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc2
On 12/24/06, Linus Torvalds <[EMAIL PROTECTED]> wrote: Ok, it's a couple of days delayed, because we've been trying to figure out what is up with the rtorrent hash failures since 2.6.18.3. I don't think we've made any progress, but we've cleaned up a number of suspects in the meantime. It's a bit sad, if only because I was really hoping to make 2.6.20 an easy release, and held back on merging some stuff during the merge window for that reason. And now we're battling something that was introduced much earlier.. Now, practically speaking this isn't likely to affect a lot of people, but it's still a worrisome problem, and we've had "top people" looking at it. And they'll continue, but xmas is coming. In the meantime, we'll continue with the stabilization, and this mainly does some driver updates (usb, sound, dri, pci hotplug) and ACPI updates (much of the latter syntactic cleanups). And arm and powerpc updates. Shortlog appended. For developers: if you sent me a patch, and I didn't apply it, it was probably just missed because I concentrated on other issues. So pls re-send.. Unless I explicitly told you that I'm not going to pull it due to the merge window being over, of course ;) Linus [shortlog snipped] As already reported multiple times, including at -rc1 time... still need this libata-sff.c patch: http://marc.theaimsgroup.com/?l=linux-kernel=116343564202844=raw to have my root device detected, ata_piix probe would otherwise fail as described in this thread: http://www.ussg.iu.edu/hypermail/linux/kernel/0612.0/0690.html Enjoy the holiday season, --alessandro "...when I get it, I _get_ it" (Lara Eidemiller) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc2
On 12/24/06, Linus Torvalds [EMAIL PROTECTED] wrote: Ok, it's a couple of days delayed, because we've been trying to figure out what is up with the rtorrent hash failures since 2.6.18.3. I don't think we've made any progress, but we've cleaned up a number of suspects in the meantime. It's a bit sad, if only because I was really hoping to make 2.6.20 an easy release, and held back on merging some stuff during the merge window for that reason. And now we're battling something that was introduced much earlier.. Now, practically speaking this isn't likely to affect a lot of people, but it's still a worrisome problem, and we've had top people looking at it. And they'll continue, but xmas is coming. In the meantime, we'll continue with the stabilization, and this mainly does some driver updates (usb, sound, dri, pci hotplug) and ACPI updates (much of the latter syntactic cleanups). And arm and powerpc updates. Shortlog appended. For developers: if you sent me a patch, and I didn't apply it, it was probably just missed because I concentrated on other issues. So pls re-send.. Unless I explicitly told you that I'm not going to pull it due to the merge window being over, of course ;) Linus [shortlog snipped] As already reported multiple times, including at -rc1 time... still need this libata-sff.c patch: http://marc.theaimsgroup.com/?l=linux-kernelm=116343564202844q=raw to have my root device detected, ata_piix probe would otherwise fail as described in this thread: http://www.ussg.iu.edu/hypermail/linux/kernel/0612.0/0690.html Enjoy the holiday season, --alessandro ...when I get it, I _get_ it (Lara Eidemiller) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-git compilation error drivers/connector/connector.c:138: error: ?struct work_struct? has no member named ?management?
On 12/19/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: to: linux-kernel@vger.kernel.org cc: [EMAIL PROTECTED] 2.6.20-rc1-git compilation error drivers/connector/connector.c:138: error: ?struct work_struct? has no member named ?management? $ date Tue Dec 19 10:12:17 CST 2006 $ git pull Already up-to-date. $ make -j 8 CHK include/linux/version.h CHK include/linux/utsrelease.h CHK include/linux/compile.h CC drivers/connector/connector.o drivers/connector/connector.c: In function ?cn_call_callback?: drivers/connector/connector.c:138: error: ?struct work_struct? has no member named ?management? drivers/connector/connector.c:138: error: ?struct work_struct? has no member named ?management? make[2]: *** [drivers/connector/connector.o] Error 1 make[1]: *** [drivers/connector] Error 2 make[1]: *** Waiting for unfinished jobs make: *** [drivers] Error 2 make: *** Waiting for unfinished jobs Already reported twice, and fixed by Al Viro's patch: http://www.ussg.iu.edu/hypermail/linux/kernel/0612.2/0197.html (though -rc1-git6 doesn't yet have the fix) --alessandro "...when I get it, I _get_ it" (Lara Eidemiller) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-git compilation error drivers/connector/connector.c:138: error: ?struct work_struct? has no member named ?management?
On 12/19/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: to: linux-kernel@vger.kernel.org cc: [EMAIL PROTECTED] 2.6.20-rc1-git compilation error drivers/connector/connector.c:138: error: ?struct work_struct? has no member named ?management? $ date Tue Dec 19 10:12:17 CST 2006 $ git pull Already up-to-date. $ make -j 8 CHK include/linux/version.h CHK include/linux/utsrelease.h CHK include/linux/compile.h CC drivers/connector/connector.o drivers/connector/connector.c: In function ?cn_call_callback?: drivers/connector/connector.c:138: error: ?struct work_struct? has no member named ?management? drivers/connector/connector.c:138: error: ?struct work_struct? has no member named ?management? make[2]: *** [drivers/connector/connector.o] Error 1 make[1]: *** [drivers/connector] Error 2 make[1]: *** Waiting for unfinished jobs make: *** [drivers] Error 2 make: *** Waiting for unfinished jobs Already reported twice, and fixed by Al Viro's patch: http://www.ussg.iu.edu/hypermail/linux/kernel/0612.2/0197.html (though -rc1-git6 doesn't yet have the fix) --alessandro ...when I get it, I _get_ it (Lara Eidemiller) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 file content corruption on ext3
On 12/18/06, Andrei Popa <[EMAIL PROTECTED]> wrote: On Mon, 2006-12-18 at 12:41 -0800, Linus Torvalds wrote: > > On Mon, 18 Dec 2006, Linus Torvalds wrote: > > > > But at the same time, it's interesting that it still happens when we try > > to re-add the dirty bit. That would tell me that it's one of two cases: > > Forget that. There's a third case, which is much more likely: > > - Andrew's patch had a ", 1" where it _should_ have had a ", 0". > > This should be fairly easy to test: just change every single ", 1" case in > the patch to ", 0". > > The only case that _definitely_ would want ",1" is actually the case that > already calls page_mkclean() directly: clear_page_dirty_for_io(). So no > other ", 1" is valid, and that one that needed it already avoided even > calling the "test_clear_page_dirty()" function, because it did it all by > hand. > > What happens for you in that case? > > Linus I have file corruption. No idea whether this can be a data point or not, but here it goes... my P2P box is about to turn 5 days old while running nonstop one or both of aMule 2.1.3 and BitTorrent 4.4.0 on ext3 mounted w/default options on both IDE and USB disks. Zero corruption. AMD K7-800, 512MB RAM, PREEMPT/UP kernel, 2.6.19-git20 on top of up-to-date FC6. --alessandro "...when I get it, I _get_ it" (Lara Eidemiller) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 file content corruption on ext3
On 12/18/06, Andrei Popa [EMAIL PROTECTED] wrote: On Mon, 2006-12-18 at 12:41 -0800, Linus Torvalds wrote: On Mon, 18 Dec 2006, Linus Torvalds wrote: But at the same time, it's interesting that it still happens when we try to re-add the dirty bit. That would tell me that it's one of two cases: Forget that. There's a third case, which is much more likely: - Andrew's patch had a , 1 where it _should_ have had a , 0. This should be fairly easy to test: just change every single , 1 case in the patch to , 0. The only case that _definitely_ would want ,1 is actually the case that already calls page_mkclean() directly: clear_page_dirty_for_io(). So no other , 1 is valid, and that one that needed it already avoided even calling the test_clear_page_dirty() function, because it did it all by hand. What happens for you in that case? Linus I have file corruption. No idea whether this can be a data point or not, but here it goes... my P2P box is about to turn 5 days old while running nonstop one or both of aMule 2.1.3 and BitTorrent 4.4.0 on ext3 mounted w/default options on both IDE and USB disks. Zero corruption. AMD K7-800, 512MB RAM, PREEMPT/UP kernel, 2.6.19-git20 on top of up-to-date FC6. --alessandro ...when I get it, I _get_ it (Lara Eidemiller) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20-rc1-git4: drivers/connector/connector.c doesn't build due to work_struct changes
CC [M] drivers/char/hangcheck-timer.o CC drivers/clocksource/acpi_pm.o LD drivers/clocksource/built-in.o CC [M] drivers/connector/cn_queue.o CC [M] drivers/connector/connector.o drivers/connector/connector.c: In function 'cn_call_callback': drivers/connector/connector.c:138: error: 'struct work_struct' has no member named 'management' drivers/connector/connector.c:138: error: 'struct work_struct' has no member named 'management' make[2]: *** [drivers/connector/connector.o] Error 1 make[1]: *** [drivers/connector] Error 2 make: *** [drivers] Error 2 --alessandro "...when I get it, I _get_ it" (Lara Eidemiller) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20-rc1-git4: drivers/connector/connector.c doesn't build due to work_struct changes
CC [M] drivers/char/hangcheck-timer.o CC drivers/clocksource/acpi_pm.o LD drivers/clocksource/built-in.o CC [M] drivers/connector/cn_queue.o CC [M] drivers/connector/connector.o drivers/connector/connector.c: In function 'cn_call_callback': drivers/connector/connector.c:138: error: 'struct work_struct' has no member named 'management' drivers/connector/connector.c:138: error: 'struct work_struct' has no member named 'management' make[2]: *** [drivers/connector/connector.o] Error 1 make[1]: *** [drivers/connector] Error 2 make: *** [drivers] Error 2 --alessandro ...when I get it, I _get_ it (Lara Eidemiller) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-git19: lockdep messages on console
On 12/15/06, Jarek Poplawski <[EMAIL PROTECTED]> wrote: On 12-12-2006 20:49, Alessandro Suardi wrote: > Very shortly after boot on my K7-800 running up-to-date FC6 > and 2.6.19-git19; didn't happen in 2.6.19-vanilla: ... > [ 134.915521] INFO: trying to register non-static key. > [ 134.915890] the code is fine but needs lockdep annotation. > [ 134.916249] turning off the locking correctness validator. It looks like repaired in 2.6.20-rc1 by this: [patch] lockdep: fix seqlock_init() Thanks Jarek, I don't seem to get it in -git20 already. Ciao, --alessandro "...when I get it, I _get_ it" (Lara Eidemiller) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-git19: lockdep messages on console
On 12/15/06, Jarek Poplawski [EMAIL PROTECTED] wrote: On 12-12-2006 20:49, Alessandro Suardi wrote: Very shortly after boot on my K7-800 running up-to-date FC6 and 2.6.19-git19; didn't happen in 2.6.19-vanilla: ... [ 134.915521] INFO: trying to register non-static key. [ 134.915890] the code is fine but needs lockdep annotation. [ 134.916249] turning off the locking correctness validator. It looks like repaired in 2.6.20-rc1 by this: [patch] lockdep: fix seqlock_init() Thanks Jarek, I don't seem to get it in -git20 already. Ciao, --alessandro ...when I get it, I _get_ it (Lara Eidemiller) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc1
On 12/14/06, Linus Torvalds <[EMAIL PROTECTED]> wrote: Ok, the two-week merge period is over, and -rc1 is out there. Still need this libata-sff.c patch: http://marc.theaimsgroup.com/?l=linux-kernel=116343564202844=raw to have my root device detected, ata_piix probe would otherwise fail as described in this thread: http://www.ussg.iu.edu/hypermail/linux/kernel/0612.0/0690.html --alessandro "...when I get it, I _get_ it" (Lara Eidemiller) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc1
On 12/14/06, Linus Torvalds [EMAIL PROTECTED] wrote: Ok, the two-week merge period is over, and -rc1 is out there. Still need this libata-sff.c patch: http://marc.theaimsgroup.com/?l=linux-kernelm=116343564202844q=raw to have my root device detected, ata_piix probe would otherwise fail as described in this thread: http://www.ussg.iu.edu/hypermail/linux/kernel/0612.0/0690.html --alessandro ...when I get it, I _get_ it (Lara Eidemiller) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-git3 panics on boot - ata_piix/PCI related [still in -git17]
On 12/12/06, Steve Wise <[EMAIL PROTECTED]> wrote:
On Tue, 2006-12-12 at 13:04 -0500, Jeff Garzik wrote:
> Alan wrote:
> > On Tue, 12 Dec 2006 10:39:02 -0600
> > Steve Wise <[EMAIL PROTECTED]> wrote:
> >
> >> All,
> >>
> >> Bisecting reveals that this commit causes the problem:
> >
> > Yes we know. There is a libata patch missing. As I said - if it is still
> > missing by -rc1 I'll sort out a diff.
>
> What's the patch? Message-id? I don't have anything from you in my
> patch queue.
>
> Jeff
>
>
>
I dug up the patch below from here:
http://marc.theaimsgroup.com/?l=linux-kernel=116343564202844=raw
This patch fixes my problem, and I don't think its in Linus's tree at
this point.
Steve.
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 10ee22a..40a2bfa 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -1027,13 +1027,13 @@ #if defined(CONFIG_NO_ATA_LEGACY)
#endif
}
- rc = pci_request_regions(pdev, DRV_NAME);
- if (rc) {
- disable_dev_on_err = 0;
- goto err_out;
- }
-
- if (legacy_mode) {
+ if (!legacy_mode) {
+ rc = pci_request_regions(pdev, DRV_NAME);
+ if (rc) {
+ disable_dev_on_err = 0;
+ goto err_out;
+ }
+ } else {
if (!request_region(ATA_PRIMARY_CMD, 8, "libata")) {
struct resource *conflict, res;
res.start = ATA_PRIMARY_CMD;
This patch on top of 2.6.19-git19 fixes my boot problem. Thanks !
--alessandro
"...when I get it, I _get_ it"
(Lara Eidemiller)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.19-git19: lockdep messages on console
Very shortly after boot on my K7-800 running up-to-date FC6 and 2.6.19-git19; didn't happen in 2.6.19-vanilla: [ 42.911439] EXT3-fs: mounted filesystem with ordered data mode. [ 43.749614] Adding 248968k swap on /dev/hda5. Priority:-1 extents:1 across:248968k [ 43.773965] Adding 240932k swap on /dev/hdb6. Priority:-2 extents:1 across:240932k [ 54.951190] eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1 [ 56.954293] skge eth1: enabling interface [ 92.748209] cdrom: This disc doesn't have any tracks I recognize! [ 134.915521] INFO: trying to register non-static key. [ 134.915890] the code is fine but needs lockdep annotation. [ 134.916249] turning off the locking correctness validator. [ 134.916635] [] dump_trace+0x63/0x1eb [ 134.916981] [] show_trace_log_lvl+0x1a/0x2f [ 134.917351] [] show_trace+0x12/0x14 [ 134.917674] [] dump_stack+0x16/0x18 [ 134.917997] [] __lock_acquire+0x124/0x9d0 [ 134.918365] [] lock_acquire+0x68/0x82 [ 134.918699] [] _spin_lock+0x35/0x42 [ 134.919035] [] neigh_destroy+0x96/0x11a [ 134.919391] [] neigh_periodic_timer+0x105/0x157 [ 134.919780] [] run_timer_softirq+0xed/0x14a [ 134.920157] [] __do_softirq+0x52/0xaa [ 134.920491] [] do_softirq+0x5b/0xc8 [ 134.920816] [] irq_exit+0x3c/0x48 [ 134.921126] [] do_IRQ+0xb2/0xc8 [ 134.921425] [] common_interrupt+0x2e/0x34 [ 134.921785] [] default_idle+0x3b/0x54 [ 134.922118] [] apm_cpu_idle+0x19f/0x1f4 [ 134.922468] [] cpu_idle+0x41/0x6a [ 134.922778] [] rest_init+0x37/0x3a [ 134.923092] [] start_kernel+0x2dd/0x2df [ 134.923450] === Available for patch testing. Thanks, --alessandro "...when I get it, I _get_ it" (Lara Eidemiller) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.19-git19: lockdep messages on console
Very shortly after boot on my K7-800 running up-to-date FC6 and 2.6.19-git19; didn't happen in 2.6.19-vanilla: [ 42.911439] EXT3-fs: mounted filesystem with ordered data mode. [ 43.749614] Adding 248968k swap on /dev/hda5. Priority:-1 extents:1 across:248968k [ 43.773965] Adding 240932k swap on /dev/hdb6. Priority:-2 extents:1 across:240932k [ 54.951190] eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1 [ 56.954293] skge eth1: enabling interface [ 92.748209] cdrom: This disc doesn't have any tracks I recognize! [ 134.915521] INFO: trying to register non-static key. [ 134.915890] the code is fine but needs lockdep annotation. [ 134.916249] turning off the locking correctness validator. [ 134.916635] [c01032b8] dump_trace+0x63/0x1eb [ 134.916981] [c010345a] show_trace_log_lvl+0x1a/0x2f [ 134.917351] [c0103aec] show_trace+0x12/0x14 [ 134.917674] [c0103b9e] dump_stack+0x16/0x18 [ 134.917997] [c0129f69] __lock_acquire+0x124/0x9d0 [ 134.918365] [c012ab4d] lock_acquire+0x68/0x82 [ 134.918699] [c03191d7] _spin_lock+0x35/0x42 [ 134.919035] [c02c0658] neigh_destroy+0x96/0x11a [ 134.919391] [c02c2481] neigh_periodic_timer+0x105/0x157 [ 134.919780] [c011aabc] run_timer_softirq+0xed/0x14a [ 134.920157] [c0117842] __do_softirq+0x52/0xaa [ 134.920491] [c0104b87] do_softirq+0x5b/0xc8 [ 134.920816] [c01177e4] irq_exit+0x3c/0x48 [ 134.921126] [c0104ca6] do_IRQ+0xb2/0xc8 [ 134.921425] [c0102d5a] common_interrupt+0x2e/0x34 [ 134.921785] [c0101670] default_idle+0x3b/0x54 [ 134.922118] [c010be99] apm_cpu_idle+0x19f/0x1f4 [ 134.922468] [c0100f86] cpu_idle+0x41/0x6a [ 134.922778] [c01005b1] rest_init+0x37/0x3a [ 134.923092] [c046c6d9] start_kernel+0x2dd/0x2df [ 134.923450] === Available for patch testing. Thanks, --alessandro ...when I get it, I _get_ it (Lara Eidemiller) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-git3 panics on boot - ata_piix/PCI related [still in -git17]
On 12/12/06, Steve Wise [EMAIL PROTECTED] wrote:
On Tue, 2006-12-12 at 13:04 -0500, Jeff Garzik wrote:
Alan wrote:
On Tue, 12 Dec 2006 10:39:02 -0600
Steve Wise [EMAIL PROTECTED] wrote:
All,
Bisecting reveals that this commit causes the problem:
Yes we know. There is a libata patch missing. As I said - if it is still
missing by -rc1 I'll sort out a diff.
What's the patch? Message-id? I don't have anything from you in my
patch queue.
Jeff
I dug up the patch below from here:
http://marc.theaimsgroup.com/?l=linux-kernelm=116343564202844q=raw
This patch fixes my problem, and I don't think its in Linus's tree at
this point.
Steve.
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 10ee22a..40a2bfa 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -1027,13 +1027,13 @@ #if defined(CONFIG_NO_ATA_LEGACY)
#endif
}
- rc = pci_request_regions(pdev, DRV_NAME);
- if (rc) {
- disable_dev_on_err = 0;
- goto err_out;
- }
-
- if (legacy_mode) {
+ if (!legacy_mode) {
+ rc = pci_request_regions(pdev, DRV_NAME);
+ if (rc) {
+ disable_dev_on_err = 0;
+ goto err_out;
+ }
+ } else {
if (!request_region(ATA_PRIMARY_CMD, 8, libata)) {
struct resource *conflict, res;
res.start = ATA_PRIMARY_CMD;
This patch on top of 2.6.19-git19 fixes my boot problem. Thanks !
--alessandro
...when I get it, I _get_ it
(Lara Eidemiller)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-git3 panics on boot - ata_piix/PCI related [still in -git17]
On 12/3/06, Alessandro Suardi <[EMAIL PROTECTED]> wrote: On 12/3/06, Alan <[EMAIL PROTECTED]> wrote: > > > ACPI: PCI Interrupt :00:1f.2[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ5 > > > PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for device :00:1f.2 > > > ata_piix: probe of :00:1f.2 failed with error -16 > > > [snip] > > > mount: could not find filesystem '/dev/root' > > > > Same failure is also in 2.6.19-git4... > > Thats the PCI updates - you need the matching fix to libata-sff where it > tries to reserve stuff it shouldn't. Thanks Alan. Indeed -git1 is where stuff breaks for me. I'll watch out for when libata-sff gets fixed in the -git snapshots and will then report back. Alan, I still have this problem in 2.6.19-git17. Is this expected behavior or should it have been fixed by now ? Thanks, --alessandro "...when I get it, I _get_ it" (Lara Eidemiller) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-git3 panics on boot - ata_piix/PCI related [still in -git17]
On 12/3/06, Alessandro Suardi [EMAIL PROTECTED] wrote: On 12/3/06, Alan [EMAIL PROTECTED] wrote: ACPI: PCI Interrupt :00:1f.2[B] - Link [LNKB] - GSI 5 (level, low) - IRQ5 PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for device :00:1f.2 ata_piix: probe of :00:1f.2 failed with error -16 [snip] mount: could not find filesystem '/dev/root' Same failure is also in 2.6.19-git4... Thats the PCI updates - you need the matching fix to libata-sff where it tries to reserve stuff it shouldn't. Thanks Alan. Indeed -git1 is where stuff breaks for me. I'll watch out for when libata-sff gets fixed in the -git snapshots and will then report back. Alan, I still have this problem in 2.6.19-git17. Is this expected behavior or should it have been fixed by now ? Thanks, --alessandro ...when I get it, I _get_ it (Lara Eidemiller) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-git3 panics on boot - ata_piix/PCI related
On 12/3/06, Alan <[EMAIL PROTECTED]> wrote: > > ACPI: PCI Interrupt :00:1f.2[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ5 > > PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for device :00:1f.2 > > ata_piix: probe of :00:1f.2 failed with error -16 > > [snip] > > mount: could not find filesystem '/dev/root' > > Same failure is also in 2.6.19-git4... Thats the PCI updates - you need the matching fix to libata-sff where it tries to reserve stuff it shouldn't. Thanks Alan. Indeed -git1 is where stuff breaks for me. I'll watch out for when libata-sff gets fixed in the -git snapshots and will then report back. --alessandro "...when I get it, I _get_ it" (Lara Eidemiller) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-git3 panics on boot - ata_piix/PCI related
On 12/3/06, Alessandro Suardi <[EMAIL PROTECTED]> wrote: FC6-latest running on a Latitude D610, SATA hard disk; 2.6.19 is okay, kernel built with oldconfig from the known-working setup fails to boot not recognizing the root partition, which is due to ata_piix not loading due to a PCI I/O reserve error. Happens both with and without CONFIG_SYSFS_DEPRECATED (I first had it to N then thought it might have had something to do with the boot error so I rebuilt with Y - no change). Messages hand-copied from the screen on the 2nd try: Loading ata_piix.ko module ata_piix :00:1f.2: MAP [ P0 P2 IDE IDE ] ACPI: PCI Interrupt :00:1f.2[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ5 PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for device :00:1f.2 ata_piix: probe of :00:1f.2 failed with error -16 [snip] mount: could not find filesystem '/dev/root' Same failure is also in 2.6.19-git4... I'll download -git1 and -git2 to see which one broke my setup first. This is what is in the dmesg ring of 2.6.19: ata_piix :00:1f.2: version 2.00ac6 ata_piix :00:1f.2: MAP [ P0 P2 IDE IDE ] ACPI: PCI Interrupt :00:1f.2[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5 PCI: Setting latency timer of device :00:1f.2 to 64 ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xBFA0 irq 14 ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xBFA8 irq 15 scsi0 : ata_piix ata1.00: ATA-6, max UDMA/100, 117210240 sectors: LBA ata1.00: ata1: dev 0 multi count 8 ata1.00: applying bridge limits ata1.00: configured for UDMA/100 scsi1 : ata_piix ata2.00: ATAPI, max UDMA/33 ata2.00: configured for UDMA/33 --alessandro "...when I get it, I _get_ it" (Lara Eidemiller) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.19-git3 panics on boot - ata_piix/PCI related
FC6-latest running on a Latitude D610, SATA hard disk; 2.6.19 is okay, kernel built with oldconfig from the known-working setup fails to boot not recognizing the root partition, which is due to ata_piix not loading due to a PCI I/O reserve error. Happens both with and without CONFIG_SYSFS_DEPRECATED (I first had it to N then thought it might have had something to do with the boot error so I rebuilt with Y - no change). Messages hand-copied from the screen on the 2nd try: Loading ata_piix.ko module ata_piix :00:1f.2: MAP [ P0 P2 IDE IDE ] ACPI: PCI Interrupt :00:1f.2[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ5 PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for device :00:1f.2 ata_piix: probe of :00:1f.2 failed with error -16 [snip] mount: could not find filesystem '/dev/root' This is what is in the dmesg ring of 2.6.19: ata_piix :00:1f.2: version 2.00ac6 ata_piix :00:1f.2: MAP [ P0 P2 IDE IDE ] ACPI: PCI Interrupt :00:1f.2[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5 PCI: Setting latency timer of device :00:1f.2 to 64 ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xBFA0 irq 14 ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xBFA8 irq 15 scsi0 : ata_piix ata1.00: ATA-6, max UDMA/100, 117210240 sectors: LBA ata1.00: ata1: dev 0 multi count 8 ata1.00: applying bridge limits ata1.00: configured for UDMA/100 scsi1 : ata_piix ata2.00: ATAPI, max UDMA/33 ata2.00: configured for UDMA/33 --alessandro "...when I get it, I _get_ it" (Lara Eidemiller) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.19-git3 panics on boot - ata_piix/PCI related
FC6-latest running on a Latitude D610, SATA hard disk; 2.6.19 is okay, kernel built with oldconfig from the known-working setup fails to boot not recognizing the root partition, which is due to ata_piix not loading due to a PCI I/O reserve error. Happens both with and without CONFIG_SYSFS_DEPRECATED (I first had it to N then thought it might have had something to do with the boot error so I rebuilt with Y - no change). Messages hand-copied from the screen on the 2nd try: Loading ata_piix.ko module ata_piix :00:1f.2: MAP [ P0 P2 IDE IDE ] ACPI: PCI Interrupt :00:1f.2[B] - Link [LNKB] - GSI 5 (level, low) - IRQ5 PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for device :00:1f.2 ata_piix: probe of :00:1f.2 failed with error -16 [snip] mount: could not find filesystem '/dev/root' This is what is in the dmesg ring of 2.6.19: ata_piix :00:1f.2: version 2.00ac6 ata_piix :00:1f.2: MAP [ P0 P2 IDE IDE ] ACPI: PCI Interrupt :00:1f.2[B] - Link [LNKB] - GSI 5 (level, low) - IRQ 5 PCI: Setting latency timer of device :00:1f.2 to 64 ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xBFA0 irq 14 ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xBFA8 irq 15 scsi0 : ata_piix ata1.00: ATA-6, max UDMA/100, 117210240 sectors: LBA ata1.00: ata1: dev 0 multi count 8 ata1.00: applying bridge limits ata1.00: configured for UDMA/100 scsi1 : ata_piix ata2.00: ATAPI, max UDMA/33 ata2.00: configured for UDMA/33 --alessandro ...when I get it, I _get_ it (Lara Eidemiller) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-git3 panics on boot - ata_piix/PCI related
On 12/3/06, Alessandro Suardi [EMAIL PROTECTED] wrote: FC6-latest running on a Latitude D610, SATA hard disk; 2.6.19 is okay, kernel built with oldconfig from the known-working setup fails to boot not recognizing the root partition, which is due to ata_piix not loading due to a PCI I/O reserve error. Happens both with and without CONFIG_SYSFS_DEPRECATED (I first had it to N then thought it might have had something to do with the boot error so I rebuilt with Y - no change). Messages hand-copied from the screen on the 2nd try: Loading ata_piix.ko module ata_piix :00:1f.2: MAP [ P0 P2 IDE IDE ] ACPI: PCI Interrupt :00:1f.2[B] - Link [LNKB] - GSI 5 (level, low) - IRQ5 PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for device :00:1f.2 ata_piix: probe of :00:1f.2 failed with error -16 [snip] mount: could not find filesystem '/dev/root' Same failure is also in 2.6.19-git4... I'll download -git1 and -git2 to see which one broke my setup first. This is what is in the dmesg ring of 2.6.19: ata_piix :00:1f.2: version 2.00ac6 ata_piix :00:1f.2: MAP [ P0 P2 IDE IDE ] ACPI: PCI Interrupt :00:1f.2[B] - Link [LNKB] - GSI 5 (level, low) - IRQ 5 PCI: Setting latency timer of device :00:1f.2 to 64 ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xBFA0 irq 14 ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xBFA8 irq 15 scsi0 : ata_piix ata1.00: ATA-6, max UDMA/100, 117210240 sectors: LBA ata1.00: ata1: dev 0 multi count 8 ata1.00: applying bridge limits ata1.00: configured for UDMA/100 scsi1 : ata_piix ata2.00: ATAPI, max UDMA/33 ata2.00: configured for UDMA/33 --alessandro ...when I get it, I _get_ it (Lara Eidemiller) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-git3 panics on boot - ata_piix/PCI related
On 12/3/06, Alan [EMAIL PROTECTED] wrote: ACPI: PCI Interrupt :00:1f.2[B] - Link [LNKB] - GSI 5 (level, low) - IRQ5 PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for device :00:1f.2 ata_piix: probe of :00:1f.2 failed with error -16 [snip] mount: could not find filesystem '/dev/root' Same failure is also in 2.6.19-git4... Thats the PCI updates - you need the matching fix to libata-sff where it tries to reserve stuff it shouldn't. Thanks Alan. Indeed -git1 is where stuff breaks for me. I'll watch out for when libata-sff gets fixed in the -git snapshots and will then report back. --alessandro ...when I get it, I _get_ it (Lara Eidemiller) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
