Oopses after SL 9.2 kernel security update
Hello, yesterday I have installed the kernel update for SL 9.2 (2.6.8-24.17.i586 SL92_BRANCH-200507190856330000) via YOU. Today (the first reboot) I tried to compile some source and gcc segfaulted. Opera did not start either. Then I noticed the oopses (see end of this mail). rpm segfaulted when I tried to downgrade. Using the rescue system and the recent version of reiserfsck showed no corruption. After downgrading to 2.6.8-24.16 there are no more oopses. Aug 6 13:30:50 linux su: (to nobody) root on none Aug 6 13:30:50 linux su: pam_unix2: session started for user nobody, service su Aug 6 13:30:50 linux su: pam_unix2: session finished for user nobody, service su Aug 6 13:30:50 linux su: (to nobody) root on none Aug 6 13:30:50 linux su: pam_unix2: session started for user nobody, service su Aug 6 13:31:02 linux su: pam_unix2: session finished for user nobody, service su Aug 6 13:31:02 linux su: (to nobody) root on none Aug 6 13:31:02 linux su: pam_unix2: session started for user nobody, service su Aug 6 13:31:02 linux su: pam_unix2: session finished for user nobody, service su Aug 6 13:31:02 linux su: (to nobody) root on none Aug 6 13:31:02 linux su: pam_unix2: session started for user nobody, service su Aug 6 13:32:30 linux kernel: Unable to handle kernel paging request at virtual address 00400000 Aug 6 13:32:30 linux kernel: printing eip: Aug 6 13:32:30 linux kernel: c0165ed6 Aug 6 13:32:30 linux kernel: *pde = 00000000 Aug 6 13:32:30 linux kernel: Oops: 0000 [#1] Aug 6 13:32:30 linux kernel: Modules linked in: nvidia usbserial parport_pc lp parport nvram speedstep_lib freq_table thermal processor fan button battery ac snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc it87 i2c_sensor i2c_isa i2c_core edd ipt_tos ipt_MARK ipt_length cls_fw sch_htb ipt_TOS ip6t_LOG ip6t_limit ipt_LOG ipt_limit ipt_pkttype af_packet joydev sg st sd_mod sr_mod scsi_mod ip6t_state ip6_conntrack ipt_state ip6t_REJECT ipt_REJECT iptable_mangle iptable_filter ip6table_mangle ip_nat_ftp iptable_nat ip_conntrack_ftp ip_conntrack ip_tables ip6table_filter ip6_tables ipv6 ohci_hcd nvidia_agp agpgart ide_cd cdrom evdev subfs dm_mod 8139too mii usbcore reiserfs Aug 6 13:32:30 linux kernel: CPU: 0 Aug 6 13:32:30 linux kernel: EIP: 0060:[<c0165ed6>] Tainted: P U VLI Aug 6 13:32:30 linux kernel: EFLAGS: 00010206 (2.6.8-24.17-default SL92_BRANCH-200507190856330000) Aug 6 13:32:30 linux kernel: EIP is at __d_lookup+0x76/0xf0 Aug 6 13:32:30 linux kernel: eax: 00400000 ebx: 00400000 ecx: 00000011 edx: c1410200 Aug 6 13:32:30 linux kernel: esi: 839f51ea edi: cc45bec8 ebp: c154611c esp: cc45be6c Aug 6 13:32:30 linux kernel: ds: 007b es: 007b ss: 0068 Aug 6 13:32:31 linux kernel: Process find (pid: 6855, threadinfo=cc45a000 task=de561000) Aug 6 13:32:31 linux kernel: Stack: 839f51ea c3e8632c 00000001 cc45bf1c 00000000 c1457818 d43f3000 00000008 Aug 6 13:32:31 linux kernel: cc45bed0 cc45bed0 cc45bf1c cc45bec8 cc45bed0 c015c6a8 cdec0080 cc45bed0 Aug 6 13:32:31 linux kernel: 839f51ea c3e8ed18 d43f3008 c015cdc9 cc45bf00 00000000 cc45bf1c cc45a000 Aug 6 13:32:31 linux kernel: Call Trace: Aug 6 13:32:31 linux kernel: [<c015c6a8>] do_lookup+0x18/0x70 Aug 6 13:32:31 linux kernel: [<c015cdc9>] link_path_walk+0x6c9/0xca0 Aug 6 13:32:31 linux kernel: [<c015d5b3>] path_lookup+0x73/0x150 Aug 6 13:32:31 linux kernel: [<c015d7e1>] __user_walk+0x21/0x60 Aug 6 13:32:31 linux kernel: [<c0158df1>] vfs_lstat+0x11/0x40 Aug 6 13:32:31 linux kernel: [<c015948f>] sys_lstat64+0xf/0x30 Aug 6 13:32:31 linux kernel: [<c01441ed>] do_no_page+0x9d/0x270 Aug 6 13:32:31 linux kernel: [<c0150753>] filp_close+0x43/0x70 Aug 6 13:32:31 linux kernel: [<c0105c69>] sysenter_past_esp+0x52/0x79 Aug 6 13:32:31 linux kernel: Code: c0 21 d0 8b 15 6c ab 43 c0 c7 44 24 10 00 00 00 00 8d 04 82 89 44 24 14 8b 18 85 db 75 0d eb 69 90 8d 74 26 00 8b 1b 85 db 74 5e <8b> 03 0f 18 00 90 8d 6b a4 8b 34 24 39 75 14 75 e9 8b 7c 24 04 Aug 6 13:32:30 linux su: pam_unix2: session finished for user nobody, service su Aug 6 13:39:30 linux kernel: <1>Unable to handle kernel paging request at virtual address 00400000 Aug 6 13:39:30 linux kernel: printing eip: Aug 6 13:39:30 linux kernel: c0165ed6 Aug 6 13:39:30 linux kernel: *pde = 00000000 Aug 6 13:39:30 linux kernel: Oops: 0000 [#2] Aug 6 13:39:30 linux kernel: Modules linked in: nvidia usbserial parport_pc lp parport nvram speedstep_lib freq_table thermal processor fan button battery ac snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc it87 i2c_sensor i2c_isa i2c_core edd ipt_tos ipt_MARK ipt_length cls_fw sch_htb ipt_TOS ip6t_LOG ip6t_limit ipt_LOG ipt_limit ipt_pkttype af_packet joydev sg st sd_mod sr_mod scsi_mod ip6t_state ip6_conntrack ipt_state ip6t_REJECT ipt_REJECT iptable_mangle iptable_filter ip6table_mangle ip_nat_ftp iptable_nat ip_conntrack_ftp ip_conntrack ip_tables ip6table_filter ip6_tables ipv6 ohci_hcd nvidia_agp agpgart ide_cd cdrom evdev subfs dm_mod 8139too mii usbcore reiserfs Aug 6 13:39:30 linux kernel: CPU: 0 Aug 6 13:39:30 linux kernel: EIP: 0060:[<c0165ed6>] Tainted: P U VLI Aug 6 13:39:30 linux kernel: EFLAGS: 00210206 (2.6.8-24.17-default SL92_BRANCH-200507190856330000) Aug 6 13:39:30 linux kernel: EIP is at __d_lookup+0x76/0xf0 Aug 6 13:39:30 linux kernel: eax: 00400000 ebx: 00400000 ecx: 00000011 edx: c1410200 Aug 6 13:39:30 linux kernel: esi: d21c440d edi: d5e3def8 ebp: c154611c esp: d5e3de9c Aug 6 13:39:30 linux kernel: ds: 007b es: 007b ss: 0068 Aug 6 13:39:31 linux kernel: Process cc1plus (pid: 27981, threadinfo=d5e3c000 task=d8a66aa0) Aug 6 13:39:31 linux kernel: Stack: d21c440d d24cdd70 fffffff4 c283b8e0 00000000 c1457818 d792300d 0000000e Aug 6 13:39:31 linux kernel: d5e3df00 d5e3df00 d5e3df68 d5e3def8 d5e3df00 c015c6a8 cdec0080 d5e3df00 Aug 6 13:39:31 linux kernel: d21c440d d2bb8290 d792301b c015cdc9 dd8e9a50 00000101 d5e3df68 cdec0080 Aug 6 13:39:31 linux kernel: Call Trace: Aug 6 13:39:31 linux kernel: [<c015c6a8>] do_lookup+0x18/0x70 Aug 6 13:39:31 linux kernel: [<c015cdc9>] link_path_walk+0x6c9/0xca0 Aug 6 13:39:31 linux kernel: [<c015d5b3>] path_lookup+0x73/0x150 Aug 6 13:39:31 linux kernel: [<c015dd15>] open_namei+0x85/0x5e0 Aug 6 13:39:31 linux kernel: [<c0145c20>] __do_mmap_pgoff+0x410/0x700 Aug 6 13:39:31 linux kernel: [<c01503a4>] filp_open+0x24/0x50 Aug 6 13:39:31 linux kernel: [<c01506a1>] sys_open+0x31/0x80 Aug 6 13:39:31 linux kernel: [<c0105c69>] sysenter_past_esp+0x52/0x79 Aug 6 13:39:31 linux kernel: Code: c0 21 d0 8b 15 6c ab 43 c0 c7 44 24 10 00 00 00 00 8d 04 82 89 44 24 14 8b 18 85 db 75 0d eb 69 90 8d 74 26 00 8b 1b 85 db 74 5e <8b> 03 0f 18 00 90 8d 6b a4 8b 34 24 39 75 14 75 e9 8b 7c 24 04 Aug 6 13:46:09 linux kernel: <1>Unable to handle kernel paging request at virtual address 00400000 Aug 6 13:46:09 linux kernel: printing eip: Aug 6 13:46:09 linux kernel: c0165ed6 Aug 6 13:46:09 linux kernel: *pde = 00000000 Aug 6 13:46:09 linux kernel: Oops: 0000 [#3] Aug 6 13:46:09 linux kernel: Modules linked in: nvidia usbserial parport_pc lp parport nvram speedstep_lib freq_table thermal processor fan button battery ac snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc it87 i2c_sensor i2c_isa i2c_core edd ipt_tos ipt_MARK ipt_length cls_fw sch_htb ipt_TOS ip6t_LOG ip6t_limit ipt_LOG ipt_limit ipt_pkttype af_packet joydev sg st sd_mod sr_mod scsi_mod ip6t_state ip6_conntrack ipt_state ip6t_REJECT ipt_REJECT iptable_mangle iptable_filter ip6table_mangle ip_nat_ftp iptable_nat ip_conntrack_ftp ip_conntrack ip_tables ip6table_filter ip6_tables ipv6 ohci_hcd nvidia_agp agpgart ide_cd cdrom evdev subfs dm_mod 8139too mii usbcore reiserfs Aug 6 13:46:09 linux kernel: CPU: 0 Aug 6 13:46:09 linux kernel: EIP: 0060:[<c0165ed6>] Tainted: P U VLI Aug 6 13:46:09 linux kernel: EFLAGS: 00210206 (2.6.8-24.17-default SL92_BRANCH-200507190856330000) Aug 6 13:46:09 linux kernel: EIP is at __d_lookup+0x76/0xf0 Aug 6 13:46:09 linux kernel: eax: 00400000 ebx: 00400000 ecx: 00000011 edx: c1410200 Aug 6 13:46:09 linux kernel: esi: d21c440d edi: d85abef8 ebp: c154611c esp: d85abe9c Aug 6 13:46:09 linux kernel: ds: 007b es: 007b ss: 0068 Aug 6 13:46:09 linux kernel: Process cc1plus (pid: 28087, threadinfo=d85aa000 task=d335baa0) Aug 6 13:46:10 linux kernel: Stack: d21c440d d24cdd70 00000000 c7344bc0 00000000 c1457818 d92d700d 0000000e Aug 6 13:46:10 linux kernel: d85abf00 d85abf00 d85abf68 d85abef8 d85abf00 c015c6a8 cdec0080 d85abf00 Aug 6 13:46:10 linux kernel: d21c440d d2bb8290 d92d701b c015cdc9 c1fa6f3c 00000101 d85abf68 cdec0080 Aug 6 13:46:10 linux kernel: Call Trace: Aug 6 13:46:10 linux kernel: [<c015c6a8>] do_lookup+0x18/0x70 Aug 6 13:46:10 linux kernel: [<c015cdc9>] link_path_walk+0x6c9/0xca0 Aug 6 13:46:10 linux kernel: [<c015d5b3>] path_lookup+0x73/0x150 Aug 6 13:46:10 linux kernel: [<c015dd15>] open_namei+0x85/0x5e0 Aug 6 13:46:10 linux kernel: [<c01503a4>] filp_open+0x24/0x50 Aug 6 13:46:10 linux kernel: [<c01506a1>] sys_open+0x31/0x80 Aug 6 13:46:10 linux kernel: [<c0105c69>] sysenter_past_esp+0x52/0x79 Aug 6 13:46:10 linux kernel: Code: c0 21 d0 8b 15 6c ab 43 c0 c7 44 24 10 00 00 00 00 8d 04 82 89 44 24 14 8b 18 85 db 75 0d eb 69 90 8d 74 26 00 8b 1b 85 db 74 5e <8b> 03 0f 18 00 90 8d 6b a4 8b 34 24 39 75 14 75 e9 8b 7c 24 04 Aug 6 13:50:59 linux kernel: <1>Unable to handle kernel paging request at virtual address 00400000 Aug 6 13:50:59 linux kernel: printing eip: Aug 6 13:50:59 linux kernel: c0165ed6 Aug 6 13:50:59 linux kernel: *pde = 00000000 Aug 6 13:50:59 linux kernel: Oops: 0000 [#4] Aug 6 13:50:59 linux kernel: Modules linked in: nvidia usbserial parport_pc lp parport nvram speedstep_lib freq_table thermal processor fan button battery ac snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc it87 i2c_sensor i2c_isa i2c_core edd ipt_tos ipt_MARK ipt_length cls_fw sch_htb ipt_TOS ip6t_LOG ip6t_limit ipt_LOG ipt_limit ipt_pkttype af_packet joydev sg st sd_mod sr_mod scsi_mod ip6t_state ip6_conntrack ipt_state ip6t_REJECT ipt_REJECT iptable_mangle iptable_filter ip6table_mangle ip_nat_ftp iptable_nat ip_conntrack_ftp ip_conntrack ip_tables ip6table_filter ip6_tables ipv6 ohci_hcd nvidia_agp agpgart ide_cd cdrom evdev subfs dm_mod 8139too mii usbcore reiserfs Aug 6 13:50:59 linux kernel: CPU: 0 Aug 6 13:50:59 linux kernel: EIP: 0060:[<c0165ed6>] Tainted: P U VLI Aug 6 13:50:59 linux kernel: EFLAGS: 00210206 (2.6.8-24.17-default SL92_BRANCH-200507190856330000) Aug 6 13:50:59 linux kernel: EIP is at __d_lookup+0x76/0xf0 Aug 6 13:50:59 linux kernel: eax: 00400000 ebx: 00400000 ecx: 00000011 edx: c1410200 Aug 6 13:50:59 linux kernel: esi: d21c440d edi: d3343ef8 ebp: c154611c esp: d3343e9c Aug 6 13:50:59 linux kernel: ds: 007b es: 007b ss: 0068 Aug 6 13:50:59 linux kernel: Process cc1plus (pid: 31360, threadinfo=d3342000 task=d4ae1000) Aug 6 13:50:59 linux kernel: Stack: d21c440d d24cdd70 00000000 c7344bc0 00000000 c1457818 c172700d 0000000e Aug 6 13:50:59 linux kernel: d3343f00 d3343f00 d3343f68 d3343ef8 d3343f00 c015c6a8 cdec0080 d3343f00 Aug 6 13:50:59 linux kernel: d21c440d d2bb8290 c172701b c015cdc9 d2e678ac 00000101 d3343f68 cdec0080 Aug 6 13:50:59 linux kernel: Call Trace: Aug 6 13:50:59 linux kernel: [<c015c6a8>] do_lookup+0x18/0x70 Aug 6 13:50:59 linux kernel: [<c015cdc9>] link_path_walk+0x6c9/0xca0 Aug 6 13:50:59 linux kernel: [<c015d5b3>] path_lookup+0x73/0x150 Aug 6 13:50:59 linux kernel: [<c015dd15>] open_namei+0x85/0x5e0 Aug 6 13:50:59 linux kernel: [<c0145c20>] __do_mmap_pgoff+0x410/0x700 Aug 6 13:50:59 linux kernel: [<c01503a4>] filp_open+0x24/0x50 Aug 6 13:50:59 linux kernel: [<c01506a1>] sys_open+0x31/0x80 Aug 6 13:50:59 linux kernel: [<c0105c69>] sysenter_past_esp+0x52/0x79 Aug 6 13:50:59 linux kernel: Code: c0 21 d0 8b 15 6c ab 43 c0 c7 44 24 10 00 00 00 00 8d 04 82 89 44 24 14 8b 18 85 db 75 0d eb 69 90 8d 74 26 00 8b 1b 85 db 74 5e <8b> 03 0f 18 00 90 8d 6b a4 8b 34 24 39 75 14 75 e9 8b 7c 24 04 Aug 6 13:59:01 linux /usr/sbin/cron[31373]: (root) CMD ( rm -f /var/spool/cron/lastrun/cron.hourly) Aug 6 14:23:15 linux kernel: Unable to handle kernel paging request at virtual address 00400000 Aug 6 14:23:15 linux kernel: printing eip: Aug 6 14:23:15 linux kernel: c0165ed6 Aug 6 14:23:15 linux kernel: *pde = 00000000 Aug 6 14:23:15 linux kernel: Oops: 0000 [#5] Aug 6 14:23:15 linux kernel: Modules linked in: nvidia usbserial parport_pc lp parport nvram speedstep_lib freq_table thermal processor fan button battery ac snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc it87 i2c_sensor i2c_isa i2c_core edd ipt_tos ipt_MARK ipt_length cls_fw sch_htb ipt_TOS ip6t_LOG ip6t_limit ipt_LOG ipt_limit ipt_pkttype af_packet joydev sg st sd_mod sr_mod scsi_mod ip6t_state ip6_conntrack ipt_state ip6t_REJECT ipt_REJECT iptable_mangle iptable_filter ip6table_mangle ip_nat_ftp iptable_nat ip_conntrack_ftp ip_conntrack ip_tables ip6table_filter ip6_tables ipv6 ohci_hcd nvidia_agp agpgart ide_cd cdrom evdev subfs dm_mod 8139too mii usbcore reiserfs Aug 6 14:23:15 linux kernel: CPU: 0 Aug 6 14:23:15 linux kernel: EIP: 0060:[<c0165ed6>] Tainted: P U VLI Aug 6 14:23:15 linux kernel: EFLAGS: 00210206 (2.6.8-24.17-default SL92_BRANCH-200507190856330000) Aug 6 14:23:15 linux kernel: EIP is at __d_lookup+0x76/0xf0 Aug 6 14:23:15 linux kernel: eax: 00400000 ebx: 00400000 ecx: 00000011 edx: c1410200 Aug 6 14:23:15 linux kernel: esi: a682767b edi: c6e7def8 ebp: c154611c esp: c6e7de9c Aug 6 14:23:15 linux kernel: ds: 007b es: 007b ss: 0068 Aug 6 14:23:15 linux kernel: Process opera (pid: 1990, threadinfo=c6e7c000 task=dbb2d000) Aug 6 14:23:15 linux kernel: Stack: a682767b c87247f8 00000001 c6e7df68 00000000 c1457818 de223018 0000000c Aug 6 14:23:15 linux kernel: c6e7df00 c6e7df00 c6e7df68 c6e7def8 c6e7df00 c015c6a8 cdec0080 c6e7df00 Aug 6 14:23:15 linux kernel: a682767b cb6bfb40 de223024 c015cdc9 c0142be1 00000101 c6e7df68 cdec0080 Aug 6 14:23:15 linux kernel: Call Trace: Aug 6 14:23:15 linux kernel: [<c015c6a8>] do_lookup+0x18/0x70 Aug 6 14:23:15 linux kernel: [<c015cdc9>] link_path_walk+0x6c9/0xca0 Aug 6 14:23:15 linux kernel: [<c0142be1>] zap_pmd_range+0x41/0x60 Aug 6 14:23:15 linux kernel: [<c015d5b3>] path_lookup+0x73/0x150 Aug 6 14:23:15 linux kernel: [<c015dd15>] open_namei+0x85/0x5e0 Aug 6 14:23:15 linux kernel: [<c01503a4>] filp_open+0x24/0x50 Aug 6 14:23:15 linux kernel: [<c0146622>] unmap_region+0x82/0xd0 Aug 6 14:23:15 linux kernel: [<c01506a1>] sys_open+0x31/0x80 Aug 6 14:23:15 linux kernel: [<c0105c69>] sysenter_past_esp+0x52/0x79 Aug 6 14:23:15 linux kernel: Code: c0 21 d0 8b 15 6c ab 43 c0 c7 44 24 10 00 00 00 00 8d 04 82 89 44 24 14 8b 18 85 db 75 0d eb 69 90 8d 74 26 00 8b 1b 85 db 74 5e <8b> 03 0f 18 00 90 8d 6b a4 8b 34 24 39 75 14 75 e9 8b 7c 24 04 Aug 6 14:25:04 linux su: (to root) jan on /dev/pts/2 Aug 6 14:25:04 linux su: pam_unix2: session started for user root, service su Aug 6 14:36:40 linux kernel: Unable to handle kernel paging request at virtual address 00400000 Aug 6 14:36:40 linux kernel: printing eip: Aug 6 14:36:40 linux kernel: c0165ed6 Aug 6 14:36:40 linux kernel: *pde = 00000000 Aug 6 14:36:40 linux kernel: Oops: 0000 [#6] Aug 6 14:36:40 linux kernel: Modules linked in: nvidia usbserial parport_pc lp parport nvram speedstep_lib freq_table thermal processor fan button battery ac snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc it87 i2c_sensor i2c_isa i2c_core edd ipt_tos ipt_MARK ipt_length cls_fw sch_htb ipt_TOS ip6t_LOG ip6t_limit ipt_LOG ipt_limit ipt_pkttype af_packet joydev sg st sd_mod sr_mod scsi_mod ip6t_state ip6_conntrack ipt_state ip6t_REJECT ipt_REJECT iptable_mangle iptable_filter ip6table_mangle ip_nat_ftp iptable_nat ip_conntrack_ftp ip_conntrack ip_tables ip6table_filter ip6_tables ipv6 ohci_hcd nvidia_agp agpgart ide_cd cdrom evdev subfs dm_mod 8139too mii usbcore reiserfs Aug 6 14:36:40 linux kernel: CPU: 0 Aug 6 14:36:40 linux kernel: EIP: 0060:[<c0165ed6>] Tainted: P U VLI Aug 6 14:36:40 linux kernel: EFLAGS: 00210206 (2.6.8-24.17-default SL92_BRANCH-200507190856330000) Aug 6 14:36:40 linux kernel: EIP is at __d_lookup+0x76/0xf0 Aug 6 14:36:40 linux kernel: eax: 00400000 ebx: 00400000 ecx: 00000011 edx: c1410200 Aug 6 14:36:40 linux kernel: esi: 839f51ea edi: cb8b5ec8 ebp: c154611c esp: cb8b5e6c Aug 6 14:36:40 linux kernel: ds: 007b es: 007b ss: 0068 Aug 6 14:36:40 linux kernel: Process rpm (pid: 2432, threadinfo=cb8b4000 task=debbc000) Aug 6 14:36:40 linux kernel: Stack: 839f51ea c3e8632c fffffff4 e0d42fc0 00000000 c1457818 ddc7901e 00000008 Aug 6 14:36:40 linux kernel: cb8b5ed0 cb8b5ed0 cb8b5f1c cb8b5ec8 cb8b5ed0 c015c6a8 cdec0080 cb8b5ed0 Aug 6 14:36:40 linux kernel: 839f51ea c3e8ed18 ddc79026 c015cdc9 c1e862e0 00000001 cb8b5f1c cdec0080 Aug 6 14:36:40 linux kernel: Call Trace: Aug 6 14:36:40 linux kernel: [<e0d42fc0>] xattr_lookup_poison+0x0/0x90 [reiserfs] Aug 6 14:36:40 linux kernel: [<c015c6a8>] do_lookup+0x18/0x70 Aug 6 14:36:40 linux kernel: [<c015cdc9>] link_path_walk+0x6c9/0xca0 Aug 6 14:36:40 linux kernel: [<c015d5b3>] path_lookup+0x73/0x150 Aug 6 14:36:40 linux kernel: [<c015d7e1>] __user_walk+0x21/0x60 Aug 6 14:36:40 linux kernel: [<c0158da4>] vfs_stat+0x14/0x50 Aug 6 14:36:40 linux kernel: [<c015945f>] sys_stat64+0xf/0x30 Aug 6 14:36:40 linux kernel: [<c0117810>] do_page_fault+0x0/0x5bf Aug 6 14:36:40 linux kernel: [<c0106d9d>] error_code+0x2d/0x40 Aug 6 14:36:40 linux kernel: [<c0105c69>] sysenter_past_esp+0x52/0x79 Aug 6 14:36:40 linux kernel: Code: c0 21 d0 8b 15 6c ab 43 c0 c7 44 24 10 00 00 00 00 8d 04 82 89 44 24 14 8b 18 85 db 75 0d eb 69 90 8d 74 26 00 8b 1b 85 db 74 5e <8b> 03 0f 18 00 90 8d 6b a4 8b 34 24 39 75 14 75 e9 8b 7c 24 04 Gruß, Jan -- Hindsight is an exact science.
Jan Ritzerfeld wrote:
yesterday I have installed the kernel update for SL 9.2 (2.6.8-24.17.i586 SL92_BRANCH-200507190856330000) via YOU. Today (the first reboot) I tried to compile some source and gcc segfaulted. Opera did not start either. Then I noticed the oopses (see end of this mail). rpm segfaulted when I tried to downgrade. Using the rescue system and the recent version of reiserfsck showed no corruption. After downgrading to 2.6.8-24.16 there are no more oopses.
This is the first and only report about a problem with the 9.2 update that I am aware of so it could be a problem with your hardware. Please try to reproduce the problem with an untainted kernel (ie without use of the nvidia binary driver). Our kernel developers can't debug tainted kernels. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/
Jan Ritzerfeld wrote:
yesterday I have installed the kernel update for SL 9.2 (2.6.8-24.17.i586 SL92_BRANCH-200507190856330000) via YOU. Today (the first reboot) I tried to compile some source and gcc segfaulted. Opera did not start
This is the first and only report about a problem with the 9.2 update that I am aware of so it could be a problem with your hardware. Please try to reproduce the problem with an untainted kernel (ie without use of the nvidia binary driver). Our kernel developers can't debug tainted kernels.
Hi, it is well-known by sysadmins that there are problems with kernel updates. It seems that the first reboot without power-off may cause sometimes problems. We had Kernel panic after some days, after such a update without power-off (Suse 9.1). I did not know what is the reason. I only could imagine, that some hardware after reset is not in the same state as after power on. Very mysterious. Regards Hans Ophüls
Hans, On Monday 08 August 2005 16:13, Hans Ophüls wrote:
...,
it is well-known by sysadmins that there are problems with kernel updates. It seems that the first reboot without power-off may cause sometimes problems. We had Kernel panic after some days, after such a update without power-off (Suse 9.1).
Could I get some references on this "well-known" phenomenon?
...
Regards Hans Ophüls
Randall Schulz
On Monday 08 August 2005 8:17 pm, Randall R Schulz wrote:
Hans,
On Monday 08 August 2005 16:13, Hans Ophüls wrote:
...,
it is well-known by sysadmins that there are problems with kernel updates. It seems that the first reboot without power-off may cause sometimes problems. We had Kernel panic after some days, after such a update without power-off (Suse 9.1).
Could I get some references on this "well-known" phenomenon?
...
Regards Hans Ophüls
Randall Schulz
Aside from personal experience from years of hardware/software compatibility testing? Consider that today's wake-on-LAN or -ring functions require power to function. A simple warm reboot will not be the same as pulling the power cord and waiting 30 seconds for capacitors to drain. This does have an effect on many components in a system. Been there, done that many times and have seen the difference. To get a baseline we almost always had to remove all power for x number of seconds or minutes and then power up and re-test. Tons of fun when large SCSI arrays were first being introduced to the PC server arena. Each drive was set to spin up when the controller told it to and that was one-by-one per bus and up to 4 busses per controller. Those first 1GB SCSI drives were HUGE and still too small. Can you say single-ended versus differential and passive versus active termination? How long was that cable supposed to be to be in spec? At most we'd mention removing power in the manuals to "zero" out any stored charge(s) that should have been drained. There was no way to effectively remove all power through mechanical switches since there was a need to monitor power throughout the system if it was plugged in but not turned on. Had to know if there was AC to the system in a lights-out scenario due to spinning up 28-60 SCSI devices/controller in a controlled manner. Stan
Stan, On Monday 08 August 2005 19:56, Stan Glasoe wrote:
On Monday 08 August 2005 8:17 pm, Randall R Schulz wrote:
Hans,
On Monday 08 August 2005 16:13, Hans Ophüls wrote:
...,
it is well-known by sysadmins that there are problems with kernel updates. It seems that the first reboot without power-off may cause sometimes problems. We had Kernel panic after some days, after such a update without power-off (Suse 9.1).
Could I get some references on this "well-known" phenomenon?
...
Regards Hans Ophüls
Randall Schulz
Aside from personal experience from years of hardware/software compatibility testing?
Yes, aside from that. Because this sounds an awful lot like superstition, so I'm looking for some hard facts and documented empirical data, not just assumptions and anecdotes. Absent such facts, I'm rather doubtful that this effect is real. And using phrases like "Can you say blah-blah-blah," does not get high marks with me. If your hardware exceeds SCSI specs, then powering down won't bring it into spec.
...
Stan
Randall Schulz P.S. Your "Reply-To" header is badly munged.
On Tuesday 09 August 2005 12:01 am, Randall R Schulz wrote: <moderate snippage>
Aside from personal experience from years of hardware/software compatibility testing?
Yes, aside from that. Because this sounds an awful lot like superstition, so I'm looking for some hard facts and documented empirical data, not just assumptions and anecdotes. Absent such facts, I'm rather doubtful that this effect is real.
Hi Randall, I thought this would be an interesting exercise... how to prove this effect to Randall so he'll stop calling it "superstition?" Well, Google is one obvious route. Here's a brief sampling of hits for your personal edification. Some of these links actually point to fun, albeit esoteric, technical reading. Watch for word-wrap breaks! - Carl ... http://www.astro.caltech.edu/palomar/200inch/lfc/lfctech_main.html Start Exposure Commands * clear <[num]> Clear (wipe) the CCDs. This flushes any charge existing in the CCDs. The chips are good about not retaining residual images, but you can give clear an argument if you want to wipe it several times. Some of the CCDs may require several wipes to clear bled charge from near the bottom of the chip if the CCD is saturated. We've seen the need for a clear 5 once or twice after a very bright (3 mv) star. If you receive a "camera not responding" or a similar warning when trying to take an exposure, you will need to start a Cold Boot sequence. ... http://www.scyld.com/pipermail/eepro100/2001-July/001769.html For testing purposes, I am running a stock 2.4.6 kernel on a Sony VAIO Z600 NE notebook (Sony Z505 JS in the US). On a cold boot, I get this information in dmesg:
eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin
and others PCI: Found IRQ 9 for device 00:0b.0 eth0: OEM i82557/i82558 10/100 Ethernet, 08:00:46:07:49:99, IRQ 9. Receiver lock-up bug exists -- enabling work-around. Board assembly 100001-001, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x04f4518b). Receiver lock-up workaround activated.
With the exact same kernel, after a warm boot ('reboot'), the picture changes to
eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin
and others PCI: Found IRQ 9 for device 00:0b.0 eth0: Invalid EEPROM checksum 0xff00, check settings before activating this device! eth0: OEM i82557/i82558 10/100 Ethernet, FF:FF:FF:FF:FF:FF, IRQ 9. Board assembly ffffff-255, Physical connectors present: RJ45 BNC AUI MII Primary interface chip unknown-15 PHY #31. Secondary interface chip i82555. Self test failed, status ffffffff: Failure to initialize the i82557. Verify that the card is a bus-master capable slot.
Result: The network essentially is dead; I cannot make HTTP requests to a server on the LAN, for instance. Shut down the system and go through a cold boot ('halt -p'), and all is well. Cold booting into 2.4.6 and then warm booting into a stock 2.2.19 kernel (on a different partition) shows the same effect on the 2.2.19 side in dmesg plus a couple of lines eepro100: cmd_wait for(0xffffffff) timedout with(0xffffffff)! The very same hardware configuration works perfectly with the 2.2.19 kernel across warm boots. ... http://lists.freebsd.org/pipermail/freebsd-current/2004-February/020678.html I am running a 5.2-CURRENT with a fresh kernel and world (cvsupped ~2 hours ago) on a Toshiba Satellite 5200-903. To install and run FreeBSD on that machine I use the known workaround hw.pci.enable_io_modes=0 in /boot/device.hints. Otherwise it hangs when probing agp0. After a cold boot the notebook works fine. But on a warm boot (e.g. shutdown -r now) the kernel hangs after ata0: [...] atapci0: <Intel ICH3 UDMA100 controller> ... ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] The error is reproducable... ... http://www.911cd.net/forums/index.php?showtopic=11213&st=20 1) If you switch it on with the USB key in it, it won't boot from it 2) If you reset it, (warm boot) it will 3) Sometimes the key must be removed AFTER the Ctrl+Alt+Del and BEFORE BIOS starts detecting hardware 4) Once every 10 times it won't boot, and after a Ctrl+Alt+Del it will ... And I know you'll *really* appreciate this one! (he says ducking...) http://support.microsoft.com/default.aspx?scid=kb;en-us;Q102228 SUMMARY When troubleshooting hardware issues, using the power on/off switch yields the most consistent testing procedure. If you suspect a hardware problem, particularly an adapter card problem, using the power switch, rather than the CTRL+ALT+DEL key combination or the Reset button, is recommended. MORE INFORMATION A warm boot, accomplished by pressing the CTRL+ALT+DEL key combination, restarts the computer through the INT19h ROM BIOS routine. This warm-boot procedure usually does not go through the complete boot process; generally, it skips the power-on self test (POST) to save time. In addition, a warm boot frequently fails to reset all adapters in the computer's adapter slots. If you use the Reset button to cold boot the computer, it generally restarts the boot process, including the POST. However, this procedure does not necessarily discontinue power to the motherboard. If the power is not interrupted, the cold boot may fail to reset all adapters in the computer's adapter slots. To ensure that all adapters are properly reset, you should use the power switch to turn the computer off. Leaving the power off for ten seconds ensures that all the capacitors on the motherboard have time to discharge and should also give the hard disk drive a chance to stop spinning. NOTE: Using other reboot methods, such as CTRL+ALT+DEL or the Reset button, is acceptable when a hardware problem is not suspected. ... http://64.233.161.104/search?q=cache:rzSTjKU7jvMJ:www.nps.gov/gis/gps/gps4gi.... +cold-boot&hl=en ->Trimble Navigation GeoExplorer Techical Information Page, Title "Warm Boot or Cold Boot a Data Collector Summary "This TIP presents a table of warm and cold boot procedures for seven Trimble mapping and GIS data collectors, followed by comments on when to use each procedure. ... http://ironbark.bendigo.latrobe.edu.au/subjects/CT/2005/L17/lecture.html Warm Boot vs Cold Boot The boot sequence used when a PC is first powered on (after being completely powered off) is known as a cold boot. This causes all system checks to be performed. When a machine is rebooted, either by pressing the reset switch, telling the operating system to reboot the machine or by pressing CTRL+ALT+DEL a warm boot is performed. In this case less time is spent testing system components as it is assumed that the system has already been running, the full POST has previously been performed and the hardware is already functional. ... https://www.redhat.com/archives/redhat-list/2004-February/msg00736.html I'm really still of the view that the card is left in an unstable command state upon re-booting the server. A cold boot will reset the PCI bus, hence the cards, whereas a warm boot does not. I really feel this is the problem.
On Monday 08 August 2005 11:01 pm, Randall R Schulz wrote:
Stan,
Aside from personal experience from years of hardware/software compatibility testing?
Yes, aside from that. Because this sounds an awful lot like superstition, so I'm looking for some hard facts and documented empirical data, not just assumptions and anecdotes. Absent such facts, I'm rather doubtful that this effect is real. Sorry, forgot to google first and supply the facts.
And using phrases like "Can you say blah-blah-blah," does not get high marks with me. If your hardware exceeds SCSI specs, then powering down won't bring it into spec. I forgot to add the "this isn't meant as a personal slight, just a
colloquialism" tag to the "Can you say", sorry.
In testing to verify whether our SCSI was in spec or not we went through a ton of tests and our SCSI expert had to know that everything started at 0. He did as much of his SCSI coding in assembler as was possible. Speed demon. Never said powering down brought anything into spec. What it did was level the playing field to the least common denominator so he had a reference point to measure what was or wasn't in spec. I see others did do some googling on this phenomenon and came up with real evidence...
...
Stan
Randall Schulz
P.S. Your "Reply-To" header is badly munged. Thanks, is it better now?
Stan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Randall R Schulz schrieb:
Hans,
On Monday 08 August 2005 16:13, Hans Ophüls wrote:
...,
it is well-known by sysadmins that there are problems with kernel updates. It seems that the first reboot without power-off may cause sometimes problems. We had Kernel panic after some days, after such a update without power-off (Suse 9.1).
Could I get some references on this "well-known" phenomenon?
As hardware is programmed and from one kernel-version to the ext there may be different parameters for register programming that may cause this side-effect. Once I had problems with dual boot and nvidia kernel-driver (strange side effects when booting to windows from linux without power off). My experience tells me that there is normally no problem with this - except with broken hardware or malfunctioning firmware on absolutely non-defect hardware (e.g. with some older adaptec scsi cards). I normally noticed this effect very seldom. Regards Philippe - -- Diese Nachricht ist digital signiert und enthält weder Siegel noch Unterschrift! Die unaufgeforderte Zusendung einer Werbemail an Privatleute verstößt gegen §1 UWG und 823 I BGB (Beschluß des LG Berlin vom 2.8.1998 Az: 16 O 201/98). Jede kommerzielle Nutzung der übermittelten persönlichen Daten sowie deren Weitergabe an Dritte ist ausdrücklich untersagt! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQD1AwUBQvhpL0Ng1DRVIGjBAQKaWQb9Fr+ijE6E3lJuE9dYieRrn8ge9Yc3dv7+ iRiDL+N5JO6LAvsMPeEe85H6gvvcMXnb+XumgmgiitwqAqsc0puttM5dLdjwVlbL Fdyr60FciTKpoQVFdHmVNu24hjHbFNmFb+S9jPhok1NTMdnwkCIJwTAJOqavCyJU HVKtDVCeXjg+NZBksOlowPDhKXNjmFHzMuCwvoRyD5t+Z1vf74XPjheFWyG6fwzJ pbAkWcd9z1l71KIB4j+ij5Fmmfss2QmXUxyJJJMaah/I8p3BtLYSCBDJ//bb5vaG AxiUgSeeb6s= =nQ9T -----END PGP SIGNATURE-----
Am Montag, 8. August 2005 17:49 schrieb Ludwig Nussel:
(...). This is the first and only report about a problem with the 9.2 update that I am aware of so it could be a problem with your hardware.
Many thanks for this information. You have convinced me that it was a hardware error (IMHO sporadic memory problems because memtest86 shows no error). Google tells me similar conclusions.
Please try to reproduce the problem with an untainted kernel (ie without use of the nvidia binary driver). Our kernel developers can't debug tainted kernels.
I have just reinstalled the update. Let us see what happens. I will try an untainted kernel if I notice the problem again. Gruß, Jan -- The trouble with the rat race is that even if you win, you're still a rat.
participants (7)
-
Carl E. Hartung
-
Hans Ophüls
-
Jan Ritzerfeld
-
Ludwig Nussel
-
Philippe Vogel
-
Randall R Schulz
-
Stan Glasoe