4.19.21: perf does not work on Ryzen, OK with 4.19.20
The same .config, BIOS, and kernel boot parameters in both kernels. # perf top -v ┌─Error:┐ │Failed to mmap with 12 (Cannot allocate memory)│ mmap size 528384B [0.015080] smpboot: CPU0: AMD Ryzen 5 1600X Six-Core Processor (family: 0x17, model: 0x1, stepping: 0x1) [0.020092] Performance Events: Fam17h core perfctr, AMD PMU driver. [0.020167] ... version:0 [0.020226] ... bit width: 48 [0.020284] ... generic registers: 6 [0.020342] ... value mask: [0.020404] ... max period: 7fff [0.020465] ... fixed-purpose events: 0 [0.020522] ... event mask: 003f [1.307185] AMD-Vi: Found IOMMU at :00:00.2 cap 0x40 [1.307248] AMD-Vi: Extended features (0xf77ef22294ada): [1.307309] PPR NX GT IA GA PC GA_vAPIC [1.307479] AMD-Vi: Lazy IO/TLB flushing enabled [1.308686] amd_uncore: AMD NB counters detected [1.308750] amd_uncore: AMD LLC counters detected [1.309133] perf/amd_iommu: Detected AMD IOMMU #0 (2 banks, 4 counters/bank). MemTotal: 32915748 kB MemFree: 7423584 kB MemAvailable: 30061500 kB Buffers:1300 kB Cached: 22917432 kB SwapCached:0 kB Active: 7432916 kB Inactive: 17190244 kB Active(anon):1706056 kB Inactive(anon): 266040 kB Active(file):5726860 kB Inactive(file): 16924204 kB Unevictable: 32 kB Mlocked: 32 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 140 kB Writeback: 0 kB AnonPages: 1704432 kB Mapped: 668832 kB Shmem:271724 kB Slab: 612960 kB SReclaimable: 448016 kB SUnreclaim: 164944 kB KernelStack: 14976 kB PageTables:55184 kB NFS_Unstable: 0 kB Bounce:0 kB WritebackTmp: 0 kB CommitLimit:16457872 kB Committed_AS:8749324 kB VmallocTotal: 34359738367 kB VmallocUsed: 0 kB VmallocChunk: 0 kB Percpu:10944 kB HardwareCorrupted: 0 kB AnonHugePages:608256 kB ShmemHugePages:0 kB ShmemPmdMapped:0 kB HugePages_Total: 0 HugePages_Free:0 HugePages_Rsvd:0 HugePages_Surp:0 Hugepagesize: 2048 kB Hugetlb: 0 kB DirectMap4k: 1221876 kB DirectMap2M:27021312 kB DirectMap1G: 6291456 kB -- Do what you love because life is too short for anything else. https://samifar.in/
[BUG] 4.9.9 shrink_slab prune_icache_sb crash
4.4 kernel had working [non-crashing] shrink_slab and friends... x86_64 arch , Core i5 2500K, 16 GiB. kernel: BUG: unable to handle kernel paging request at 00020157 kernel: IP: [] __lock_acquire.isra.15+0x39a/0x930 kernel: PGD 0 kernel: kernel: Oops: [#1] PREEMPT SMP kernel: Modules linked in: ip6t_REJECT nf_reject_ipv6 tun nfnetlink_queue nfnetlink_log snd_seq_dummy nls_utf8 nls_iso8859_1 nls_cp437 vfat fat uas usb_storage sctp_diag sctp dccp_diag dccp tcp_cdg tcp_cubic fuse nf_conntrack_netlink nfnetlink_acct ip6table_mangle nf_log_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6t_rt ip6table_filter ip6_tables ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat iptable_raw xt_mark xt_connmark iptable_mangle ipt_REJECT nf_reject_ipv4 nf_log_ipv4 nf_log_common xt_LOG xt_length xt_limit xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_connlimit xt_owner xt_hashlimit xt_multiport xt_conntrack nf_conntrack xt_set iptable_filter ip_set_hash_net ip_set nfnetlink cls_fw sch_pie sch_htb arptable_filter arp_tables cfg80211 w83627ehf hwmon_vid coretemp hwmon kernel: kvm_intel iTCO_wdt iTCO_vendor_support btusb kvm btrtl btbcm mxm_wmi btintel bluetooth irqbypass rfkill snd_hda_codec_hdmi i2c_i801 snd_hda_codec_realtek i2c_smbus snd_hda_codec_generic lpc_ich snd_hda_intel snd_hda_codec snd_hda_core battery rtc_cmos acpi_cpufreq sch_fq_codel tcp_bbr binfmt_misc snd_pcm_oss snd_seq snd_seq_device snd_pcm snd_timer ip_tables x_tables algif_skcipher af_alg usbhid r8169 mii xhci_pci xhci_hcd i915 e1000e ehci_pci ptp ehci_hcd usbcore pps_core usb_common video fjes wmi button 8021q mrp scsi_transport_iscsi sunrpc snd_mixer_oss snd soundcore analog gameport joydev i2c_dev ecryptfs autofs4 [last unloaded: pcspkr] kernel: CPU: 3 PID: 6444 Comm: pulseaudio Not tainted 4.9.9+ #88 kernel: Hardware name: System manufacturer System Product Name/P8Z68-V PRO GEN3, BIOS 3402 05/07/2012 kernel: task: 9319c2526900 task.stack: b31700eac000 kernel: RIP: 0010:[] [] __lock_acquire.isra.15+0x39a/0x930 kernel: RSP: :b31700eaf4e8 EFLAGS: 00010097 kernel: RAX: RBX: RCX: kernel: RDX: RSI: RDI: 0002014f kernel: RBP: b31700eaf528 R08: R09: kernel: R10: R11: 0001 R12: 0002014f kernel: R13: 9319c2526900 R14: R15: kernel: FS: 7f320f39f940() GS:931a1f18() knlGS: kernel: CS: 0010 DS: ES: CR0: 80050033 kernel: CR2: 00020157 CR3: 0003c27c7000 CR4: 000406e0 kernel: Stack: kernel: b31700eaf558 0286 0282 kernel: kernel: b31700eaf590 9510ae16 95244efa kernel: Call Trace: kernel: [] lock_acquire+0xd6/0x180 kernel: [] ? remove_inode_buffers+0x3a/0x90 kernel: [] _raw_spin_lock+0x33/0x50 kernel: [] ? remove_inode_buffers+0x3a/0x90 kernel: [] remove_inode_buffers+0x3a/0x90 kernel: [] inode_lru_isolate+0xde/0x1b0 kernel: [] __list_lru_walk_one.isra.2+0x99/0x160 kernel: [] ? iput+0x290/0x290 kernel: [] list_lru_walk_one+0x1e/0x20 kernel: [] prune_icache_sb+0x3b/0x60 kernel: [] super_cache_scan+0x149/0x1a0 kernel: [] shrink_slab.part.15+0x22e/0x4b0 kernel: [] shrink_slab+0x2f/0x40 kernel: [] shrink_node+0xeb/0x2e0 kernel: [] do_try_to_free_pages+0xc7/0x2d0 kernel: [] try_to_free_pages+0xce/0x210 kernel: [] __alloc_pages_nodemask+0x59f/0xde0 kernel: [] ? expand_files+0x1e0/0x1e0 kernel: [] __get_free_pages+0x12/0x40 kernel: [] __pollwait+0x94/0xe0 kernel: [] snd_ctl_poll+0x34/0x60 [snd] kernel: [] do_sys_poll+0x26e/0x520 kernel: [] ? check_preempt_wakeup+0x144/0x240 kernel: [] ? poll_initwait+0x40/0x40 kernel: [] ? poll_select_copy_remaining+0x120/0x120 kernel: message repeated 8 times: [ [] ? poll_select_copy_remaining+0x120/0x120] kernel: [] SyS_ppoll+0x163/0x190 kernel: [] ? lockdep_sys_exit_thunk+0x16/0x18 kernel: [] entry_SYSCALL_64_fastpath+0x1a/0xae kernel: Code: 8b 3c 25 00 d4 00 00 e8 75 f7 ff ff e8 b0 f9 ff ff e8 f8 8c 35 00 31 db 48 83 c4 18 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 89 f0 <49> 8b 44 c4 08 48 85 c0 0f 85 c9 fc ff ff e9 9b fc ff ff e8 3e kernel: RIP [] __lock_acquire.isra.15+0x39a/0x930 kernel: RSP kernel: CR2: 00020157 kernel: ---[ end trace b8fb7bade0b2bc45 ]--- kernel: note: pulseaudio[6444] exited with preempt_count 1 kernel: kernel tried to execute NX-protected page - exploit attempt? (uid: 500) kernel: BUG: unable to handle kernel paging request at b31700eafd68 kernel: IP: [] 0xb31700eafd68 kernel: PGD 40cc39067 kernel: PUD 40cc3c067 kernel: PMD 40c5c6067 kernel: PTE 8003c27c6163 kernel: kernel: Oops: 0011 [#2] PREEMPT SMP kernel: Modules linked in: ip6t_REJECT nf_reject_ipv6 tun nfnetlink_queue nfnetlink_log
[BUG] 4.9.9 shrink_slab prune_icache_sb crash
4.4 kernel had working [non-crashing] shrink_slab and friends... x86_64 arch , Core i5 2500K, 16 GiB. kernel: BUG: unable to handle kernel paging request at 00020157 kernel: IP: [] __lock_acquire.isra.15+0x39a/0x930 kernel: PGD 0 kernel: kernel: Oops: [#1] PREEMPT SMP kernel: Modules linked in: ip6t_REJECT nf_reject_ipv6 tun nfnetlink_queue nfnetlink_log snd_seq_dummy nls_utf8 nls_iso8859_1 nls_cp437 vfat fat uas usb_storage sctp_diag sctp dccp_diag dccp tcp_cdg tcp_cubic fuse nf_conntrack_netlink nfnetlink_acct ip6table_mangle nf_log_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6t_rt ip6table_filter ip6_tables ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat iptable_raw xt_mark xt_connmark iptable_mangle ipt_REJECT nf_reject_ipv4 nf_log_ipv4 nf_log_common xt_LOG xt_length xt_limit xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_connlimit xt_owner xt_hashlimit xt_multiport xt_conntrack nf_conntrack xt_set iptable_filter ip_set_hash_net ip_set nfnetlink cls_fw sch_pie sch_htb arptable_filter arp_tables cfg80211 w83627ehf hwmon_vid coretemp hwmon kernel: kvm_intel iTCO_wdt iTCO_vendor_support btusb kvm btrtl btbcm mxm_wmi btintel bluetooth irqbypass rfkill snd_hda_codec_hdmi i2c_i801 snd_hda_codec_realtek i2c_smbus snd_hda_codec_generic lpc_ich snd_hda_intel snd_hda_codec snd_hda_core battery rtc_cmos acpi_cpufreq sch_fq_codel tcp_bbr binfmt_misc snd_pcm_oss snd_seq snd_seq_device snd_pcm snd_timer ip_tables x_tables algif_skcipher af_alg usbhid r8169 mii xhci_pci xhci_hcd i915 e1000e ehci_pci ptp ehci_hcd usbcore pps_core usb_common video fjes wmi button 8021q mrp scsi_transport_iscsi sunrpc snd_mixer_oss snd soundcore analog gameport joydev i2c_dev ecryptfs autofs4 [last unloaded: pcspkr] kernel: CPU: 3 PID: 6444 Comm: pulseaudio Not tainted 4.9.9+ #88 kernel: Hardware name: System manufacturer System Product Name/P8Z68-V PRO GEN3, BIOS 3402 05/07/2012 kernel: task: 9319c2526900 task.stack: b31700eac000 kernel: RIP: 0010:[] [] __lock_acquire.isra.15+0x39a/0x930 kernel: RSP: :b31700eaf4e8 EFLAGS: 00010097 kernel: RAX: RBX: RCX: kernel: RDX: RSI: RDI: 0002014f kernel: RBP: b31700eaf528 R08: R09: kernel: R10: R11: 0001 R12: 0002014f kernel: R13: 9319c2526900 R14: R15: kernel: FS: 7f320f39f940() GS:931a1f18() knlGS: kernel: CS: 0010 DS: ES: CR0: 80050033 kernel: CR2: 00020157 CR3: 0003c27c7000 CR4: 000406e0 kernel: Stack: kernel: b31700eaf558 0286 0282 kernel: kernel: b31700eaf590 9510ae16 95244efa kernel: Call Trace: kernel: [] lock_acquire+0xd6/0x180 kernel: [] ? remove_inode_buffers+0x3a/0x90 kernel: [] _raw_spin_lock+0x33/0x50 kernel: [] ? remove_inode_buffers+0x3a/0x90 kernel: [] remove_inode_buffers+0x3a/0x90 kernel: [] inode_lru_isolate+0xde/0x1b0 kernel: [] __list_lru_walk_one.isra.2+0x99/0x160 kernel: [] ? iput+0x290/0x290 kernel: [] list_lru_walk_one+0x1e/0x20 kernel: [] prune_icache_sb+0x3b/0x60 kernel: [] super_cache_scan+0x149/0x1a0 kernel: [] shrink_slab.part.15+0x22e/0x4b0 kernel: [] shrink_slab+0x2f/0x40 kernel: [] shrink_node+0xeb/0x2e0 kernel: [] do_try_to_free_pages+0xc7/0x2d0 kernel: [] try_to_free_pages+0xce/0x210 kernel: [] __alloc_pages_nodemask+0x59f/0xde0 kernel: [] ? expand_files+0x1e0/0x1e0 kernel: [] __get_free_pages+0x12/0x40 kernel: [] __pollwait+0x94/0xe0 kernel: [] snd_ctl_poll+0x34/0x60 [snd] kernel: [] do_sys_poll+0x26e/0x520 kernel: [] ? check_preempt_wakeup+0x144/0x240 kernel: [] ? poll_initwait+0x40/0x40 kernel: [] ? poll_select_copy_remaining+0x120/0x120 kernel: message repeated 8 times: [ [] ? poll_select_copy_remaining+0x120/0x120] kernel: [] SyS_ppoll+0x163/0x190 kernel: [] ? lockdep_sys_exit_thunk+0x16/0x18 kernel: [] entry_SYSCALL_64_fastpath+0x1a/0xae kernel: Code: 8b 3c 25 00 d4 00 00 e8 75 f7 ff ff e8 b0 f9 ff ff e8 f8 8c 35 00 31 db 48 83 c4 18 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 89 f0 <49> 8b 44 c4 08 48 85 c0 0f 85 c9 fc ff ff e9 9b fc ff ff e8 3e kernel: RIP [] __lock_acquire.isra.15+0x39a/0x930 kernel: RSP kernel: CR2: 00020157 kernel: ---[ end trace b8fb7bade0b2bc45 ]--- kernel: note: pulseaudio[6444] exited with preempt_count 1 kernel: kernel tried to execute NX-protected page - exploit attempt? (uid: 500) kernel: BUG: unable to handle kernel paging request at b31700eafd68 kernel: IP: [] 0xb31700eafd68 kernel: PGD 40cc39067 kernel: PUD 40cc3c067 kernel: PMD 40c5c6067 kernel: PTE 8003c27c6163 kernel: kernel: Oops: 0011 [#2] PREEMPT SMP kernel: Modules linked in: ip6t_REJECT nf_reject_ipv6 tun nfnetlink_queue nfnetlink_log
Re: [BUG] How to crash 4.9.2 x86_64: vmscan: shrink_slab
On Tue, Jan 10, 2017 at 10:22:41 +0100, Michal Hocko wrote: > On Mon 09-01-17 23:02:10, Sami Farin wrote: > > # sysctl vm.vfs_cache_pressure=-100 > > > > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to > > delete nr=-6640827866535449472 > > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to > > delete nr=-6640827866535450112 ... > > > > > > Alternatively, > > # sysctl vm.vfs_cache_pressure=1000 > > Both values are insane and admins do not do insane things to their > machines, do they? Not on purpose, unless they are insane :) Docs say: "Increasing vfs_cache_pressure significantly beyond 100 may have negative performance impact." Nothing about crashing. But anyways, the problem I originally had was: with vm.vfs_cache_pressure=0 , dentry/inode caches are reclaimed at a very alarming rate, and when I e.g. rescan quodlibet media directory (only 3 files), that takes a lot of time.. I only download some files for a minute and dentry/inode caches are reclaimed, or so it seems. Still, SReclaimable keeps on increasing, when it gets to about 6 GB , I increase vm.vfs_cache_pressure -- Do what you love because life is too short for anything else. https://samifar.in/
Re: [BUG] How to crash 4.9.2 x86_64: vmscan: shrink_slab
On Tue, Jan 10, 2017 at 10:22:41 +0100, Michal Hocko wrote: > On Mon 09-01-17 23:02:10, Sami Farin wrote: > > # sysctl vm.vfs_cache_pressure=-100 > > > > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to > > delete nr=-6640827866535449472 > > kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to > > delete nr=-6640827866535450112 ... > > > > > > Alternatively, > > # sysctl vm.vfs_cache_pressure=1000 > > Both values are insane and admins do not do insane things to their > machines, do they? Not on purpose, unless they are insane :) Docs say: "Increasing vfs_cache_pressure significantly beyond 100 may have negative performance impact." Nothing about crashing. But anyways, the problem I originally had was: with vm.vfs_cache_pressure=0 , dentry/inode caches are reclaimed at a very alarming rate, and when I e.g. rescan quodlibet media directory (only 3 files), that takes a lot of time.. I only download some files for a minute and dentry/inode caches are reclaimed, or so it seems. Still, SReclaimable keeps on increasing, when it gets to about 6 GB , I increase vm.vfs_cache_pressure -- Do what you love because life is too short for anything else. https://samifar.in/
[BUG] How to crash 4.9.2 x86_64: vmscan: shrink_slab
# sysctl vm.vfs_cache_pressure=-100 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-6640827866535449472 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-6640827866535450112 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-661702561611775889 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-6640827866535442432 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-6562613194205300197 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-6640827866535439872 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-659655090764208789 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-6564660665198832072 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-6562613194351275164 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-6562615996648922728 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-6564660665198832072 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-6562613194351264981 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-569296135781119076 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-565206492037048430 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-565212096665106188 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-569296135781119076 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-565206492037043196 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-659660388715270673 Alternatively, # sysctl vm.vfs_cache_pressure=1000 < allocate 6 GB of RAM on 16 GB system > < start google-chrome-stable > infinite loop in khugepaged → super_cache_scan (this was with 4.9.1) kernel: sysrq: SysRq : Show Regs kernel: CPU: 2 PID: 353 Comm: khugepaged Tainted: GW 4.9.1+ #79 kernel: Hardware name: System manufacturer System Product Name/P8Z68-V PRO GEN3, BIOS 3402 05/07/2012 kernel: task: a2e8cc7d9500 task.stack: abe040858000 kernel: RIP: 0010:[] [] lock_acquire+0xee/0x180 kernel: RSP: 0018:abe04085b860 EFLAGS: 0286 kernel: RAX: a2e8cc7d9500 RBX: 0286 RCX: d1055b5d kernel: RDX: 1113d196 RSI: 03e5c7cd RDI: 0286 kernel: RBP: abe04085b8b8 R08: R09: kernel: R10: 32ec60fe R11: 0001 R12: kernel: R13: R14: R15: kernel: FS: () GS:a2e8df10() knlGS: kernel: CS: 0010 DS: ES: CR0: 80050033 kernel: CR2: 371ebec2e004 CR3: 0004033fb000 CR4: 000406e0 kernel: Stack: kernel: a21c88ed a2e8 0286 kernel: 00017ae9f878 a2e87af7de98 a2e87af7de80 kernel: abe04085b9f8 abe04085b8d8 kernel: Call Trace: kernel: [] ? __list_lru_count_one.isra.0+0x1d/0x80 kernel: [] _raw_spin_lock+0x33/0x50 kernel: [] ? __list_lru_count_one.isra.0+0x1d/0x80 kernel: [] __list_lru_count_one.isra.0+0x1d/0x80 kernel: [] list_lru_count_one+0x1e/0x20 kernel: [] super_cache_scan+0xa1/0x1a0 kernel: [] shrink_slab.part.15+0x22e/0x4b0 kernel: [] shrink_slab+0x2f/0x40 kernel: [] shrink_node+0xeb/0x2e0 kernel: [] do_try_to_free_pages+0xc7/0x2d0 kernel: [] try_to_free_pages+0xce/0x210 kernel: [] __alloc_pages_nodemask+0x538/0xd60 kernel: [] khugepaged+0x3a3/0x24a0 kernel: [] ? wake_atomic_t_function+0x50/0x50 kernel: [] ? collapse_shmem.isra.8+0xb00/0xb00 kernel: [] kthread+0xe0/0x100 kernel: [] ? kthread_park+0x60/0x60 kernel: [] ret_from_fork+0x25/0x30 kernel: Code: 04 24 48 8b 7d d0 49 83 f0 01 41 83 e0 01 e8 aa f2 ff ff 48 89 df 65 48 8b 04 25 00 d4 00 00 c7 80 0c 07 00 00 00 00 00 00 57 9d <66> 66 90 66 90 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 65 -- Do what you love because life is too short for anything else. https://samifar.in/
[BUG] How to crash 4.9.2 x86_64: vmscan: shrink_slab
# sysctl vm.vfs_cache_pressure=-100 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-6640827866535449472 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-6640827866535450112 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-661702561611775889 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-6640827866535442432 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-6562613194205300197 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-6640827866535439872 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-659655090764208789 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-6564660665198832072 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-6562613194351275164 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-6562615996648922728 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-6564660665198832072 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-6562613194351264981 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-569296135781119076 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-565206492037048430 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-565212096665106188 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-569296135781119076 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-565206492037043196 kernel: vmscan: shrink_slab: super_cache_scan+0x0/0x1a0 negative objects to delete nr=-659660388715270673 Alternatively, # sysctl vm.vfs_cache_pressure=1000 < allocate 6 GB of RAM on 16 GB system > < start google-chrome-stable > infinite loop in khugepaged → super_cache_scan (this was with 4.9.1) kernel: sysrq: SysRq : Show Regs kernel: CPU: 2 PID: 353 Comm: khugepaged Tainted: GW 4.9.1+ #79 kernel: Hardware name: System manufacturer System Product Name/P8Z68-V PRO GEN3, BIOS 3402 05/07/2012 kernel: task: a2e8cc7d9500 task.stack: abe040858000 kernel: RIP: 0010:[] [] lock_acquire+0xee/0x180 kernel: RSP: 0018:abe04085b860 EFLAGS: 0286 kernel: RAX: a2e8cc7d9500 RBX: 0286 RCX: d1055b5d kernel: RDX: 1113d196 RSI: 03e5c7cd RDI: 0286 kernel: RBP: abe04085b8b8 R08: R09: kernel: R10: 32ec60fe R11: 0001 R12: kernel: R13: R14: R15: kernel: FS: () GS:a2e8df10() knlGS: kernel: CS: 0010 DS: ES: CR0: 80050033 kernel: CR2: 371ebec2e004 CR3: 0004033fb000 CR4: 000406e0 kernel: Stack: kernel: a21c88ed a2e8 0286 kernel: 00017ae9f878 a2e87af7de98 a2e87af7de80 kernel: abe04085b9f8 abe04085b8d8 kernel: Call Trace: kernel: [] ? __list_lru_count_one.isra.0+0x1d/0x80 kernel: [] _raw_spin_lock+0x33/0x50 kernel: [] ? __list_lru_count_one.isra.0+0x1d/0x80 kernel: [] __list_lru_count_one.isra.0+0x1d/0x80 kernel: [] list_lru_count_one+0x1e/0x20 kernel: [] super_cache_scan+0xa1/0x1a0 kernel: [] shrink_slab.part.15+0x22e/0x4b0 kernel: [] shrink_slab+0x2f/0x40 kernel: [] shrink_node+0xeb/0x2e0 kernel: [] do_try_to_free_pages+0xc7/0x2d0 kernel: [] try_to_free_pages+0xce/0x210 kernel: [] __alloc_pages_nodemask+0x538/0xd60 kernel: [] khugepaged+0x3a3/0x24a0 kernel: [] ? wake_atomic_t_function+0x50/0x50 kernel: [] ? collapse_shmem.isra.8+0xb00/0xb00 kernel: [] kthread+0xe0/0x100 kernel: [] ? kthread_park+0x60/0x60 kernel: [] ret_from_fork+0x25/0x30 kernel: Code: 04 24 48 8b 7d d0 49 83 f0 01 41 83 e0 01 e8 aa f2 ff ff 48 89 df 65 48 8b 04 25 00 d4 00 00 c7 80 0c 07 00 00 00 00 00 00 57 9d <66> 66 90 66 90 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 65 -- Do what you love because life is too short for anything else. https://samifar.in/
drivers/char/random.c:write_pool() -- cond_resched needed?
In write_pool(), isn't cond_resched() needed after call to add_entropy_words() because otherwise there can be large latencies (think of command "dd if=/dev/zero of=/dev/random bs=1" ) ? -- Do what you love because life is too short for anything else. - 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/
drivers/char/random.c:write_pool() -- cond_resched needed?
In write_pool(), isn't cond_resched() needed after call to add_entropy_words() because otherwise there can be large latencies (think of command dd if=/dev/zero of=/dev/random bs=1 ) ? -- Do what you love because life is too short for anything else. - 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 Tue, Nov 20, 2007 at 13:52:52 +0100, Alessandro Suardi wrote: > 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. -m32: 2.7.2.3: /tmp/cc1EO0wg.s:14: Error: suffix or operands invalid for `push' 2.95.3: OK 3.0.4: broken 3.1.1: broken 3.2.3: broken 3.3.5: broken 3.4.6: broken 4.0.3: broken -m32 and -m64: gcc Red Hat 4.1.2-33: broken 4.2.2 20070909 (prerelease): broken -- Do what you love because life is too short for anything else. - 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 Tue, Nov 20, 2007 at 13:52:52 +0100, Alessandro Suardi wrote: 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. -m32: 2.7.2.3: /tmp/cc1EO0wg.s:14: Error: suffix or operands invalid for `push' 2.95.3: OK 3.0.4: broken 3.1.1: broken 3.2.3: broken 3.3.5: broken 3.4.6: broken 4.0.3: broken -m32 and -m64: gcc Red Hat 4.1.2-33: broken 4.2.2 20070909 (prerelease): broken -- Do what you love because life is too short for anything else. - 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: kernel 2.6.23: what IS the VM doing?
On Fri, Sep 14, 2007 at 20:17:46 +0300, Sami Farin wrote: > On Wed, Sep 05, 2007 at 18:48:51 -0400, Rik van Riel wrote: > > Sami Farin wrote: > >> On Wed, Sep 05, 2007 at 12:24:26 -0400, Rik van Riel wrote: > >> ... > >>>> *shrug* > >>> The attached patch should make sure kswapd does not free an > >>> excessive number of pages in zone_normal just because the > >>> pages in zone_highmem are difficult to free. > >>> > >>> It does give kswapd a large margin to continue putting equal > >>> pressure on all zones in normal situations. > >>> > >>> Sami, could you try out this patch to see if it helps your > >>> situation? > >> > >> Thanks, Rik. bzImage is ready, I probably reboot inside one > >> month for a reason or other 8-) > > > > The more I look at the bug, the more I see that it is probably > > not very easy to reproduce on demand. I have, however, a full > > Well, I now booted to x86_64 kernel. > > I can still reproduce this. > When I unload ipset modules, kernel resumes "normal" operation, i.e., > not swapping like mad. I now have 2GB of extra RAM, so 3GB in total, on x86_64 system. If ipset tries to allocate 512 KB or more, kernel goes into swapping frenzy, of which system does not recover in over 30 minutes unless I press sysrq+k. some kernel settings...: vm.dirty_ratio = 4 vm.dirty_background_ratio = 2 vm.swappiness = 10 vm.vfs_cache_pressure = 10 vm.overcommit_memory = 2 SysRq : Show Blocked State taskPC stack pid father kswapd0 D 0 258 2 8100be333ca0 0046 0286 8100be333c50 8100be560080 807af3c0 0064 0001285af6e6 00ff 802463f8 Call Trace: [] __mod_timer+0xb8/0xd0 [] schedule_timeout+0x63/0xd0 [] process_timeout+0x0/0x10 [] io_schedule_timeout+0x28/0x40 [] congestion_wait+0x8c/0xb0 [] autoremove_wake_function+0x0/0x40 [] throttle_vm_writeout+0x54/0xc0 [] shrink_zone+0xe3/0x140 [] kswapd+0x510/0x5b0 [] autoremove_wake_function+0x0/0x40 [] kswapd+0x0/0x5b0 [] kthread+0x4d/0x80 [] child_rip+0xa/0x12 [] kthread+0x0/0x80 [] child_rip+0x0/0x12 irqbalanceD 00aa7f00 0 2110 1 8100b8c4fcd8 0082 8100a5e57f00 00080076 8100be5f91c0 810060182140 8100b8c4fc88 0282 8100b8c4fcb8 8040e1f6 Call Trace: [] __up_read+0x46/0xb0 [] io_schedule+0x28/0x40 [] sync_page+0x37/0x50 [] __wait_on_bit_lock+0x4e/0x80 [] sync_page+0x0/0x50 [] __lock_page+0x65/0x70 [] wake_bit_function+0x0/0x30 [] handle_mm_fault+0x269/0x870 [] do_page_fault+0x1a4/0x900 [] free_pages_and_swap_cache+0x9e/0xd0 [] unmap_region+0x136/0x150 [] remove_vma+0x5e/0x70 [] __up_write+0xd0/0x130 [] error_exit+0x0/0x84 svscanD 00df7900 0 2438 1 8100b6607cd8 0082 81005f81fd80 00080076 8100bb516180 810060182140 8100b6607c88 0282 8100b6607cb8 8040e1f6 Call Trace: [] __up_read+0x46/0xb0 [] io_schedule+0x28/0x40 [] sync_page+0x37/0x50 [] __wait_on_bit_lock+0x4e/0x80 [] sync_page+0x0/0x50 [] __lock_page+0x65/0x70 [] wake_bit_function+0x0/0x30 [] handle_mm_fault+0x269/0x870 [] xfs_vn_getattr+0x4c/0x140 [] do_page_fault+0x1a4/0x900 [] vfs_getattr+0x60/0x90 [] vfs_fstat+0x45/0x60 [] sys32_fstat64+0x2e/0x40 [] error_exit+0x0/0x84 ... ipset D 0 3713 3574 8100566237a8 0086 810056623748 802335e2 810056623748 0010 8100b085e0c0 810060182140 810056623758 0282 810056623788 8040e1f6 Call Trace: [] enqueue_entity+0x42/0x60 [] __up_read+0x46/0xb0 [] io_schedule+0x28/0x40 [] sync_page+0x37/0x50 [] __wait_on_bit+0x55/0x80 [] sync_page+0x0/0x50 [] wait_on_page_bit+0x6f/0x80 [] wake_bit_function+0x0/0x30 [] shrink_page_list+0x164/0x680 [] del_timer_sync+0x1a/0x30 [] schedule_timeout+0x6b/0xd0 [] process_timeout+0x0/0x10 [] congestion_wait+0x9a/0xb0 [] shrink_inactive_list+0x40a/0x420 [] shrink_zone+0xcf/0x140 [] try_to_free_pages+0x174/0x270 [] __alloc_pages+0x160/0x350 [] printk+0x67/0x70 [] cache_alloc_refill+0x2e3/0x570 [] __kmalloc+0x113/0x120 [] :ip_set_nethash:retry+0x183/0x500 [] :ip_set:__ip_set_addip+0x6f/0x90 [] :ip_set:ip_set_sockfn_get+0x93d/0xd50 [] nf_sockopt+0x142/0x150 [] nf_getsockopt+0xf/0x20 [] ip_getsockopt+0x98/0xc0 [] raw_getsockopt+0x11/0x30 [] sock_common_getsockopt+0xf/0x20 [] sys_getsockopt+0x9c/0xd0 [] tracesys+0xdc/0xe1 SysRq : Show Memory Mem-info: DMA per-cpu: CPU0: Hot: hi:0, btch: 1 usd: 0 Cold: hi:0, bt
Re: kernel 2.6.23: what IS the VM doing?
On Fri, Sep 14, 2007 at 20:17:46 +0300, Sami Farin wrote: On Wed, Sep 05, 2007 at 18:48:51 -0400, Rik van Riel wrote: Sami Farin wrote: On Wed, Sep 05, 2007 at 12:24:26 -0400, Rik van Riel wrote: ... *shrug* The attached patch should make sure kswapd does not free an excessive number of pages in zone_normal just because the pages in zone_highmem are difficult to free. It does give kswapd a large margin to continue putting equal pressure on all zones in normal situations. Sami, could you try out this patch to see if it helps your situation? Thanks, Rik. bzImage is ready, I probably reboot inside one month for a reason or other 8-) The more I look at the bug, the more I see that it is probably not very easy to reproduce on demand. I have, however, a full Well, I now booted to x86_64 kernel. I can still reproduce this. When I unload ipset modules, kernel resumes normal operation, i.e., not swapping like mad. I now have 2GB of extra RAM, so 3GB in total, on x86_64 system. If ipset tries to allocate 512 KB or more, kernel goes into swapping frenzy, of which system does not recover in over 30 minutes unless I press sysrq+k. some kernel settings...: vm.dirty_ratio = 4 vm.dirty_background_ratio = 2 vm.swappiness = 10 vm.vfs_cache_pressure = 10 vm.overcommit_memory = 2 SysRq : Show Blocked State taskPC stack pid father kswapd0 D 0 258 2 8100be333ca0 0046 0286 8100be333c50 8100be560080 807af3c0 0064 0001285af6e6 00ff 802463f8 Call Trace: [802463f8] __mod_timer+0xb8/0xd0 [80657da3] schedule_timeout+0x63/0xd0 [80246120] process_timeout+0x0/0x10 [806576f8] io_schedule_timeout+0x28/0x40 [8027f5fc] congestion_wait+0x8c/0xb0 [802524e0] autoremove_wake_function+0x0/0x40 [80279ad4] throttle_vm_writeout+0x54/0xc0 [8027d6f3] shrink_zone+0xe3/0x140 [8027dea0] kswapd+0x510/0x5b0 [802524e0] autoremove_wake_function+0x0/0x40 [8027d990] kswapd+0x0/0x5b0 [802520dd] kthread+0x4d/0x80 [8020cae8] child_rip+0xa/0x12 [80252090] kthread+0x0/0x80 [8020cade] child_rip+0x0/0x12 irqbalanceD 00aa7f00 0 2110 1 8100b8c4fcd8 0082 8100a5e57f00 00080076 8100be5f91c0 810060182140 8100b8c4fc88 0282 8100b8c4fcb8 8040e1f6 Call Trace: [8040e1f6] __up_read+0x46/0xb0 [806579d8] io_schedule+0x28/0x40 [802736e7] sync_page+0x37/0x50 [80657e9e] __wait_on_bit_lock+0x4e/0x80 [802736b0] sync_page+0x0/0x50 [80273695] __lock_page+0x65/0x70 [80252520] wake_bit_function+0x0/0x30 [80282289] handle_mm_fault+0x269/0x870 [802261b4] do_page_fault+0x1a4/0x900 [8028cafe] free_pages_and_swap_cache+0x9e/0xd0 [80285b86] unmap_region+0x136/0x150 [80285bfe] remove_vma+0x5e/0x70 [8040e330] __up_write+0xd0/0x130 [80659d9d] error_exit+0x0/0x84 svscanD 00df7900 0 2438 1 8100b6607cd8 0082 81005f81fd80 00080076 8100bb516180 810060182140 8100b6607c88 0282 8100b6607cb8 8040e1f6 Call Trace: [8040e1f6] __up_read+0x46/0xb0 [806579d8] io_schedule+0x28/0x40 [802736e7] sync_page+0x37/0x50 [80657e9e] __wait_on_bit_lock+0x4e/0x80 [802736b0] sync_page+0x0/0x50 [80273695] __lock_page+0x65/0x70 [80252520] wake_bit_function+0x0/0x30 [80282289] handle_mm_fault+0x269/0x870 [803acc2c] xfs_vn_getattr+0x4c/0x140 [802261b4] do_page_fault+0x1a4/0x900 [8029cf80] vfs_getattr+0x60/0x90 [8029d515] vfs_fstat+0x45/0x60 [8022b35e] sys32_fstat64+0x2e/0x40 [80659d9d] error_exit+0x0/0x84 ... ipset D 0 3713 3574 8100566237a8 0086 810056623748 802335e2 810056623748 0010 8100b085e0c0 810060182140 810056623758 0282 810056623788 8040e1f6 Call Trace: [802335e2] enqueue_entity+0x42/0x60 [8040e1f6] __up_read+0x46/0xb0 [806579d8] io_schedule+0x28/0x40 [802736e7] sync_page+0x37/0x50 [80657fb5] __wait_on_bit+0x55/0x80 [802736b0] sync_page+0x0/0x50 [802738bf] wait_on_page_bit+0x6f/0x80 [80252520] wake_bit_function+0x0/0x30 [8027ccd4] shrink_page_list+0x164/0x680 [8024632a] del_timer_sync+0x1a/0x30 [80657dab] schedule_timeout+0x6b/0xd0 [80246120] process_timeout+0x0/0x10 [8027f60a] congestion_wait+0x9a/0xb0 [8027d5fa
Re: x86: randomize brk() and RLIMIT_DATA
On Thu, Oct 25, 2007 at 16:46:26 +0200, Jiri Kosina wrote: > On Thu, 25 Oct 2007, Arjan van de Ven wrote: > > > > Would be neat if randomized brk and setrlimit(RLIMIT_DATA, ...) > > > worked in a predictable way: > > this isn't a valid case afaics; even on "traditional x86" (before we > > changed the address space layout, or even today if you have an unlimited > > stack rlimit) this isn't going to work. applications really shouldn't > > use (s)brk() but malloc(); you have to be able to fall back to mmap > > regardless of what you do. > > I tend to agree here with Arjan. However it probably would make no harm to > make at least a little bit consisten behavior of setrlimit(), though it > has a little use in such cases. > > Sami, does the patch below work for you? Thanks, Jiri, now RLIMIT_DATA works as expected. Using only RLIMIT_AS to limit processes' memory usage is not very easy. It includes also libraries mapped read-only, I have to check/modify the limits when I update/add libraries,... Amazingly, I found a patch which seems to be just what I need: http://marc.info/?l=linux-mm=118402827803338=4 Seems like that is not going to -mm or mainstream... -- Do what you love because life is too short for anything else. - 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/
x86: randomize brk() and RLIMIT_DATA
Would be neat if randomized brk and setrlimit(RLIMIT_DATA, ...)
worked in a predictable way:
$ gcc brk.c -fPIC -pie -m64;./a.out;./a.out;./a.out
sbrk=0x7f721b815000 main=0x7f721af04860
sbrk succeeded (brk=0x7f721b909240)
sbrk=0x7fc3d77e2000 main=0x7fc3d66fa860
sbrk failed: Cannot allocate memory (brk=0x7fc3d77e2000)
sbrk=0x7f05b0615000 main=0x7f05af76b860
sbrk failed: Cannot allocate memory (brk=0x7f05b0615000)
--
Do what you love because life is too short for anything else.
#include
#include
#include
#include
#include
#include
int main(void)
{
void *p;
const struct rlimit rlim_data = {
.rlim_cur = 10 << 20,
.rlim_max = RLIM_INFINITY
};
int saved_errno;
p = sbrk(0);
fprintf(stderr, "sbrk=%p main=%p\n", p, );
if (setrlimit(RLIMIT_DATA, _data) == -1) {
fprintf(stderr, "setrlimit failed: %s\n", strerror(errno));
return 1;
}
if (sbrk(1 << 20) == (void*)-1) {
saved_errno = errno;
fprintf(stderr, "sbrk failed: %s (brk=%p)\n",
strerror(saved_errno), sbrk(0));
return 1;
} else {
fprintf(stderr, "sbrk succeeded (brk=%p)\n", sbrk(0));
return 0;
}
}
x86: randomize brk() and RLIMIT_DATA
Would be neat if randomized brk and setrlimit(RLIMIT_DATA, ...)
worked in a predictable way:
$ gcc brk.c -fPIC -pie -m64;./a.out;./a.out;./a.out
sbrk=0x7f721b815000 main=0x7f721af04860
sbrk succeeded (brk=0x7f721b909240)
sbrk=0x7fc3d77e2000 main=0x7fc3d66fa860
sbrk failed: Cannot allocate memory (brk=0x7fc3d77e2000)
sbrk=0x7f05b0615000 main=0x7f05af76b860
sbrk failed: Cannot allocate memory (brk=0x7f05b0615000)
--
Do what you love because life is too short for anything else.
#include stdio.h
#include unistd.h
#include sys/time.h
#include sys/resource.h
#include errno.h
#include string.h
int main(void)
{
void *p;
const struct rlimit rlim_data = {
.rlim_cur = 10 20,
.rlim_max = RLIM_INFINITY
};
int saved_errno;
p = sbrk(0);
fprintf(stderr, sbrk=%p main=%p\n, p, main);
if (setrlimit(RLIMIT_DATA, rlim_data) == -1) {
fprintf(stderr, setrlimit failed: %s\n, strerror(errno));
return 1;
}
if (sbrk(1 20) == (void*)-1) {
saved_errno = errno;
fprintf(stderr, sbrk failed: %s (brk=%p)\n,
strerror(saved_errno), sbrk(0));
return 1;
} else {
fprintf(stderr, sbrk succeeded (brk=%p)\n, sbrk(0));
return 0;
}
}
Re: x86: randomize brk() and RLIMIT_DATA
On Thu, Oct 25, 2007 at 16:46:26 +0200, Jiri Kosina wrote: On Thu, 25 Oct 2007, Arjan van de Ven wrote: Would be neat if randomized brk and setrlimit(RLIMIT_DATA, ...) worked in a predictable way: this isn't a valid case afaics; even on traditional x86 (before we changed the address space layout, or even today if you have an unlimited stack rlimit) this isn't going to work. applications really shouldn't use (s)brk() but malloc(); you have to be able to fall back to mmap regardless of what you do. I tend to agree here with Arjan. However it probably would make no harm to make at least a little bit consisten behavior of setrlimit(), though it has a little use in such cases. Sami, does the patch below work for you? Thanks, Jiri, now RLIMIT_DATA works as expected. Using only RLIMIT_AS to limit processes' memory usage is not very easy. It includes also libraries mapped read-only, I have to check/modify the limits when I update/add libraries,... Amazingly, I found a patch which seems to be just what I need: http://marc.info/?l=linux-mmm=118402827803338w=4 Seems like that is not going to -mm or mainstream... -- Do what you love because life is too short for anything else. - 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 1/2] oProfile: oops when profile_pc() return ~0LU
On Tue, Oct 23, 2007 at 18:13:21 +0200, Philippe Elie wrote: > On Tue, 23 Oct 2007 at 13:10 +0000, Sami Farin wrote: > > > On Mon, Oct 22, 2007 at 19:38:10 -0700, Linus Torvalds wrote: > > > > > > This set of two patches look ok by me, but I'd like sign-offs.. Also, > > > were > > > they tested and found to fix the problem by Sami? > > > > > > Linus > > For the signed-offs I thought the From: was an implicit Signed-offs. > > Test was done privately, Sami helped to narrow down the trouble, but > he didn't test the last patch, nothing bad on Sami side, I was too > confident the fix was obvious after narrowing it. > > > > > The previous patch I tested by Philippe, oprof-fix-profile_pc-use.patch, > > worked ok, but with this latest patch oprofiled aborts. > > But kernel does not oops or print msgs. > > argh, I just moved the wrong eip from kernel to user space where the same > problem occur too, *sighs*, since I can't reproduce Sami problem, my own > test obviously worked... > > Sami, can you test this new patch. After testing can you report > the contents of /dev/oprofile/stats/cpu*/sample_invalid_eip ? cat /dev/oprofile/stats/cpu?/sample_invalid_eip; sleep 10; cat /dev/oprofile/stats/cpu?/sample_invalid_eip 834 835 0 0 906 911 0 0 For some reason there are four directories, but I have only two CPUs in reality. And oprofiled survives the test OK. > Linus, there is two way to fix this problem, the attached patch fix it > by sanitizing the sampled eip, the other is to replace the use of > profile_pc(); by instruction_pointer(); in cpu_buffer.c, that one was > tested by Sami but 1) it'll break the 'use oprofile as a sort of lockometer' > 2) I think sanitizing the eip will be necessary anyway as I'm not really > confident than instruction_pointer() can never return weird eip on some > weird arch and/or some weird circumstances. -- Do what you love because life is too short for anything else. - 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 1/2] oProfile: oops when profile_pc() return ~0LU
On Mon, Oct 22, 2007 at 19:38:10 -0700, Linus Torvalds wrote:
>
> This set of two patches look ok by me, but I'd like sign-offs.. Also, were
> they tested and found to fix the problem by Sami?
>
> Linus
The previous patch I tested by Philippe, oprof-fix-profile_pc-use.patch,
worked ok, but with this latest patch oprofiled aborts.
But kernel does not oops or print msgs.
(gdb) bt
#0 0x7f68d66fee65 in raise () from /lib64/libc.so.6
#1 0x7f68d6700910 in abort () from /lib64/libc.so.6
#2 0x7f68d7053974 in code_unknown (trans=0x7fff5bcd1c60) at opd_trans.c:140
#3 0x7f68d7053eff in opd_process_samples (buffer=0x7f68d6ef3010
"\002", count=99349) at opd_trans.c:362
#4 0x7f68d7050408 in opd_do_samples (opd_buf=0x7f68d6ef3010
"\002", count=794792) at init.c:131
#5 0x7f68d70504e9 in opd_do_read (buf=0x7f68d6ef3010 "\002",
size=1048576) at init.c:181
#6 0x7f68d70506ca in opd_26_start () at init.c:265
#7 0x7f68d7051468 in main (argc=9, argv=0x7fff5bcd1e98) at oprofiled.c:501
(gdb) frame 2
#2 0x7f68d7053974 in code_unknown (trans=0x7fff5bcd1c60) at opd_trans.c:140
140 abort();
(gdb) p *trans
$1 = {buffer = 0x7f68d6ef3c38 "�)\200", remaining = 98960, tracing =
TRACING_OFF, current = 0x7f68d89dd010, last = 0x7f68d89dd010, anon = 0x0,
last_anon = 0x0, cookie = 18446604436320244048, app_cookie =
18446604436320244048, pc = 18446744071568019675, last_pc =
18446744071568019675,
event = 5, in_kernel = 1, cpu = 1, tid = 10074, tgid = 10074, embedded_offset
= 18446744073709551615}
(gdb)
--
Do what you love because life is too short for anything else.
-
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 1/2] oProfile: oops when profile_pc() return ~0LU
On Mon, Oct 22, 2007 at 19:38:10 -0700, Linus Torvalds wrote:
This set of two patches look ok by me, but I'd like sign-offs.. Also, were
they tested and found to fix the problem by Sami?
Linus
The previous patch I tested by Philippe, oprof-fix-profile_pc-use.patch,
worked ok, but with this latest patch oprofiled aborts.
But kernel does not oops or print msgs.
(gdb) bt
#0 0x7f68d66fee65 in raise () from /lib64/libc.so.6
#1 0x7f68d6700910 in abort () from /lib64/libc.so.6
#2 0x7f68d7053974 in code_unknown (trans=0x7fff5bcd1c60) at opd_trans.c:140
#3 0x7f68d7053eff in opd_process_samples (buffer=0x7f68d6ef3010
\002, count=99349) at opd_trans.c:362
#4 0x7f68d7050408 in opd_do_samples (opd_buf=0x7f68d6ef3010
\002, count=794792) at init.c:131
#5 0x7f68d70504e9 in opd_do_read (buf=0x7f68d6ef3010 \002,
size=1048576) at init.c:181
#6 0x7f68d70506ca in opd_26_start () at init.c:265
#7 0x7f68d7051468 in main (argc=9, argv=0x7fff5bcd1e98) at oprofiled.c:501
(gdb) frame 2
#2 0x7f68d7053974 in code_unknown (trans=0x7fff5bcd1c60) at opd_trans.c:140
140 abort();
(gdb) p *trans
$1 = {buffer = 0x7f68d6ef3c38 �)\200, remaining = 98960, tracing =
TRACING_OFF, current = 0x7f68d89dd010, last = 0x7f68d89dd010, anon = 0x0,
last_anon = 0x0, cookie = 18446604436320244048, app_cookie =
18446604436320244048, pc = 18446744071568019675, last_pc =
18446744071568019675,
event = 5, in_kernel = 1, cpu = 1, tid = 10074, tgid = 10074, embedded_offset
= 18446744073709551615}
(gdb)
--
Do what you love because life is too short for anything else.
-
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 1/2] oProfile: oops when profile_pc() return ~0LU
On Tue, Oct 23, 2007 at 18:13:21 +0200, Philippe Elie wrote: On Tue, 23 Oct 2007 at 13:10 +, Sami Farin wrote: On Mon, Oct 22, 2007 at 19:38:10 -0700, Linus Torvalds wrote: This set of two patches look ok by me, but I'd like sign-offs.. Also, were they tested and found to fix the problem by Sami? Linus For the signed-offs I thought the From: was an implicit Signed-offs. Test was done privately, Sami helped to narrow down the trouble, but he didn't test the last patch, nothing bad on Sami side, I was too confident the fix was obvious after narrowing it. The previous patch I tested by Philippe, oprof-fix-profile_pc-use.patch, worked ok, but with this latest patch oprofiled aborts. But kernel does not oops or print msgs. argh, I just moved the wrong eip from kernel to user space where the same problem occur too, *sighs*, since I can't reproduce Sami problem, my own test obviously worked... Sami, can you test this new patch. After testing can you report the contents of /dev/oprofile/stats/cpu*/sample_invalid_eip ? cat /dev/oprofile/stats/cpu?/sample_invalid_eip; sleep 10; cat /dev/oprofile/stats/cpu?/sample_invalid_eip 834 835 0 0 906 911 0 0 For some reason there are four directories, but I have only two CPUs in reality. And oprofiled survives the test OK. Linus, there is two way to fix this problem, the attached patch fix it by sanitizing the sampled eip, the other is to replace the use of profile_pc(); by instruction_pointer(); in cpu_buffer.c, that one was tested by Sami but 1) it'll break the 'use oprofile as a sort of lockometer' 2) I think sanitizing the eip will be necessary anyway as I'm not really confident than instruction_pointer() can never return weird eip on some weird arch and/or some weird circumstances. -- Do what you love because life is too short for anything else. - 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.22.6 + oprofile oops
On Thu, Oct 11, 2007 at 16:36:10 +0200, Philippe Elie wrote: > On Sat, 29 Sep 2007 at 20:05 +0000, Sami Farin wrote: > > > > x86_64 SMP kernel v2.6.22.6 (not using callgraph). > > > sometimes oprofile works for a longer time... but not this time. > > > > > > 2007-09-22 13:53:32.52723 <1>[ 3372.390188] Unable to handle kernel > > > NULL pointer dereference at 0650 RIP: > > > 2007-09-22 13:53:32.527245948 <1>[ 3372.390195] [] > > > _spin_lock+0x4/0x20 > ... > > 2007-09-22 13:53:32.527390314 <4>[ 3372.390457] [] > > get_task_mm+0x18/0x60 > > On the per cpu buffer writer side oprofile_add_sample() use profile_pc() > to get the eip, profile_pc() can return ~0lu, but an eip == ~0lu is a > magic value = ESCAPE_CODE. The per cpu reader side in buffer_sync.c use > this value to know that the associated data is a task pointer but here > the associated data is a counter number. I applied this patch and I'm not able to reproduce Oops anymore with 2.6.22.10 or 2.6.23. Haven't gotten "oprofile: Invalid event", either. Thanks a bunch! -- Do what you love because life is too short for anything else. - 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.22.6 + oprofile oops
On Thu, Oct 11, 2007 at 16:36:10 +0200, Philippe Elie wrote: On Sat, 29 Sep 2007 at 20:05 +, Sami Farin wrote: x86_64 SMP kernel v2.6.22.6 (not using callgraph). sometimes oprofile works for a longer time... but not this time. 2007-09-22 13:53:32.52723 1[ 3372.390188] Unable to handle kernel NULL pointer dereference at 0650 RIP: 2007-09-22 13:53:32.527245948 1[ 3372.390195] [80652f44] _spin_lock+0x4/0x20 ... 2007-09-22 13:53:32.527390314 4[ 3372.390457] [80232b88] get_task_mm+0x18/0x60 On the per cpu buffer writer side oprofile_add_sample() use profile_pc() to get the eip, profile_pc() can return ~0lu, but an eip == ~0lu is a magic value = ESCAPE_CODE. The per cpu reader side in buffer_sync.c use this value to know that the associated data is a task pointer but here the associated data is a counter number. I applied this patch and I'm not able to reproduce Oops anymore with 2.6.22.10 or 2.6.23. Haven't gotten oprofile: Invalid event, either. Thanks a bunch! -- Do what you love because life is too short for anything else. - 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.22.6 + oprofile oops
On Mon, Oct 01, 2007 at 12:29:18 +0200, Andi Kleen wrote: > Sami Farin <[EMAIL PROTECTED]> writes: ... > Can you reproduce it with a non tainted kernel without any patches like CFS > applied? I tried without CFS and it Oopsed just as nicely, the only difference was that in call trace before :oprofile:wq_sync_buffer there's now cache_reap. Call Trace: [] get_task_mm+0x18/0x50 [] :oprofile:sync_buffer+0xf4/0x450 [] :oprofile:wq_sync_buffer+0x0/0x60 [] :oprofile:wq_sync_buffer+0x33/0x60 [] cache_reap+0x0/0x130 [] run_workqueue+0x89/0x120 [] worker_thread+0xc7/0x130 [] autoremove_wake_function+0x0/0x40 [] worker_thread+0x0/0x130 [] kthread+0x4d/0x80 [] child_rip+0xa/0x12 [] kthread+0x0/0x80 [] child_rip+0x0/0x12 > The oops happens because oprofile tries to reference a NULL task in > its event buffer for a context switch, which might well be a minor > merging mistake or similar in the CFS backport. ... > > 2007-09-22 13:53:32.527385634 <4>[ 3372.390442] Call Trace: > > 2007-09-22 13:53:32.527390314 <4>[ 3372.390457] [] > > get_task_mm+0x18/0x60 > > 2007-09-22 13:53:32.527391990 <4>[ 3372.390484] [] > > :oprofile:sync_buffer+0xf4/0x480 > > 2007-09-22 13:53:32.527393666 <4>[ 3372.390544] [] > > :oprofile:wq_sync_buffer+0x0/0x60 > > 2007-09-22 13:53:32.527399673 <4>[ 3372.390576] [] > > :oprofile:wq_sync_buffer+0x33/0x60 > > 2007-09-22 13:53:32.527401419 <4>[ 3372.390602] [] > > run_workqueue+0xcd/0x170 > > 2007-09-22 13:53:32.527406238 <4>[ 3372.390635] [] > > worker_thread+0xb3/0x120 > > 2007-09-22 13:53:32.527421324 <4>[ 3372.390652] [] > > autoremove_wake_function+0x0/0x40 > > 2007-09-22 13:53:32.527423140 <4>[ 3372.390684] [] > > worker_thread+0x0/0x120 > > 2007-09-22 13:53:32.527424816 <4>[ 3372.390697] [] > > kthread+0x4d/0x80 > > 2007-09-22 13:53:32.527426423 <4>[ 3372.390730] [] > > child_rip+0xa/0x12 > > 2007-09-22 13:53:32.527428099 <4>[ 3372.390810] [] > > kthread+0x0/0x80 > > 2007-09-22 13:53:32.527444931 <4>[ 3372.390822] [] > > child_rip+0x0/0x12 -- Do what you love because life is too short for anything else. - 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.22.6 + oprofile oops
On Mon, Oct 01, 2007 at 12:29:18 +0200, Andi Kleen wrote: Sami Farin [EMAIL PROTECTED] writes: ... Can you reproduce it with a non tainted kernel without any patches like CFS applied? I tried without CFS and it Oopsed just as nicely, the only difference was that in call trace before :oprofile:wq_sync_buffer there's now cache_reap. Call Trace: [80231988] get_task_mm+0x18/0x50 [88316b64] :oprofile:sync_buffer+0xf4/0x450 [88316650] :oprofile:wq_sync_buffer+0x0/0x60 [88316683] :oprofile:wq_sync_buffer+0x33/0x60 [80289f10] cache_reap+0x0/0x130 [80243269] run_workqueue+0x89/0x120 [80243cf7] worker_thread+0xc7/0x130 [802474d0] autoremove_wake_function+0x0/0x40 [80243c30] worker_thread+0x0/0x130 [802470cd] kthread+0x4d/0x80 [8020aa78] child_rip+0xa/0x12 [80247080] kthread+0x0/0x80 [8020aa6e] child_rip+0x0/0x12 The oops happens because oprofile tries to reference a NULL task in its event buffer for a context switch, which might well be a minor merging mistake or similar in the CFS backport. ... 2007-09-22 13:53:32.527385634 4[ 3372.390442] Call Trace: 2007-09-22 13:53:32.527390314 4[ 3372.390457] [80232b88] get_task_mm+0x18/0x60 2007-09-22 13:53:32.527391990 4[ 3372.390484] [8831abd4] :oprofile:sync_buffer+0xf4/0x480 2007-09-22 13:53:32.527393666 4[ 3372.390544] [8831a6b0] :oprofile:wq_sync_buffer+0x0/0x60 2007-09-22 13:53:32.527399673 4[ 3372.390576] [8831a6e3] :oprofile:wq_sync_buffer+0x33/0x60 2007-09-22 13:53:32.527401419 4[ 3372.390602] [80244bfd] run_workqueue+0xcd/0x170 2007-09-22 13:53:32.527406238 4[ 3372.390635] [802456b3] worker_thread+0xb3/0x120 2007-09-22 13:53:32.527421324 4[ 3372.390652] [80249000] autoremove_wake_function+0x0/0x40 2007-09-22 13:53:32.527423140 4[ 3372.390684] [80245600] worker_thread+0x0/0x120 2007-09-22 13:53:32.527424816 4[ 3372.390697] [80248bfd] kthread+0x4d/0x80 2007-09-22 13:53:32.527426423 4[ 3372.390730] [8020abc8] child_rip+0xa/0x12 2007-09-22 13:53:32.527428099 4[ 3372.390810] [80248bb0] kthread+0x0/0x80 2007-09-22 13:53:32.527444931 4[ 3372.390822] [8020abbe] child_rip+0x0/0x12 -- Do what you love because life is too short for anything else. - 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.22.6 + oprofile oops
On Sat, Sep 22, 2007 at 14:23:35 +0300, Sami Farin wrote: > x86_64 SMP kernel v2.6.22.6 (not using callgraph). > sometimes oprofile works for a longer time... but not this time. > > 2007-09-22 13:53:32.52723 <1>[ 3372.390188] Unable to handle kernel NULL > pointer dereference at 0650 RIP: > 2007-09-22 13:53:32.527245948 <1>[ 3372.390195] [] > _spin_lock+0x4/0x20 > 2007-09-22 13:53:32.527247694 <4>[ 3372.390211] PGD 13a6c067 PUD 3ad91067 PMD > 0 > 2007-09-22 13:53:32.527249371 <0>[ 3372.390216] Oops: 0002 [1] SMP > 2007-09-22 13:53:32.527250837 <4>[ 3372.390220] CPU 0 > 2007-09-22 13:53:32.527252304 <4>[ 3372.390227] ... > 2007-09-22 13:53:32.527385634 <4>[ 3372.390442] Call Trace: > 2007-09-22 13:53:32.527390314 <4>[ 3372.390457] [] > get_task_mm+0x18/0x60 > 2007-09-22 13:53:32.527391990 <4>[ 3372.390484] [] > :oprofile:sync_buffer+0xf4/0x480 > 2007-09-22 13:53:32.527393666 <4>[ 3372.390544] [] > :oprofile:wq_sync_buffer+0x0/0x60 > 2007-09-22 13:53:32.527399673 <4>[ 3372.390576] [] > :oprofile:wq_sync_buffer+0x33/0x60 > 2007-09-22 13:53:32.527401419 <4>[ 3372.390602] [] > run_workqueue+0xcd/0x170 > 2007-09-22 13:53:32.527406238 <4>[ 3372.390635] [] > worker_thread+0xb3/0x120 > 2007-09-22 13:53:32.527421324 <4>[ 3372.390652] [] > autoremove_wake_function+0x0/0x40 > 2007-09-22 13:53:32.527423140 <4>[ 3372.390684] [] > worker_thread+0x0/0x120 > 2007-09-22 13:53:32.527424816 <4>[ 3372.390697] [] > kthread+0x4d/0x80 > 2007-09-22 13:53:32.527426423 <4>[ 3372.390730] [] > child_rip+0xa/0x12 > 2007-09-22 13:53:32.527428099 <4>[ 3372.390810] [] > kthread+0x0/0x80 > 2007-09-22 13:53:32.527444931 <4>[ 3372.390822] [] > child_rip+0x0/0x12 This is easy to trigger with "ping -f 127.0.0.1" (as root). Oopses inside 0.1s. If you can't reproduce, try more events and/or smaller sample count. May I suggest something: if system is too slow to process events, find out which event is triggering too often, double the sample count for it, reset all counters, and log an informative kernel message. If that's why it's crashing... if it's some other reason, tough luck :) > 2007-09-22 13:53:32.527446817 <4>[ 3372.390844] > 2007-09-22 13:53:32.527448144 <4>[ 3372.390846] > 2007-09-22 13:53:32.527449541 <4>[ 3372.390846] Code: f0 ff 0f 79 09 f3 90 83 > 3f 00 7e f9 eb f2 c9 c3 66 66 66 2e > 2007-09-22 13:53:32.527455757 <1>[ 3372.390866] RIP [] > _spin_lock+0x4/0x20 > 2007-09-22 13:53:32.527457433 <4>[ 3372.390876] RSP > 2007-09-22 13:53:32.527463090 <0>[ 3372.390878] CR2: 0650 > > BTW. does somebody have callgraph working on x86_64 with oprofile? > I get instant freeze and I need to power cycle system... (callgraph worked on > IA-32) -- Do what you love because life is too short for anything else. - 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.22.6 + oprofile oops
On Sat, Sep 22, 2007 at 14:23:35 +0300, Sami Farin wrote: x86_64 SMP kernel v2.6.22.6 (not using callgraph). sometimes oprofile works for a longer time... but not this time. 2007-09-22 13:53:32.52723 1[ 3372.390188] Unable to handle kernel NULL pointer dereference at 0650 RIP: 2007-09-22 13:53:32.527245948 1[ 3372.390195] [80652f44] _spin_lock+0x4/0x20 2007-09-22 13:53:32.527247694 4[ 3372.390211] PGD 13a6c067 PUD 3ad91067 PMD 0 2007-09-22 13:53:32.527249371 0[ 3372.390216] Oops: 0002 [1] SMP 2007-09-22 13:53:32.527250837 4[ 3372.390220] CPU 0 2007-09-22 13:53:32.527252304 4[ 3372.390227] snip ... 2007-09-22 13:53:32.527385634 4[ 3372.390442] Call Trace: 2007-09-22 13:53:32.527390314 4[ 3372.390457] [80232b88] get_task_mm+0x18/0x60 2007-09-22 13:53:32.527391990 4[ 3372.390484] [8831abd4] :oprofile:sync_buffer+0xf4/0x480 2007-09-22 13:53:32.527393666 4[ 3372.390544] [8831a6b0] :oprofile:wq_sync_buffer+0x0/0x60 2007-09-22 13:53:32.527399673 4[ 3372.390576] [8831a6e3] :oprofile:wq_sync_buffer+0x33/0x60 2007-09-22 13:53:32.527401419 4[ 3372.390602] [80244bfd] run_workqueue+0xcd/0x170 2007-09-22 13:53:32.527406238 4[ 3372.390635] [802456b3] worker_thread+0xb3/0x120 2007-09-22 13:53:32.527421324 4[ 3372.390652] [80249000] autoremove_wake_function+0x0/0x40 2007-09-22 13:53:32.527423140 4[ 3372.390684] [80245600] worker_thread+0x0/0x120 2007-09-22 13:53:32.527424816 4[ 3372.390697] [80248bfd] kthread+0x4d/0x80 2007-09-22 13:53:32.527426423 4[ 3372.390730] [8020abc8] child_rip+0xa/0x12 2007-09-22 13:53:32.527428099 4[ 3372.390810] [80248bb0] kthread+0x0/0x80 2007-09-22 13:53:32.527444931 4[ 3372.390822] [8020abbe] child_rip+0x0/0x12 This is easy to trigger with ping -f 127.0.0.1 (as root). Oopses inside 0.1s. If you can't reproduce, try more events and/or smaller sample count. May I suggest something: if system is too slow to process events, find out which event is triggering too often, double the sample count for it, reset all counters, and log an informative kernel message. If that's why it's crashing... if it's some other reason, tough luck :) 2007-09-22 13:53:32.527446817 4[ 3372.390844] 2007-09-22 13:53:32.527448144 4[ 3372.390846] 2007-09-22 13:53:32.527449541 4[ 3372.390846] Code: f0 ff 0f 79 09 f3 90 83 3f 00 7e f9 eb f2 c9 c3 66 66 66 2e 2007-09-22 13:53:32.527455757 1[ 3372.390866] RIP [80652f44] _spin_lock+0x4/0x20 2007-09-22 13:53:32.527457433 4[ 3372.390876] RSP 81003e5fddc0 2007-09-22 13:53:32.527463090 0[ 3372.390878] CR2: 0650 BTW. does somebody have callgraph working on x86_64 with oprofile? I get instant freeze and I need to power cycle system... (callgraph worked on IA-32) -- Do what you love because life is too short for anything else. - 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.22.6 + oprofile oops
x86_64 SMP kernel v2.6.22.6 (not using callgraph). sometimes oprofile works for a longer time... but not this time. 2007-09-22 13:53:32.52723 <1>[ 3372.390188] Unable to handle kernel NULL pointer dereference at 0650 RIP: 2007-09-22 13:53:32.527245948 <1>[ 3372.390195] [] _spin_lock+0x4/0x20 2007-09-22 13:53:32.527247694 <4>[ 3372.390211] PGD 13a6c067 PUD 3ad91067 PMD 0 2007-09-22 13:53:32.527249371 <0>[ 3372.390216] Oops: 0002 [1] SMP 2007-09-22 13:53:32.527250837 <4>[ 3372.390220] CPU 0 2007-09-22 13:53:32.527252304 <4>[ 3372.390227] Modules linked in: i915 oprofile xt_CLASSIFY ipt_ECN xt_CONNMARK xt_connlimit xt_length ipt_set xt_multiport ip_set_iphash ip_set_nethash ip_set_portmap sch_esfq ipt_REJECT ip6t_LOG xt_limit ipt_LOG xt_hashlimit ipt_owner nf_conntrack_ipv4 xt_state xt_tcpudp ip6table_filter ip6table_mangle ip6_tables iptable_filter iptable_mangle iptable_raw ip_tables tcp_highspeed tcp_htcp tcp_hybla tcp_scalable tcp_vegas tcp_westwood ip_set sch_netem sch_hfsc sch_htb sch_sfq cls_fw cls_u32 cls_route sch_ingress sch_red sch_tbf sch_teql sch_prio sch_gred cls_rsvp cls_rsvp6 cls_tcindex sch_cbq sch_dsmark nf_conntrack xt_TARPIT x_tables perfctr dccp_diag dccp ioatdma cmtp kernelcapi l2cap bluetooth intelfb i2c_algo_bit i810 lp i2c_dev ftdi_sio usbserial usb_storage eeprom ohci_hcd irlan irda crc_ccitt binfmt_misc loop dm_mod video dock button battery ac tcp_cubic nvram snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss parport_p 2007-09-22 13:53:32.527328363 c snd_pcm parport snd_timer ohci1394 ieee1394 snd i2c_i801 i2c_core soundcore ehci_hcd uhci_hcd e1000 snd_page_alloc iTCO_wdt iTCO_vendor_support 2007-09-22 13:53:32.527330808 <4>[ 3372.390363] Pid: 7, comm: events/0 Not tainted 2.6.22.6-cfs-v20.5-64-2 #7 2007-09-22 13:53:32.527332623 <4>[ 3372.390366] RIP: 0010:[] [] _spin_lock+0x4/0x20 2007-09-22 13:53:32.527334439 <4>[ 3372.390373] RSP: 0018:81003e5fddc0 EFLAGS: 00010282 2007-09-22 13:53:32.527336116 <4>[ 3372.390380] RAX: 000d RBX: 0004 RCX: 00018000 2007-09-22 13:53:32.527346033 <4>[ 3372.390383] RDX: 000155ae RSI: RDI: 0650 2007-09-22 13:53:32.527347849 <4>[ 3372.390387] RBP: 81003e5fddc0 R08: R09: 2007-09-22 13:53:32.527349595 <4>[ 3372.390391] R10: R11: R12: 0004 2007-09-22 13:53:32.527351411 <4>[ 3372.390398] R13: R14: 88321d00 R15: 000d 2007-09-22 13:53:32.527365100 <4>[ 3372.390402] FS: () GS:80805000() knlGS: 2007-09-22 13:53:32.527367056 <4>[ 3372.390406] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b 2007-09-22 13:53:32.527368662 <4>[ 3372.390409] CR2: 0650 CR3: 11d52000 CR4: 06e0 2007-09-22 13:53:32.527370478 <4>[ 3372.390417] Process events/0 (pid: 7, threadinfo 81003e5fc000, task 810001ffb100) 2007-09-22 13:53:32.527380117 <4>[ 3372.390419] Stack: 81003e5fdde0 80232b88 81003e5fdeb0 00ba 2007-09-22 13:53:32.527382002 <4>[ 3372.390427] 81003e5fde60 8831abd4 88321d70 2007-09-22 13:53:32.527383818 <4>[ 3372.390437] 00010001 00ba 2007-09-22 13:53:32.527385634 <4>[ 3372.390442] Call Trace: 2007-09-22 13:53:32.527390314 <4>[ 3372.390457] [] get_task_mm+0x18/0x60 2007-09-22 13:53:32.527391990 <4>[ 3372.390484] [] :oprofile:sync_buffer+0xf4/0x480 2007-09-22 13:53:32.527393666 <4>[ 3372.390544] [] :oprofile:wq_sync_buffer+0x0/0x60 2007-09-22 13:53:32.527399673 <4>[ 3372.390576] [] :oprofile:wq_sync_buffer+0x33/0x60 2007-09-22 13:53:32.527401419 <4>[ 3372.390602] [] run_workqueue+0xcd/0x170 2007-09-22 13:53:32.527406238 <4>[ 3372.390635] [] worker_thread+0xb3/0x120 2007-09-22 13:53:32.527421324 <4>[ 3372.390652] [] autoremove_wake_function+0x0/0x40 2007-09-22 13:53:32.527423140 <4>[ 3372.390684] [] worker_thread+0x0/0x120 2007-09-22 13:53:32.527424816 <4>[ 3372.390697] [] kthread+0x4d/0x80 2007-09-22 13:53:32.527426423 <4>[ 3372.390730] [] child_rip+0xa/0x12 2007-09-22 13:53:32.527428099 <4>[ 3372.390810] [] kthread+0x0/0x80 2007-09-22 13:53:32.527444931 <4>[ 3372.390822] [] child_rip+0x0/0x12 2007-09-22 13:53:32.527446817 <4>[ 3372.390844] 2007-09-22 13:53:32.527448144 <4>[ 3372.390846] 2007-09-22 13:53:32.527449541 <4>[ 3372.390846] Code: f0 ff 0f 79 09 f3 90 83 3f 00 7e f9 eb f2 c9 c3 66 66 66 2e 2007-09-22 13:53:32.527455757 <1>[ 3372.390866] RIP [] _spin_lock+0x4/0x20 2007-09-22 13:53:32.527457433 <4>[ 3372.390876] RSP 2007-09-22 13:53:32.527463090 <0>[ 3372.390878] CR2: 0650 BTW. does somebody have callgraph working on x86_64 with oprofile? I get instant freeze and I need to power cycle system... (callgraph worked on
2.6.22.6 + oprofile oops
x86_64 SMP kernel v2.6.22.6 (not using callgraph). sometimes oprofile works for a longer time... but not this time. 2007-09-22 13:53:32.52723 1[ 3372.390188] Unable to handle kernel NULL pointer dereference at 0650 RIP: 2007-09-22 13:53:32.527245948 1[ 3372.390195] [80652f44] _spin_lock+0x4/0x20 2007-09-22 13:53:32.527247694 4[ 3372.390211] PGD 13a6c067 PUD 3ad91067 PMD 0 2007-09-22 13:53:32.527249371 0[ 3372.390216] Oops: 0002 [1] SMP 2007-09-22 13:53:32.527250837 4[ 3372.390220] CPU 0 2007-09-22 13:53:32.527252304 4[ 3372.390227] Modules linked in: i915 oprofile xt_CLASSIFY ipt_ECN xt_CONNMARK xt_connlimit xt_length ipt_set xt_multiport ip_set_iphash ip_set_nethash ip_set_portmap sch_esfq ipt_REJECT ip6t_LOG xt_limit ipt_LOG xt_hashlimit ipt_owner nf_conntrack_ipv4 xt_state xt_tcpudp ip6table_filter ip6table_mangle ip6_tables iptable_filter iptable_mangle iptable_raw ip_tables tcp_highspeed tcp_htcp tcp_hybla tcp_scalable tcp_vegas tcp_westwood ip_set sch_netem sch_hfsc sch_htb sch_sfq cls_fw cls_u32 cls_route sch_ingress sch_red sch_tbf sch_teql sch_prio sch_gred cls_rsvp cls_rsvp6 cls_tcindex sch_cbq sch_dsmark nf_conntrack xt_TARPIT x_tables perfctr dccp_diag dccp ioatdma cmtp kernelcapi l2cap bluetooth intelfb i2c_algo_bit i810 lp i2c_dev ftdi_sio usbserial usb_storage eeprom ohci_hcd irlan irda crc_ccitt binfmt_misc loop dm_mod video dock button battery ac tcp_cubic nvram snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss parport_p 2007-09-22 13:53:32.527328363 c snd_pcm parport snd_timer ohci1394 ieee1394 snd i2c_i801 i2c_core soundcore ehci_hcd uhci_hcd e1000 snd_page_alloc iTCO_wdt iTCO_vendor_support 2007-09-22 13:53:32.527330808 4[ 3372.390363] Pid: 7, comm: events/0 Not tainted 2.6.22.6-cfs-v20.5-64-2 #7 2007-09-22 13:53:32.527332623 4[ 3372.390366] RIP: 0010:[80652f44] [80652f44] _spin_lock+0x4/0x20 2007-09-22 13:53:32.527334439 4[ 3372.390373] RSP: 0018:81003e5fddc0 EFLAGS: 00010282 2007-09-22 13:53:32.527336116 4[ 3372.390380] RAX: 000d RBX: 0004 RCX: 00018000 2007-09-22 13:53:32.527346033 4[ 3372.390383] RDX: 000155ae RSI: RDI: 0650 2007-09-22 13:53:32.527347849 4[ 3372.390387] RBP: 81003e5fddc0 R08: R09: 2007-09-22 13:53:32.527349595 4[ 3372.390391] R10: R11: R12: 0004 2007-09-22 13:53:32.527351411 4[ 3372.390398] R13: R14: 88321d00 R15: 000d 2007-09-22 13:53:32.527365100 4[ 3372.390402] FS: () GS:80805000() knlGS: 2007-09-22 13:53:32.527367056 4[ 3372.390406] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b 2007-09-22 13:53:32.527368662 4[ 3372.390409] CR2: 0650 CR3: 11d52000 CR4: 06e0 2007-09-22 13:53:32.527370478 4[ 3372.390417] Process events/0 (pid: 7, threadinfo 81003e5fc000, task 810001ffb100) 2007-09-22 13:53:32.527380117 4[ 3372.390419] Stack: 81003e5fdde0 80232b88 81003e5fdeb0 00ba 2007-09-22 13:53:32.527382002 4[ 3372.390427] 81003e5fde60 8831abd4 88321d70 2007-09-22 13:53:32.527383818 4[ 3372.390437] 00010001 00ba 2007-09-22 13:53:32.527385634 4[ 3372.390442] Call Trace: 2007-09-22 13:53:32.527390314 4[ 3372.390457] [80232b88] get_task_mm+0x18/0x60 2007-09-22 13:53:32.527391990 4[ 3372.390484] [8831abd4] :oprofile:sync_buffer+0xf4/0x480 2007-09-22 13:53:32.527393666 4[ 3372.390544] [8831a6b0] :oprofile:wq_sync_buffer+0x0/0x60 2007-09-22 13:53:32.527399673 4[ 3372.390576] [8831a6e3] :oprofile:wq_sync_buffer+0x33/0x60 2007-09-22 13:53:32.527401419 4[ 3372.390602] [80244bfd] run_workqueue+0xcd/0x170 2007-09-22 13:53:32.527406238 4[ 3372.390635] [802456b3] worker_thread+0xb3/0x120 2007-09-22 13:53:32.527421324 4[ 3372.390652] [80249000] autoremove_wake_function+0x0/0x40 2007-09-22 13:53:32.527423140 4[ 3372.390684] [80245600] worker_thread+0x0/0x120 2007-09-22 13:53:32.527424816 4[ 3372.390697] [80248bfd] kthread+0x4d/0x80 2007-09-22 13:53:32.527426423 4[ 3372.390730] [8020abc8] child_rip+0xa/0x12 2007-09-22 13:53:32.527428099 4[ 3372.390810] [80248bb0] kthread+0x0/0x80 2007-09-22 13:53:32.527444931 4[ 3372.390822] [8020abbe] child_rip+0x0/0x12 2007-09-22 13:53:32.527446817 4[ 3372.390844] 2007-09-22 13:53:32.527448144 4[ 3372.390846] 2007-09-22 13:53:32.527449541 4[ 3372.390846] Code: f0 ff 0f 79 09 f3 90 83 3f 00 7e f9 eb f2 c9 c3 66 66 66 2e 2007-09-22 13:53:32.527455757 1[ 3372.390866] RIP [80652f44] _spin_lock+0x4/0x20 2007-09-22 13:53:32.527457433 4[ 3372.390876] RSP 81003e5fddc0 2007-09-22
TSC && HPET calibration
/var/log # grep -Ei "hpet|tsc" dmesg-2.6.19.7 dmesg.2.6.22.6-x86_64 dmesg-2.6.19.7:ACPI: HPET (v001 INTEL DQ965GF 0x15db MSFT 0x0113) @ 0x3e6f2000 dmesg-2.6.19.7:ACPI: HPET id: 0x8086a201 base: 0xfed0 dmesg-2.6.19.7:[ 34.337155] hpet0: at MMIO 0xfed0, IRQs 2, 8, 0 dmesg-2.6.19.7:[ 34.337296] hpet0: 3 64-bit timers, 14318180 Hz [*] dmesg-2.6.19.7:[ 34.338350] Using HPET for base-timer dmesg-2.6.19.7:[ 34.594096] checking TSC synchronization across 2 CPUs: passed. dmesg-2.6.19.7:[0.215896] hpet_resources: 0xfed0 is busy dmesg-2.6.19.7:[7.794166] Time: tsc clocksource has been installed. dmesg.2.6.22.6-x86_64:ACPI: HPET 3E6F2000, 0038 (r1 INTEL DQ965GF 1741 MSFT 113) dmesg.2.6.22.6-x86_64:ACPI: HPET id: 0x8086a201 base: 0xfed0 dmesg.2.6.22.6-x86_64:[0.00] hpet clockevent registered dmesg.2.6.22.6-x86_64:[0.00] TSC calibrated against HPET dmesg.2.6.22.6-x86_64:[ 23.917469] checking TSC synchronization [CPU#0 -> CPU#1]: dmesg.2.6.22.6-x86_64:[ 23.937970] Measured 196 cycles TSC warp between CPUs, turning off TSC clock. dmesg.2.6.22.6-x86_64:[ 23.938030] Marking TSC unstable due to check_tsc_sync_source failed dmesg.2.6.22.6-x86_64:[ 23.968187] Time: hpet clocksource has been installed. dmesg.2.6.22.6-x86_64:[ 23.997754] hpet_acpi_add: no address or irqs in _CRS # grep MHz /proc/cpuinfo cpu MHz : 2797.203 cpu MHz : 2797.203 # calc 2797203000/196 ~14271443.87755102040816326531 [*] so, does TSC calibration against HPET screw up TSC synchronization? I have Intel(R) Pentium(R) D CPU 2.80GHz and DQ965GF motherboard, BIOS v.5953. -- Do what you love because life is too short for anything else. - 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/
TSC HPET calibration
/var/log # grep -Ei hpet|tsc dmesg-2.6.19.7 dmesg.2.6.22.6-x86_64 dmesg-2.6.19.7:ACPI: HPET (v001 INTEL DQ965GF 0x15db MSFT 0x0113) @ 0x3e6f2000 dmesg-2.6.19.7:ACPI: HPET id: 0x8086a201 base: 0xfed0 dmesg-2.6.19.7:[ 34.337155] hpet0: at MMIO 0xfed0, IRQs 2, 8, 0 dmesg-2.6.19.7:[ 34.337296] hpet0: 3 64-bit timers, 14318180 Hz [*] dmesg-2.6.19.7:[ 34.338350] Using HPET for base-timer dmesg-2.6.19.7:[ 34.594096] checking TSC synchronization across 2 CPUs: passed. dmesg-2.6.19.7:[0.215896] hpet_resources: 0xfed0 is busy dmesg-2.6.19.7:[7.794166] Time: tsc clocksource has been installed. dmesg.2.6.22.6-x86_64:ACPI: HPET 3E6F2000, 0038 (r1 INTEL DQ965GF 1741 MSFT 113) dmesg.2.6.22.6-x86_64:ACPI: HPET id: 0x8086a201 base: 0xfed0 dmesg.2.6.22.6-x86_64:[0.00] hpet clockevent registered dmesg.2.6.22.6-x86_64:[0.00] TSC calibrated against HPET dmesg.2.6.22.6-x86_64:[ 23.917469] checking TSC synchronization [CPU#0 - CPU#1]: dmesg.2.6.22.6-x86_64:[ 23.937970] Measured 196 cycles TSC warp between CPUs, turning off TSC clock. dmesg.2.6.22.6-x86_64:[ 23.938030] Marking TSC unstable due to check_tsc_sync_source failed dmesg.2.6.22.6-x86_64:[ 23.968187] Time: hpet clocksource has been installed. dmesg.2.6.22.6-x86_64:[ 23.997754] hpet_acpi_add: no address or irqs in _CRS # grep MHz /proc/cpuinfo cpu MHz : 2797.203 cpu MHz : 2797.203 # calc 2797203000/196 ~14271443.87755102040816326531 [*] so, does TSC calibration against HPET screw up TSC synchronization? I have Intel(R) Pentium(R) D CPU 2.80GHz and DQ965GF motherboard, BIOS v.5953. -- Do what you love because life is too short for anything else. - 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: kernel 2.6.22: what IS the VM doing?
On Wed, Sep 05, 2007 at 18:48:51 -0400, Rik van Riel wrote: > Sami Farin wrote: >> On Wed, Sep 05, 2007 at 12:24:26 -0400, Rik van Riel wrote: >> ... >>>> *shrug* >>> The attached patch should make sure kswapd does not free an >>> excessive number of pages in zone_normal just because the >>> pages in zone_highmem are difficult to free. >>> >>> It does give kswapd a large margin to continue putting equal >>> pressure on all zones in normal situations. >>> >>> Sami, could you try out this patch to see if it helps your >>> situation? >> >> Thanks, Rik. bzImage is ready, I probably reboot inside one >> month for a reason or other 8-) > > The more I look at the bug, the more I see that it is probably > not very easy to reproduce on demand. I have, however, a full Well, I now booted to x86_64 kernel. I can still reproduce this. When I unload ipset modules, kernel resumes "normal" operation, i.e., not swapping like mad. sysrq-m, normal operation: [172074.989053] SysRq : Show Memory [172074.989063] Mem-info: [172074.989071] DMA per-cpu: [172074.989078] CPU0: Hot: hi:0, btch: 1 usd: 0 Cold: hi:0, btch: 1 usd: 0 [172074.989083] CPU1: Hot: hi:0, btch: 1 usd: 0 Cold: hi:0, btch: 1 usd: 0 [172074.989089] DMA32 per-cpu: [172074.989094] CPU0: Hot: hi: 186, btch: 31 usd: 153 Cold: hi: 62, btch: 15 usd: 10 [172074.989101] CPU1: Hot: hi: 186, btch: 31 usd: 34 Cold: hi: 62, btch: 15 usd: 14 [172074.989109] Active:123048 inactive:55194 dirty:5 writeback:0 unstable:0 [172074.989111] free:15001 slab:27961 mapped:15063 pagetables:2996 bounce:0 [172074.989118] DMA free:5560kB min:32kB low:40kB high:48kB active:404kB inactive:736kB present:8620kB pages_scanned:0 all_unreclaimable? no [172074.989124] lowmem_reserve[]: 0 968 968 [172074.989143] DMA32 free:5kB min:3964kB low:4952kB high:5944kB active:491788kB inactive:220040kB present:991996kB pages_scanned:0 all_unreclaimable? no [172074.989150] lowmem_reserve[]: 0 0 0 [172074.989166] DMA: 276*4kB 121*8kB 30*16kB 6*32kB 0*64kB 0*128kB 1*256kB 1*512kB 2*1024kB 0*2048kB 0*4096kB = 5560kB [172074.989205] DMA32: 9467*4kB 1222*8kB 121*16kB 22*32kB 3*64kB 1*128kB 1*256kB 3*512kB 0*1024kB 1*2048kB 0*4096kB = 5kB [172074.989249] Swap cache: add 613353, delete 556659, find 441592/473681, race 0+5 [172074.989255] Free swap = 2751640kB [172074.989260] Total swap = 3911784kB [172074.989265] Free swap: 2751640kB [172074.993693] 255744 pages of RAM [172074.993699] 6060 reserved pages [172074.993702] 79933 pages shared [172074.993706] 56719 pages swap cached then it goes bad: [172373.542933] net/ipv4/netfilter/ip_set_nethash.c: retry: rehashing of set blockedp2pnew triggered: hashsize grows from 262144 to 288358 [172373.554837] net/ipv4/netfilter/ip_set_nethash.c: retry: rehashing of set blockedp2pnew triggered: hashsize grows from 262144 to 317193 [172373.561167] net/ipv4/netfilter/ip_set_nethash.c: retry: rehashing of set blockedp2pnew triggered: hashsize grows from 262144 to 348912 [172373.569375] net/ipv4/netfilter/ip_set_nethash.c: retry: rehashing of set blockedp2pnew triggered: hashsize grows from 262144 to 383803 [172394.471570] SysRq : Show Memory [172394.471580] Mem-info: [172394.471583] DMA per-cpu: [172394.471586] CPU0: Hot: hi:0, btch: 1 usd: 0 Cold: hi:0, btch: 1 usd: 0 [172394.471590] CPU1: Hot: hi:0, btch: 1 usd: 0 Cold: hi:0, btch: 1 usd: 0 [172394.471593] DMA32 per-cpu: [172394.471597] CPU0: Hot: hi: 186, btch: 31 usd: 152 Cold: hi: 62, btch: 15 usd: 58 [172394.471601] CPU1: Hot: hi: 186, btch: 31 usd: 108 Cold: hi: 62, btch: 15 usd: 52 [172394.471606] Active:46934 inactive:23643 dirty:0 writeback:17112 unstable:0 [172394.471608] free:133942 slab:16510 mapped:7826 pagetables:3004 bounce:0 [172394.471613] DMA free:8460kB min:32kB low:40kB high:48kB active:0kB inactive:0kB present:8620kB pages_scanned:0 all_unreclaimable? yes [172394.471616] lowmem_reserve[]: 0 968 968 [172394.471623] DMA32 free:527308kB min:3964kB low:4952kB high:5944kB active:187736kB inactive:94572kB present:991996kB pages_scanned:92 all_unreclaimable? no [172394.471627] lowmem_reserve[]: 0 0 0 [172394.471631] DMA: 154*4kB 133*8kB 78*16kB 29*32kB 12*64kB 0*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 8464kB [172394.471644] DMA32: 47127*4kB 24614*8kB 7110*16kB 751*32kB 29*64kB 2*128kB 0*256kB 2*512kB 1*1024kB 0*2048kB 0*4096kB = 527372kB [172394.471658] Swap cache: add 659497, delete 623328, find 442788/475174, race 0+5 [172394.471661] Free swap = 2571424kB [172394.471664] Total swap = 3911784kB [172394.471666] Free swap: 2571424kB [172394.476322] 255744 pages of RAM [172394.476325] 6060 reserved pages [172394.476327] 61683 pages shared [172394.476329] 36197 pages swap
Re: kernel 2.6.22: what IS the VM doing?
On Wed, Sep 05, 2007 at 18:48:51 -0400, Rik van Riel wrote: Sami Farin wrote: On Wed, Sep 05, 2007 at 12:24:26 -0400, Rik van Riel wrote: ... *shrug* The attached patch should make sure kswapd does not free an excessive number of pages in zone_normal just because the pages in zone_highmem are difficult to free. It does give kswapd a large margin to continue putting equal pressure on all zones in normal situations. Sami, could you try out this patch to see if it helps your situation? Thanks, Rik. bzImage is ready, I probably reboot inside one month for a reason or other 8-) The more I look at the bug, the more I see that it is probably not very easy to reproduce on demand. I have, however, a full Well, I now booted to x86_64 kernel. I can still reproduce this. When I unload ipset modules, kernel resumes normal operation, i.e., not swapping like mad. sysrq-m, normal operation: [172074.989053] SysRq : Show Memory [172074.989063] Mem-info: [172074.989071] DMA per-cpu: [172074.989078] CPU0: Hot: hi:0, btch: 1 usd: 0 Cold: hi:0, btch: 1 usd: 0 [172074.989083] CPU1: Hot: hi:0, btch: 1 usd: 0 Cold: hi:0, btch: 1 usd: 0 [172074.989089] DMA32 per-cpu: [172074.989094] CPU0: Hot: hi: 186, btch: 31 usd: 153 Cold: hi: 62, btch: 15 usd: 10 [172074.989101] CPU1: Hot: hi: 186, btch: 31 usd: 34 Cold: hi: 62, btch: 15 usd: 14 [172074.989109] Active:123048 inactive:55194 dirty:5 writeback:0 unstable:0 [172074.989111] free:15001 slab:27961 mapped:15063 pagetables:2996 bounce:0 [172074.989118] DMA free:5560kB min:32kB low:40kB high:48kB active:404kB inactive:736kB present:8620kB pages_scanned:0 all_unreclaimable? no [172074.989124] lowmem_reserve[]: 0 968 968 [172074.989143] DMA32 free:5kB min:3964kB low:4952kB high:5944kB active:491788kB inactive:220040kB present:991996kB pages_scanned:0 all_unreclaimable? no [172074.989150] lowmem_reserve[]: 0 0 0 [172074.989166] DMA: 276*4kB 121*8kB 30*16kB 6*32kB 0*64kB 0*128kB 1*256kB 1*512kB 2*1024kB 0*2048kB 0*4096kB = 5560kB [172074.989205] DMA32: 9467*4kB 1222*8kB 121*16kB 22*32kB 3*64kB 1*128kB 1*256kB 3*512kB 0*1024kB 1*2048kB 0*4096kB = 5kB [172074.989249] Swap cache: add 613353, delete 556659, find 441592/473681, race 0+5 [172074.989255] Free swap = 2751640kB [172074.989260] Total swap = 3911784kB [172074.989265] Free swap: 2751640kB [172074.993693] 255744 pages of RAM [172074.993699] 6060 reserved pages [172074.993702] 79933 pages shared [172074.993706] 56719 pages swap cached then it goes bad: [172373.542933] net/ipv4/netfilter/ip_set_nethash.c: retry: rehashing of set blockedp2pnew triggered: hashsize grows from 262144 to 288358 [172373.554837] net/ipv4/netfilter/ip_set_nethash.c: retry: rehashing of set blockedp2pnew triggered: hashsize grows from 262144 to 317193 [172373.561167] net/ipv4/netfilter/ip_set_nethash.c: retry: rehashing of set blockedp2pnew triggered: hashsize grows from 262144 to 348912 [172373.569375] net/ipv4/netfilter/ip_set_nethash.c: retry: rehashing of set blockedp2pnew triggered: hashsize grows from 262144 to 383803 [172394.471570] SysRq : Show Memory [172394.471580] Mem-info: [172394.471583] DMA per-cpu: [172394.471586] CPU0: Hot: hi:0, btch: 1 usd: 0 Cold: hi:0, btch: 1 usd: 0 [172394.471590] CPU1: Hot: hi:0, btch: 1 usd: 0 Cold: hi:0, btch: 1 usd: 0 [172394.471593] DMA32 per-cpu: [172394.471597] CPU0: Hot: hi: 186, btch: 31 usd: 152 Cold: hi: 62, btch: 15 usd: 58 [172394.471601] CPU1: Hot: hi: 186, btch: 31 usd: 108 Cold: hi: 62, btch: 15 usd: 52 [172394.471606] Active:46934 inactive:23643 dirty:0 writeback:17112 unstable:0 [172394.471608] free:133942 slab:16510 mapped:7826 pagetables:3004 bounce:0 [172394.471613] DMA free:8460kB min:32kB low:40kB high:48kB active:0kB inactive:0kB present:8620kB pages_scanned:0 all_unreclaimable? yes [172394.471616] lowmem_reserve[]: 0 968 968 [172394.471623] DMA32 free:527308kB min:3964kB low:4952kB high:5944kB active:187736kB inactive:94572kB present:991996kB pages_scanned:92 all_unreclaimable? no [172394.471627] lowmem_reserve[]: 0 0 0 [172394.471631] DMA: 154*4kB 133*8kB 78*16kB 29*32kB 12*64kB 0*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 8464kB [172394.471644] DMA32: 47127*4kB 24614*8kB 7110*16kB 751*32kB 29*64kB 2*128kB 0*256kB 2*512kB 1*1024kB 0*2048kB 0*4096kB = 527372kB [172394.471658] Swap cache: add 659497, delete 623328, find 442788/475174, race 0+5 [172394.471661] Free swap = 2571424kB [172394.471664] Total swap = 3911784kB [172394.471666] Free swap: 2571424kB [172394.476322] 255744 pages of RAM [172394.476325] 6060 reserved pages [172394.476327] 61683 pages shared [172394.476329] 36197 pages swap cached --- procs ---memory-- ---swap-- -io --system-- -cpu-- r b swpd free buff cache si sobibo
Re: [PATCH/RFC] doc: about email clients for Linux kernel patches
On Tue, Sep 11, 2007 at 14:38:13 -0400, Lee Revell wrote: > You can also diff -Nru old.c new.c | xclip, select Preformat, then > paste with the middle button. mutt does not come with text editor, so I'd like to add note about vim: If using xclip, type command :set paste before middle button or shift-insert or use :r filename ...if you want to include patch inline. (a)ttach works fine without "set paste". -- Do what you love because life is too short for anything else. pgp9tnOcB12Bo.pgp Description: PGP signature
Re: [PATCH/RFC] doc: about email clients for Linux kernel patches
On Tue, Sep 11, 2007 at 14:38:13 -0400, Lee Revell wrote: You can also diff -Nru old.c new.c | xclip, select Preformat, then paste with the middle button. mutt does not come with text editor, so I'd like to add note about vim: If using xclip, type command :set paste before middle button or shift-insert or use :r filename ...if you want to include patch inline. (a)ttach works fine without set paste. -- Do what you love because life is too short for anything else. pgp9tnOcB12Bo.pgp Description: PGP signature
Re: Broken mail setup
On Mon, Sep 10, 2007 at 14:39:34 +0100, Alan Cox wrote: ... > > Well, outpipe-village-512-1.bc.nu is NXDOMAIN. > > It should have A record 81.2.110.250. > > I've yet to see a specification which requires this. You don't need specs. My point was you might have better luck emailing people if you have that A record. -- Do what you love because life is too short for anything else. - 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: Broken mail setup
On Mon, Sep 10, 2007 at 13:59:12 +0100, Alan Cox wrote: > Will RMK ([EMAIL PROTECTED]) please fix his email setup otherwise I > can't send serial/tty/arm stuff to him. > > "<<< 550 You have no reverse DNS; please try again when you have resolved Well, outpipe-village-512-1.bc.nu is NXDOMAIN. It should have A record 81.2.110.250. > that error 554 5.0.0 Service unavailable" > Difficult to tell what you've got wrong but the delivering host does have > a reverse DNS, and the mail address is an MX so if you are trying to turn > that into a reverse A record you have some problems with your scripts. > > Alan -- Do what you love because life is too short for anything else. - 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: Broken mail setup
On Mon, Sep 10, 2007 at 13:59:12 +0100, Alan Cox wrote: Will RMK ([EMAIL PROTECTED]) please fix his email setup otherwise I can't send serial/tty/arm stuff to him. 550 You have no reverse DNS; please try again when you have resolved Well, outpipe-village-512-1.bc.nu is NXDOMAIN. It should have A record 81.2.110.250. that error 554 5.0.0 Service unavailable Difficult to tell what you've got wrong but the delivering host does have a reverse DNS, and the mail address is an MX so if you are trying to turn that into a reverse A record you have some problems with your scripts. Alan -- Do what you love because life is too short for anything else. - 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: Broken mail setup
On Mon, Sep 10, 2007 at 14:39:34 +0100, Alan Cox wrote: ... Well, outpipe-village-512-1.bc.nu is NXDOMAIN. It should have A record 81.2.110.250. I've yet to see a specification which requires this. You don't need specs. My point was you might have better luck emailing people if you have that A record. -- Do what you love because life is too short for anything else. - 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: kernel 2.6.22: what IS the VM doing?
On Wed, Sep 05, 2007 at 12:24:26 -0400, Rik van Riel wrote: ... >> *shrug* > > The attached patch should make sure kswapd does not free an > excessive number of pages in zone_normal just because the > pages in zone_highmem are difficult to free. > > It does give kswapd a large margin to continue putting equal > pressure on all zones in normal situations. > > Sami, could you try out this patch to see if it helps your > situation? Thanks, Rik. bzImage is ready, I probably reboot inside one month for a reason or other 8-) -- Do what you love because life is too short for anything else. - 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: kernel 2.6.22: what IS the VM doing?
On Tue, Sep 04, 2007 at 21:37:35 -0400, Rik van Riel wrote: > Sami Farin wrote: >> Using SMP kernel 2.6.22.6pre-CFS-v20.5 on Pentium D (IA-32). >> I think this bug (or whatever you want to call it) got triggered >> when you first allocate several megabytes of memory in a kernel module >> and then free them, and then run e.g. X and when memory gets tight, >> you end up with this situation... >> Top 2 /proc/vmstat Biggest Winners: >> pgrefill_normal:49900/second >> pgrefill_high:20810/second > > That means the pageout code was scanning about 7 pages > per second on your system during peak stress. You may have > run into a scalability problem in the Linux kernel, where it > wants to clear the referenced bit off all the anonymous pages > before swapping something out. Thanks for analysis... Why turning off swap did not make any difference? Why does is not keep e.g. xterm in memory (which I had 700MB free)? > To make matters worse, that unlucky page gets chosen because > it was the page where kswapd started scanning. It has little > to do with being the least recently used page, because every > anonymous page tends to have its referenced bit set by the time > we start scanning. > > On truly enormous systems, say with 256GB of memory, kswapd > sometimes needs to scan hundreds of thousands or even millions > of pages before finding something to swap out. Not fun. > >> Did I forget to include some info??? >> Oh, and I need to reboot in order to get usable system >> when this bug happens. > > Is the system trying to evict pages like crazy when your > system becomes unusable? I think so.. > If so, I wonder if kswapd is simply doing the wrong thing > and trying to evict data from all zones, simply because the > highmem zone is low on free pages... *shrug* -- "If we put the Pentagon's personnel managers in charge of the Sahara Desert, they would run out of sand in five years." -Sayen Report - 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: kernel 2.6.22: what IS the VM doing?
On Tue, Sep 04, 2007 at 21:37:35 -0400, Rik van Riel wrote: Sami Farin wrote: Using SMP kernel 2.6.22.6pre-CFS-v20.5 on Pentium D (IA-32). I think this bug (or whatever you want to call it) got triggered when you first allocate several megabytes of memory in a kernel module and then free them, and then run e.g. X and when memory gets tight, you end up with this situation... Top 2 /proc/vmstat Biggest Winners: pgrefill_normal:49900/second pgrefill_high:20810/second That means the pageout code was scanning about 7 pages per second on your system during peak stress. You may have run into a scalability problem in the Linux kernel, where it wants to clear the referenced bit off all the anonymous pages before swapping something out. Thanks for analysis... Why turning off swap did not make any difference? Why does is not keep e.g. xterm in memory (which I had 700MB free)? To make matters worse, that unlucky page gets chosen because it was the page where kswapd started scanning. It has little to do with being the least recently used page, because every anonymous page tends to have its referenced bit set by the time we start scanning. On truly enormous systems, say with 256GB of memory, kswapd sometimes needs to scan hundreds of thousands or even millions of pages before finding something to swap out. Not fun. Did I forget to include some info??? Oh, and I need to reboot in order to get usable system when this bug happens. Is the system trying to evict pages like crazy when your system becomes unusable? I think so.. If so, I wonder if kswapd is simply doing the wrong thing and trying to evict data from all zones, simply because the highmem zone is low on free pages... *shrug* -- If we put the Pentagon's personnel managers in charge of the Sahara Desert, they would run out of sand in five years. -Sayen Report - 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: kernel 2.6.22: what IS the VM doing?
On Wed, Sep 05, 2007 at 12:24:26 -0400, Rik van Riel wrote: ... *shrug* The attached patch should make sure kswapd does not free an excessive number of pages in zone_normal just because the pages in zone_highmem are difficult to free. It does give kswapd a large margin to continue putting equal pressure on all zones in normal situations. Sami, could you try out this patch to see if it helps your situation? Thanks, Rik. bzImage is ready, I probably reboot inside one month for a reason or other 8-) -- Do what you love because life is too short for anything else. - 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/
kernel 2.6.22: what IS the VM doing?
Using SMP kernel 2.6.22.6pre-CFS-v20.5 on Pentium D (IA-32). I think this bug (or whatever you want to call it) got triggered when you first allocate several megabytes of memory in a kernel module and then free them, and then run e.g. X and when memory gets tight, you end up with this situation... Top 2 /proc/vmstat Biggest Winners: pgrefill_normal:49900/second pgrefill_high:20810/second $ vmstat 1 procs ---memory-- ---swap-- -io --system-- -cpu-- r b swpd free buff cache si sobibo incs us sy id wa st 0 1 326020 861476 0 7384 2360 392 0 68 1100 1 1 45 54 0 0 1 326020 861860 0 7216 64 14064 148 68 1137 0 0 48 51 0 0 1 326020 862696 0 6772 960 108 4 55 1069 0 1 48 51 0 0 3 326024 861352 0 8080 752 300 2540 308 191 1202 1 3 37 59 0 0 2 326024 857464 0 9340 27680 536440 228 1589 0 2 20 77 0 0 3 326396 857772 0 8408 1280 656 2580 664 203 1589 1 3 20 78 0 0 3 326376 855768 0 9864 14480 3632 0 167 1488 1 2 11 87 0 0 3 326084 854000 0 10712 18480 3228 0 180 1515 1 3 1 95 0 0 1 326084 854204 0 10052 6280 776 0 98 1324 1 1 38 61 0 0 1 326084 855476 0 8644 1000 33252 81 1065 1 1 48 51 0 0 2 326084 856444 0 8180 880 396 0 84 1195 1 2 38 60 0 0 2 319072 849068 0 9572 70080 8548 0 1820 8460 1 18 15 68 0 2 3 303888 835724 0 8864 149000 15100 8 3800 15863 1 27 29 44 0 around here I rand swapoff -a 0 2 289024 822352 0 7724 146880 14840 4 3706 17628 1 25 13 61 0 0 4 270728 805104 0 7644 173840 17656 8 4388 19984 0 25 19 55 0 0 3 255216 789884 0 7296 157320 15892 8 3932 19146 1 22 24 54 0 2 3 241188 776476 0 6748 141920 14732 4 3550 16584 1 21 0 78 0 2 4 224708 760320 0 7152 165520 17460 0 4142 18909 1 22 0 77 0 2 4 211624 748112 0 6996 127160 13496 8 3226 14975 0 19 9 71 0 0 4 196352 733304 0 7464 152680 1616816 3816 18359 1 25 0 74 0 2 4 179580 716516 0 7112 170280 17776 9 4261 20913 1 26 6 67 0 procs ---memory-- ---swap-- -io --system-- -cpu-- r b swpd free buff cache si sobibo incs us sy id wa st 0 4 164692 701644 0 7168 148480 16276 8 3732 16751 0 19 0 80 0 2 5 151980 688480 0 8140 127920 13872 0 3196 15417 0 24 0 75 0 0 6 135712 672272 0 8036 164960 17484 0 4036 18392 1 22 0 78 0 0 4 122128 658556 0 8116 136160 1474812 3374 16222 0 23 0 77 0 0 4 109360 646788 0 7632 126480 13164 4 3176 15188 0 24 3 72 0 2 5 92496 630396 0 7480 168600 17460 4 4215 19614 1 24 5 71 0 0 6 78620 617316 0 7944 126880 13940 0 3229 14086 1 21 0 79 0 3 3 64760 603536 0 7980 136920 14576 8 3455 16508 1 20 2 76 0 0 4 50728 589352 0 8868 135520 1539620 3474 15373 0 20 2 77 0 1 4 36088 575916 0 7724 146760 15208 4 3726 17567 0 27 0 72 0 2 2 22896 562900 0 7748 129520 13732 0 3311 14979 1 20 0 80 0 2 4 6108 547560 0 8044 151640 16300 0 3865 16899 1 24 40 35 0 0 1 0 545740192 7620 38320 558865 1108 6072 1 8 38 54 0 0 2 0 545652148 760800 332 0 63 1006 0 1 50 50 0 0 1 0 545048 44 834400 1976 0 103 1542 1 2 42 57 0 0 2 0 544168 0 949200 2764 4 105 1523 0 3 45 52 0 0 1 0 543812 0 964400 1584 8 113 1397 1 2 47 51 0 0 1 0 543836 0 950800 396 0 66 955 1 1 50 49 0 0 1 0 544288 0 913200 8 1 53 813 0 1 50 49 0 0 1 0 545216 0 816800 392 0 72 1489 1 1 50 48 0 0 1 0 545684 0 749600 124 8 59 1275 1 2 47 51 0 0 1 0 545160 0 802000 856 8 60 951 0 2 46 51 0 0 1 0 543396 0 1005600 3144 0 146 1545 1 2 24 74 0 well did not make much difference, $ vmstat 1 -a procs ---memory-- ---swap-- -io --system-- -cpu-- r b swpd free inact active si sobibo incs us sy id wa st 0 1 326084 854204 3176 18896 6280 776 0 97 1324 1 1 38 61 0 0 1 326084 855476 2936 17696 1000 33252 82 1065 1 1 48 51 0 0 2 326084 856444 2536 17156 880 396 0 84 1195 1 2 38 60 0 1 1 319076 849068 2676 24404 70040 8544 0 1820 8459 1 18 15 68 0 2 3 303920 835744 1388
kernel 2.6.22: what IS the VM doing?
Using SMP kernel 2.6.22.6pre-CFS-v20.5 on Pentium D (IA-32). I think this bug (or whatever you want to call it) got triggered when you first allocate several megabytes of memory in a kernel module and then free them, and then run e.g. X and when memory gets tight, you end up with this situation... Top 2 /proc/vmstat Biggest Winners: pgrefill_normal:49900/second pgrefill_high:20810/second $ vmstat 1 procs ---memory-- ---swap-- -io --system-- -cpu-- r b swpd free buff cache si sobibo incs us sy id wa st 0 1 326020 861476 0 7384 2360 392 0 68 1100 1 1 45 54 0 0 1 326020 861860 0 7216 64 14064 148 68 1137 0 0 48 51 0 0 1 326020 862696 0 6772 960 108 4 55 1069 0 1 48 51 0 0 3 326024 861352 0 8080 752 300 2540 308 191 1202 1 3 37 59 0 0 2 326024 857464 0 9340 27680 536440 228 1589 0 2 20 77 0 0 3 326396 857772 0 8408 1280 656 2580 664 203 1589 1 3 20 78 0 0 3 326376 855768 0 9864 14480 3632 0 167 1488 1 2 11 87 0 0 3 326084 854000 0 10712 18480 3228 0 180 1515 1 3 1 95 0 0 1 326084 854204 0 10052 6280 776 0 98 1324 1 1 38 61 0 0 1 326084 855476 0 8644 1000 33252 81 1065 1 1 48 51 0 0 2 326084 856444 0 8180 880 396 0 84 1195 1 2 38 60 0 0 2 319072 849068 0 9572 70080 8548 0 1820 8460 1 18 15 68 0 2 3 303888 835724 0 8864 149000 15100 8 3800 15863 1 27 29 44 0 around here I rand swapoff -a 0 2 289024 822352 0 7724 146880 14840 4 3706 17628 1 25 13 61 0 0 4 270728 805104 0 7644 173840 17656 8 4388 19984 0 25 19 55 0 0 3 255216 789884 0 7296 157320 15892 8 3932 19146 1 22 24 54 0 2 3 241188 776476 0 6748 141920 14732 4 3550 16584 1 21 0 78 0 2 4 224708 760320 0 7152 165520 17460 0 4142 18909 1 22 0 77 0 2 4 211624 748112 0 6996 127160 13496 8 3226 14975 0 19 9 71 0 0 4 196352 733304 0 7464 152680 1616816 3816 18359 1 25 0 74 0 2 4 179580 716516 0 7112 170280 17776 9 4261 20913 1 26 6 67 0 procs ---memory-- ---swap-- -io --system-- -cpu-- r b swpd free buff cache si sobibo incs us sy id wa st 0 4 164692 701644 0 7168 148480 16276 8 3732 16751 0 19 0 80 0 2 5 151980 688480 0 8140 127920 13872 0 3196 15417 0 24 0 75 0 0 6 135712 672272 0 8036 164960 17484 0 4036 18392 1 22 0 78 0 0 4 122128 658556 0 8116 136160 1474812 3374 16222 0 23 0 77 0 0 4 109360 646788 0 7632 126480 13164 4 3176 15188 0 24 3 72 0 2 5 92496 630396 0 7480 168600 17460 4 4215 19614 1 24 5 71 0 0 6 78620 617316 0 7944 126880 13940 0 3229 14086 1 21 0 79 0 3 3 64760 603536 0 7980 136920 14576 8 3455 16508 1 20 2 76 0 0 4 50728 589352 0 8868 135520 1539620 3474 15373 0 20 2 77 0 1 4 36088 575916 0 7724 146760 15208 4 3726 17567 0 27 0 72 0 2 2 22896 562900 0 7748 129520 13732 0 3311 14979 1 20 0 80 0 2 4 6108 547560 0 8044 151640 16300 0 3865 16899 1 24 40 35 0 0 1 0 545740192 7620 38320 558865 1108 6072 1 8 38 54 0 0 2 0 545652148 760800 332 0 63 1006 0 1 50 50 0 0 1 0 545048 44 834400 1976 0 103 1542 1 2 42 57 0 0 2 0 544168 0 949200 2764 4 105 1523 0 3 45 52 0 0 1 0 543812 0 964400 1584 8 113 1397 1 2 47 51 0 0 1 0 543836 0 950800 396 0 66 955 1 1 50 49 0 0 1 0 544288 0 913200 8 1 53 813 0 1 50 49 0 0 1 0 545216 0 816800 392 0 72 1489 1 1 50 48 0 0 1 0 545684 0 749600 124 8 59 1275 1 2 47 51 0 0 1 0 545160 0 802000 856 8 60 951 0 2 46 51 0 0 1 0 543396 0 1005600 3144 0 146 1545 1 2 24 74 0 well did not make much difference, $ vmstat 1 -a procs ---memory-- ---swap-- -io --system-- -cpu-- r b swpd free inact active si sobibo incs us sy id wa st 0 1 326084 854204 3176 18896 6280 776 0 97 1324 1 1 38 61 0 0 1 326084 855476 2936 17696 1000 33252 82 1065 1 1 48 51 0 0 2 326084 856444 2536 17156 880 396 0 84 1195 1 2 38 60 0 1 1 319076 849068 2676 24404 70040 8544 0 1820 8459 1 18 15 68 0 2 3 303920 835744 1388
Re: Kernel oops during netfilter memory allocation
On Wed, Aug 22, 2007 at 17:09:04 +0200, Thomas Jarosch wrote: > Hello, > > > > kernel BUG at arch/i386/mm/highmem.c:38 > > > > > > Try this. > > I just tried kernel 2.6.22.4 and 2.6.23-rc3. Using 2.6.23-rc3 vanilla, > the box survives only 3 seconds with ipt_CRASH. Here's the backtrace, > it's only slightly different: > > [ cut here ] > kernel BUG at arch/i386/mm/highmem.c:38! > invalid opcode: [#1] > Modules linked in: ipt_CRASH iptable_filter ip_tables x_tables deflate > zlib_deflate twofish twofish_common serpent blowfish des cbc ecb blkcipher > aes xcbcd What are you using crypto stuff for? Hopefully you are not calling crypto functions from IRQ context. -- Do what you love because life is too short for anything else. - 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: Kernel oops during netfilter memory allocation
On Wed, Aug 22, 2007 at 17:09:04 +0200, Thomas Jarosch wrote: Hello, kernel BUG at arch/i386/mm/highmem.c:38 Try this. I just tried kernel 2.6.22.4 and 2.6.23-rc3. Using 2.6.23-rc3 vanilla, the box survives only 3 seconds with ipt_CRASH. Here's the backtrace, it's only slightly different: [ cut here ] kernel BUG at arch/i386/mm/highmem.c:38! invalid opcode: [#1] Modules linked in: ipt_CRASH iptable_filter ip_tables x_tables deflate zlib_deflate twofish twofish_common serpent blowfish des cbc ecb blkcipher aes xcbcd What are you using crypto stuff for? Hopefully you are not calling crypto functions from IRQ context. -- Do what you love because life is too short for anything else. - 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/
Linux 2.6.22: had to reboot after OOM
After I got this error [1], system got real slow, like 386 having 32 MB of RAM and swapping constantly. My system is P4 SMP with 1GB of RAM. I got this same behavior with 2.6.19, too, but then I used GNU cp v6.9 which had micro-optimization which did not bother doing read() for regular files, like /proc/vmstat , instead, it generated 0-byte destination file (I noticed that only after rebooting). So I do not have useful debug info for 2.6.19. And now my version of cp does not have that micro-optimization. I also attached vmstat and slabinfo , in case somebody can figure out something out of them. I also now use --probes=5 for ipset nethash... uses less mem but is slower. procs ---memory-- ---swap-- -io --system-- -cpu-- r b swpd free buff cache si sobibo incs us sy id wa st 0 2 762376 748392 0 17104 1185265 6453 10 3 85 3 0 0 3 762376 748664 0 17144 456 12 90824 237 3044 2 3 26 70 0 0 2 762376 749544 0 16492 464 284 1440 288 248 3633 2 5 14 79 0 0 3 762376 749916 0 16392 4320 136816 239 3360 1 2 5 93 0 0 3 762376 751108 0 15740 512 432 1656 460 214 3751 1 3 28 69 0 0 7 762376 751740 0 15512 532 104 1920 131 237 4014 2 4 5 90 0 0 10 762436 755064 0 15652 200 3172 992 3264 274 5086 1 3 1 96 0 0 11 762504 757208 0 15156 144 836 624 926 204 2602 1 2 0 98 0 0 13 762680 766384 0 12740 36 728496 7308 252 8643 0 5 0 95 0 0 14 762772 771312 0 11696 12 3908 132 3912 253 5153 0 3 0 97 0 0 13 763044 778536 0 10356 184 8088 572 8088 249 6889 1 3 0 97 0 0 15 763092 781380 0 102840 2136 532 2160 176 2387 1 2 0 98 0 0 16 763360 785428 0 10008 60 4884 1312 4985 281 4798 0 5 0 96 0 0 19 763636 791192 0 8548 24 6264 476 6268 219 6732 0 3 0 97 0 0 18 763824 799184 0 62400 750052 7504 217 7080 1 6 0 94 0 0 18 763872 802196 0 58160 2628 552 2640 194 3851 0 4 0 96 0 0 28 764048 805072 0 5168 92 1760 1180 1772 185 2703 0 5 0 94 0 0 30 764048 806032 0 5256 36 164 364 234 126 1448 0 1 0 99 0 0 31 764048 807728 0 4732 32 409284 152 1824 0 3 0 97 0 0 35 764056 809372 0 4332 1100 532 9084 804 194 1986 0 7 0 94 0 0 74 764012 839544 0 8100 16040 566012 4216 46853 0 8 0 92 0 procs ---memory-- ---swap-- -io --system-- -cpu-- r b swpd free inact active si sobibo incs us sy id wa st 0 14 762504 757108 4004 90724 1185265 6453 10 3 85 3 0 0 13 762676 764608 8768 78084 44 6324 288 6370 251 7697 0 4 0 95 0 0 14 762772 770832 12404 68328 12 4868 128 4880 243 6161 0 4 0 96 0 0 13 763044 778536 24248 48736 180 7908 548 7912 296 7208 0 3 0 97 0 0 16 763092 781380 21196 490044 2312 560 2336 185 2524 1 1 0 98 0 0 16 763360 784584 40040 27048 60 4088 1312 4189 267 3964 0 4 0 96 0 0 19 763636 791192 36552 23804 24 7064 392 7068 227 7600 0 4 0 96 0 0 18 763824 798896 36928 155680 7352 136 7356 219 6902 0 5 0 94 0 0 19 763872 802088 41372 78760 2776 548 2788 195 3917 0 4 0 96 0 0 25 764048 804636 39896 6932 56 1760 920 1772 170 2602 0 4 0 95 0 0 30 764048 806032 39308 6272 72 164 628 234 131 1579 0 2 0 98 0 0 30 764048 807500 38316 5768 32 408468 149 1630 0 2 0 98 0 1 34 764056 808476 37900 5444 20 192 660 242 184 1883 0 6 0 94 0 1 37 764056 811148 38772 1740 20 100 388 104 168 2409 0 5 0 95 0 0 38 764056 813056 34164 453600 12447 227 2590 0 6 0 94 0 0 38 764056 815500 32924 3308 400 608 5 228 2448 0 4 0 96 0 10 37 764056 817764 30404 38000 16 26020 323 3795 0 10 0 90 0 1 37 764056 819548 28552 37440 20 14856 207 2275 0 6 0 94 0 1 38 764056 820828 27004 4028 208 49621 216 1703 0 3 0 97 0 0 71 764056 820064 28228 3508 6000 1424 4 140 826 0 2 0 99 0 0 73 764028 822568 25928 3404 68 36 33248 205 2223 0 5 0 95 0 As a comparison, these are stats after booting, with similar workload: procs ---memory-- ---swap-- -io --system-- -cpu-- r b swpd free buff cache si sobibo incs us sy id wa st 2 0 290544 12728 0 4442162 13 213 285 144 922 7 2 82 9 0 0 0 290544 12672 0 4442640016 1616 270 1881 2 2 96 0 0 0 0 290544 12752 0 444280001656 245 1687 2 2 96 1 0 0 0 290544 12876 0 44428000 0
Linux 2.6.22: had to reboot after OOM
After I got this error [1], system got real slow, like 386 having 32 MB of RAM and swapping constantly. My system is P4 SMP with 1GB of RAM. I got this same behavior with 2.6.19, too, but then I used GNU cp v6.9 which had micro-optimization which did not bother doing read() for regular files, like /proc/vmstat , instead, it generated 0-byte destination file (I noticed that only after rebooting). So I do not have useful debug info for 2.6.19. And now my version of cp does not have that micro-optimization. I also attached vmstat and slabinfo , in case somebody can figure out something out of them. I also now use --probes=5 for ipset nethash... uses less mem but is slower. procs ---memory-- ---swap-- -io --system-- -cpu-- r b swpd free buff cache si sobibo incs us sy id wa st 0 2 762376 748392 0 17104 1185265 6453 10 3 85 3 0 0 3 762376 748664 0 17144 456 12 90824 237 3044 2 3 26 70 0 0 2 762376 749544 0 16492 464 284 1440 288 248 3633 2 5 14 79 0 0 3 762376 749916 0 16392 4320 136816 239 3360 1 2 5 93 0 0 3 762376 751108 0 15740 512 432 1656 460 214 3751 1 3 28 69 0 0 7 762376 751740 0 15512 532 104 1920 131 237 4014 2 4 5 90 0 0 10 762436 755064 0 15652 200 3172 992 3264 274 5086 1 3 1 96 0 0 11 762504 757208 0 15156 144 836 624 926 204 2602 1 2 0 98 0 0 13 762680 766384 0 12740 36 728496 7308 252 8643 0 5 0 95 0 0 14 762772 771312 0 11696 12 3908 132 3912 253 5153 0 3 0 97 0 0 13 763044 778536 0 10356 184 8088 572 8088 249 6889 1 3 0 97 0 0 15 763092 781380 0 102840 2136 532 2160 176 2387 1 2 0 98 0 0 16 763360 785428 0 10008 60 4884 1312 4985 281 4798 0 5 0 96 0 0 19 763636 791192 0 8548 24 6264 476 6268 219 6732 0 3 0 97 0 0 18 763824 799184 0 62400 750052 7504 217 7080 1 6 0 94 0 0 18 763872 802196 0 58160 2628 552 2640 194 3851 0 4 0 96 0 0 28 764048 805072 0 5168 92 1760 1180 1772 185 2703 0 5 0 94 0 0 30 764048 806032 0 5256 36 164 364 234 126 1448 0 1 0 99 0 0 31 764048 807728 0 4732 32 409284 152 1824 0 3 0 97 0 0 35 764056 809372 0 4332 1100 532 9084 804 194 1986 0 7 0 94 0 0 74 764012 839544 0 8100 16040 566012 4216 46853 0 8 0 92 0 procs ---memory-- ---swap-- -io --system-- -cpu-- r b swpd free inact active si sobibo incs us sy id wa st 0 14 762504 757108 4004 90724 1185265 6453 10 3 85 3 0 0 13 762676 764608 8768 78084 44 6324 288 6370 251 7697 0 4 0 95 0 0 14 762772 770832 12404 68328 12 4868 128 4880 243 6161 0 4 0 96 0 0 13 763044 778536 24248 48736 180 7908 548 7912 296 7208 0 3 0 97 0 0 16 763092 781380 21196 490044 2312 560 2336 185 2524 1 1 0 98 0 0 16 763360 784584 40040 27048 60 4088 1312 4189 267 3964 0 4 0 96 0 0 19 763636 791192 36552 23804 24 7064 392 7068 227 7600 0 4 0 96 0 0 18 763824 798896 36928 155680 7352 136 7356 219 6902 0 5 0 94 0 0 19 763872 802088 41372 78760 2776 548 2788 195 3917 0 4 0 96 0 0 25 764048 804636 39896 6932 56 1760 920 1772 170 2602 0 4 0 95 0 0 30 764048 806032 39308 6272 72 164 628 234 131 1579 0 2 0 98 0 0 30 764048 807500 38316 5768 32 408468 149 1630 0 2 0 98 0 1 34 764056 808476 37900 5444 20 192 660 242 184 1883 0 6 0 94 0 1 37 764056 811148 38772 1740 20 100 388 104 168 2409 0 5 0 95 0 0 38 764056 813056 34164 453600 12447 227 2590 0 6 0 94 0 0 38 764056 815500 32924 3308 400 608 5 228 2448 0 4 0 96 0 10 37 764056 817764 30404 38000 16 26020 323 3795 0 10 0 90 0 1 37 764056 819548 28552 37440 20 14856 207 2275 0 6 0 94 0 1 38 764056 820828 27004 4028 208 49621 216 1703 0 3 0 97 0 0 71 764056 820064 28228 3508 6000 1424 4 140 826 0 2 0 99 0 0 73 764028 822568 25928 3404 68 36 33248 205 2223 0 5 0 95 0 As a comparison, these are stats after booting, with similar workload: procs ---memory-- ---swap-- -io --system-- -cpu-- r b swpd free buff cache si sobibo incs us sy id wa st 2 0 290544 12728 0 4442162 13 213 285 144 922 7 2 82 9 0 0 0 290544 12672 0 4442640016 1616 270 1881 2 2 96 0 0 0 0 290544 12752 0 444280001656 245 1687 2 2 96 1 0 0 0 290544 12876 0 44428000 0
Re: oprofile / selinux / security_port_sid
On Tue, Mar 27, 2007 at 09:40:23 -0400, Stephen Smalley wrote: > On Tue, 2007-03-27 at 13:06 +0300, Sami Farin wrote: > > is there room for improvement in security_port_sid() ? > > Yes, lots of room. Also, it won't get called per-packet if you enable > secmark (echo 0 > /selinux/compat_net or boot with selinux_compat_net=0 > or build with SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT), although that > may require updating your policy. Hmm, test was done with CONFIG_NETWORK_SECMARK=y CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=y and /selinux/compat_net = 0 -- Do what you love because life is too short for anything else. - 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/
oprofile / selinux / security_port_sid
is there room for improvement in security_port_sid() ? little test with dns queries (dnsfilter (the client) on local host using poll() and dnscache (the server) using epoll (at max 4000 concurrent queries): (stats for only vmlinux) CPU: P4 / Xeon, speed 2797.32 MHz (estimated) Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 45000 Counted FSB_DATA_ACTIVITY events (DRDY or DBSY events on the front side bus) with a unit mask of 0x03 (multiple flags) count 45000 Counted BRANCH_RETIRED events (retired branches) with a unit mask of 0x05 (multiple flags) count 45000 Counted BRANCH_RETIRED events (retired branches) with a unit mask of 0x0a (multiple flags) count 45000 samples %samples %samples %samples %symbol name 220663 10.2181 6704 17.9737 5735 7.5171 271.1989 datagram_poll 1400866.4869 3239 8.6839 3786 4.9624 241.0657 sock_poll 1196365.5399 2172 5.8232 7168 9.3954 241.0657 do_poll 1015124.7006 3987 10.6893 812 1.0643 140.6217 udp_get_port 71008 3.2881 1017 2.7266 2694 3.5311 397 17.6288 security_port_sid 64350 2.9798 144 0.3861 1912 2.5061 6 0.2664 add_wait_queue 60815 2.8161 187 0.5014 3246 4.2546 2 0.0888 remove_wait_queue 47456 2.1975 1823 4.8875 476 0.6239 311.3766 udp_v4_lookup_longway if dnsfilter had used epoll, security_port_sid would probably (?) be number one (or two or three) CPU user in kernel. also note that 17.6% of mispredicted branches occurr in security_port_sid. -- Do what you love because life is too short for anything else. - 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/
oprofile / selinux / security_port_sid
is there room for improvement in security_port_sid() ? little test with dns queries (dnsfilter (the client) on local host using poll() and dnscache (the server) using epoll (at max 4000 concurrent queries): (stats for only vmlinux) CPU: P4 / Xeon, speed 2797.32 MHz (estimated) Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 45000 Counted FSB_DATA_ACTIVITY events (DRDY or DBSY events on the front side bus) with a unit mask of 0x03 (multiple flags) count 45000 Counted BRANCH_RETIRED events (retired branches) with a unit mask of 0x05 (multiple flags) count 45000 Counted BRANCH_RETIRED events (retired branches) with a unit mask of 0x0a (multiple flags) count 45000 samples %samples %samples %samples %symbol name 220663 10.2181 6704 17.9737 5735 7.5171 271.1989 datagram_poll 1400866.4869 3239 8.6839 3786 4.9624 241.0657 sock_poll 1196365.5399 2172 5.8232 7168 9.3954 241.0657 do_poll 1015124.7006 3987 10.6893 812 1.0643 140.6217 udp_get_port 71008 3.2881 1017 2.7266 2694 3.5311 397 17.6288 security_port_sid 64350 2.9798 144 0.3861 1912 2.5061 6 0.2664 add_wait_queue 60815 2.8161 187 0.5014 3246 4.2546 2 0.0888 remove_wait_queue 47456 2.1975 1823 4.8875 476 0.6239 311.3766 udp_v4_lookup_longway if dnsfilter had used epoll, security_port_sid would probably (?) be number one (or two or three) CPU user in kernel. also note that 17.6% of mispredicted branches occurr in security_port_sid. -- Do what you love because life is too short for anything else. - 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: oprofile / selinux / security_port_sid
On Tue, Mar 27, 2007 at 09:40:23 -0400, Stephen Smalley wrote: On Tue, 2007-03-27 at 13:06 +0300, Sami Farin wrote: is there room for improvement in security_port_sid() ? Yes, lots of room. Also, it won't get called per-packet if you enable secmark (echo 0 /selinux/compat_net or boot with selinux_compat_net=0 or build with SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT), although that may require updating your policy. Hmm, test was done with CONFIG_NETWORK_SECMARK=y CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=y and /selinux/compat_net = 0 -- Do what you love because life is too short for anything else. - 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/
Linux 2.6.19.7 + oprofile = BUG: unable to handle kernel NULL pointer dereference at virtual address 00000020
Not sure if this is oprofile's fault, but I got this when I started opreport. 10 min after BUG system needed to be rebooted (cycling power). With earlier kernel (without oprofile) everything worked for a month without hiccups. [295318.822839] BUG: unable to handle kernel NULL pointer dereference at virtual address 0020 [295318.822847] printing eip: [295318.822850] c0182530 [295318.822852] *pde = 2ed68001 [295318.822858] *pte = [295318.822862] Oops: [#1] [295318.822864] SMP [295318.822867] Modules linked in: oprofile perfctr dccp_diag dccp_ccid2 dccp_ipv4 i915 dccp xt_CLASSIFY ipt_ECN xt_CONNMARK ipt_connlimit ipt_TARPIT xt_length ipt_set xt_multiport ip_set_iphash ip_set_nethash ip_set_portmap sch_esfq ipt_REJECT ip6t_LOG xt_limit ipt_LOG ipt_hashlimit ip6table_mangle iptable_mangle iptable_raw ipt_owner xt_tcpudp xt_state ip_conntrack ip6table_filter ip6_tables iptable_filter ip_tables x_tables tcp_highspeed tcp_htcp tcp_hybla tcp_scalable tcp_vegas tcp_westwood ip_set sch_netem sch_hfsc sch_htb sch_sfq cls_fw cls_u32 cls_route sch_ingress sch_red sch_tbf sch_teql sch_prio sch_gred cls_rsvp cls_rsvp6 cls_tcindex sch_cbq sch_dsmark ioatdma cmtp kernelcapi l2cap bluetooth intelfb i2c_algo_bit i810 i2c_dev usb_storage eeprom ohci_hcd irlan irda crc_ccitt binfmt_misc loop dm_mod video button battery asus_acpi ac tcp_cubic lp nvram snd_hda_intel snd_hda_codec snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ohci1394 i2c_i801 snd_pcm ieee1394 pcspkr snd_timer snd i2c_core soundcore iTCO_wdt ehci_hcd snd_page_alloc e1000 parport_pc parport uhci_hcd [295318.822998] CPU:0 [295318.822999] EIP:0060:[]Not tainted VLI [295318.823000] EFLAGS: 00010282 (2.6.19.7-exec-shield-1 #137) [295318.823008] EIP is at iput+0x17/0x69 [295318.823016] eax: ebx: cafdd31c ecx: cafdd334 edx: cafdd334 [295318.823019] esi: cafdd31c edi: 003f ebp: c1ac7e64 esp: c1ac7e60 [295318.823022] ds: 007b es: 007b ss: 0068 [295318.823026] Process kswapd0 (pid: 217, ti=c1ac6000 task=c1a12550 task.ti=c1ac6000) [295318.823029] Stack: ddbcc42c c1ac7e7c c017f259 c1ac7e7c c017f2c6 ddbcc42c ddbcc42c c1ac7e8c [295318.823042]c017f6d3 f7624c3c ddbcc42c c1ac7ea4 c017f7f3 4970 [295318.823059]0086 c1ac7eac c017fd29 c1ac7ef8 c0155fc0 c0592680 [295318.823068] Call Trace: [295318.823358] [] dentry_iput+0x53/0x9f [295318.823627] [] prune_one_dentry+0x57/0x7a [295318.823900] [] prune_dcache+0xfd/0x152 [295318.824177] [] shrink_dcache_memory+0x19/0x3d [295318.824446] [] shrink_slab+0x123/0x1b5 [295318.824652] [] balance_pgdat+0x203/0x30b [295318.824852] [] kswapd+0xba/0x10a [295318.825064] [] kthread+0xa0/0xcd [295318.825209] [] kernel_thread_helper+0x7/0x10 [295318.825237] === [295318.825239] Code: 85 c9 89 e5 75 07 e8 6e fd ff ff 5d c3 e8 a1 fe ff ff 5d c3 55 85 c0 89 e5 53 89 c3 74 4c 8b 80 a8 00 00 00 83 bb 50 01 00 00 20 <8b> 40 20 74 43 85 c0 74 07 8b 50 14 85 d2 75 32 8d 43 24 ba 1c [295318.825295] EIP: [] iput+0x17/0x69 SS:ESP 0068:c1ac7e60 -- - 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/
Linux 2.6.19.7 + oprofile = BUG: unable to handle kernel NULL pointer dereference at virtual address 00000020
Not sure if this is oprofile's fault, but I got this when I started opreport. 10 min after BUG system needed to be rebooted (cycling power). With earlier kernel (without oprofile) everything worked for a month without hiccups. [295318.822839] BUG: unable to handle kernel NULL pointer dereference at virtual address 0020 [295318.822847] printing eip: [295318.822850] c0182530 [295318.822852] *pde = 2ed68001 [295318.822858] *pte = [295318.822862] Oops: [#1] [295318.822864] SMP [295318.822867] Modules linked in: oprofile perfctr dccp_diag dccp_ccid2 dccp_ipv4 i915 dccp xt_CLASSIFY ipt_ECN xt_CONNMARK ipt_connlimit ipt_TARPIT xt_length ipt_set xt_multiport ip_set_iphash ip_set_nethash ip_set_portmap sch_esfq ipt_REJECT ip6t_LOG xt_limit ipt_LOG ipt_hashlimit ip6table_mangle iptable_mangle iptable_raw ipt_owner xt_tcpudp xt_state ip_conntrack ip6table_filter ip6_tables iptable_filter ip_tables x_tables tcp_highspeed tcp_htcp tcp_hybla tcp_scalable tcp_vegas tcp_westwood ip_set sch_netem sch_hfsc sch_htb sch_sfq cls_fw cls_u32 cls_route sch_ingress sch_red sch_tbf sch_teql sch_prio sch_gred cls_rsvp cls_rsvp6 cls_tcindex sch_cbq sch_dsmark ioatdma cmtp kernelcapi l2cap bluetooth intelfb i2c_algo_bit i810 i2c_dev usb_storage eeprom ohci_hcd irlan irda crc_ccitt binfmt_misc loop dm_mod video button battery asus_acpi ac tcp_cubic lp nvram snd_hda_intel snd_hda_codec snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ohci1394 i2c_i801 snd_pcm ieee1394 pcspkr snd_timer snd i2c_core soundcore iTCO_wdt ehci_hcd snd_page_alloc e1000 parport_pc parport uhci_hcd [295318.822998] CPU:0 [295318.822999] EIP:0060:[c0182530]Not tainted VLI [295318.823000] EFLAGS: 00010282 (2.6.19.7-exec-shield-1 #137) [295318.823008] EIP is at iput+0x17/0x69 [295318.823016] eax: ebx: cafdd31c ecx: cafdd334 edx: cafdd334 [295318.823019] esi: cafdd31c edi: 003f ebp: c1ac7e64 esp: c1ac7e60 [295318.823022] ds: 007b es: 007b ss: 0068 [295318.823026] Process kswapd0 (pid: 217, ti=c1ac6000 task=c1a12550 task.ti=c1ac6000) [295318.823029] Stack: ddbcc42c c1ac7e7c c017f259 c1ac7e7c c017f2c6 ddbcc42c ddbcc42c c1ac7e8c [295318.823042]c017f6d3 f7624c3c ddbcc42c c1ac7ea4 c017f7f3 4970 [295318.823059]0086 c1ac7eac c017fd29 c1ac7ef8 c0155fc0 c0592680 [295318.823068] Call Trace: [295318.823358] [c017f259] dentry_iput+0x53/0x9f [295318.823627] [c017f6d3] prune_one_dentry+0x57/0x7a [295318.823900] [c017f7f3] prune_dcache+0xfd/0x152 [295318.824177] [c017fd29] shrink_dcache_memory+0x19/0x3d [295318.824446] [c0155fc0] shrink_slab+0x123/0x1b5 [295318.824652] [c01572c4] balance_pgdat+0x203/0x30b [295318.824852] [c0157486] kswapd+0xba/0x10a [295318.825064] [c0135b7f] kthread+0xa0/0xcd [295318.825209] [c0103a63] kernel_thread_helper+0x7/0x10 [295318.825237] === [295318.825239] Code: 85 c9 89 e5 75 07 e8 6e fd ff ff 5d c3 e8 a1 fe ff ff 5d c3 55 85 c0 89 e5 53 89 c3 74 4c 8b 80 a8 00 00 00 83 bb 50 01 00 00 20 8b 40 20 74 43 85 c0 74 07 8b 50 14 85 d2 75 32 8d 43 24 ba 1c [295318.825295] EIP: [c0182530] iput+0x17/0x69 SS:ESP 0068:c1ac7e60 -- - 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: asm volatile [Was: [RFC] div64_64 support]
On Wed, Mar 07, 2007 at 00:24:35 +0200, Sami Farin wrote:
> On Tue, Mar 06, 2007 at 23:53:49 +0200, Sami Farin wrote:
> ...
> > And I found bug in gcc-4.1.2, it gave 0 for ncubic results
> > when doing 1000 loops test... gcc-4.0.3 works.
>
> Found it.
>
> --- cbrt-test.c~ 2007-03-07 00:20:54.735248105 +0200
> +++ cbrt-test.c 2007-03-07 00:21:03.964864343 +0200
> @@ -209,7 +209,7 @@
>
> __asm__("bsrl %1,%0\n\t"
> "cmovzl %2,%0"
> - : "=" (r) : "rm" (x), "rm" (-1));
> + : "=" (r) : "rm" (x), "rm" (-1) : "memory");
> return r+1;
> }
>
> Now Linux 2.6 does not have "memory" in fls, maybe it causes
> some gcc funnies some people are seeing.
It also works without "memory" if I do "__asm__ volatile".
Why some functions have volatile and some have not in include/asm-*/*.h ?
--
-
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: asm volatile [Was: [RFC] div64_64 support]
On Wed, Mar 07, 2007 at 00:24:35 +0200, Sami Farin wrote: On Tue, Mar 06, 2007 at 23:53:49 +0200, Sami Farin wrote: ... And I found bug in gcc-4.1.2, it gave 0 for ncubic results when doing 1000 loops test... gcc-4.0.3 works. Found it. --- cbrt-test.c~ 2007-03-07 00:20:54.735248105 +0200 +++ cbrt-test.c 2007-03-07 00:21:03.964864343 +0200 @@ -209,7 +209,7 @@ __asm__(bsrl %1,%0\n\t cmovzl %2,%0 - : =r (r) : rm (x), rm (-1)); + : =r (r) : rm (x), rm (-1) : memory); return r+1; } Now Linux 2.6 does not have memory in fls, maybe it causes some gcc funnies some people are seeing. It also works without memory if I do __asm__ volatile. Why some functions have volatile and some have not in include/asm-*/*.h ? -- - 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 v2] epoll use a single inode ...
On Tue, Mar 06, 2007 at 21:20:33 +0100, Eric Dumazet wrote:
...
> I rewrote the reciprocal_div() for i386 so that one multiply is used.
>
> static inline u32 reciprocal_divide(u32 A, u32 R)
> {
> #if __i386
> unsigned int edx, eax;
> asm("mul %2":"=a" (eax), "=d" (edx):"rm" (R), "0" (A));
^^^
mul does not work if R is memory operand.
mull should be used instead.
--
-
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: [RFC] div64_64 support
On Wed, Mar 07, 2007 at 11:11:49 -0500, Chuck Ebbert wrote:
> Sami Farin wrote:
> > On Tue, Mar 06, 2007 at 23:53:49 +0200, Sami Farin wrote:
> > ...
> >> And I found bug in gcc-4.1.2, it gave 0 for ncubic results
> >> when doing 1000 loops test... gcc-4.0.3 works.
> >
> > Found it.
> >
> > --- cbrt-test.c~2007-03-07 00:20:54.735248105 +0200
> > +++ cbrt-test.c 2007-03-07 00:21:03.964864343 +0200
> > @@ -209,7 +209,7 @@
> >
> > __asm__("bsrl %1,%0\n\t"
> > "cmovzl %2,%0"
> > - : "=" (r) : "rm" (x), "rm" (-1));
> > + : "=" (r) : "rm" (x), "rm" (-1) : "memory");
> > return r+1;
> > }
> >
> > Now Linux 2.6 does not have "memory" in fls, maybe it causes
> > some gcc funnies some people are seeing.
>
> Can you post the difference in the generated code with that change?
Fun.. looks when not using "memory" gcc does not even bother
calling ncubic() 666 times. So it gets better timings ( 42/666=0 ) =)
--- cbrt-test-no_memory.s 2007-03-07 20:22:27.838466385 +0200
+++ cbrt-test-using_memory.s2007-03-07 20:22:38.237013197 +0200
...
main:
leal4(%esp), %ecx
andl$-16, %esp
pushl -4(%ecx)
pushl %ebp
pushl %edi
pushl %esi
pushl %ebx
pushl %ecx
- subl$136, %esp
+ subl$152, %esp
movl$.LC0, (%esp)
callputs
xorl%edx, %edx
movl$27, %eax
callncubic
cmpl$3, %eax
- je .L83
+ je .L87
movl$.LC1, (%esp)
callputs
-.L83:
- xorl%eax, %eax
- xorl%edi, %edi
- movl%eax, 88(%esp)
+.L87:
xorl%eax, %eax
- xorl%esi, %esi
+ xorl%ebp, %ebp
movl%eax, 92(%esp)
xorl%eax, %eax
- xorl%ebp, %ebp
+ xorl%edi, %edi
movl%eax, 96(%esp)
xorl%eax, %eax
+ xorl%esi, %esi
movl%eax, 100(%esp)
xorl%eax, %eax
movl%eax, 104(%esp)
xorl%eax, %eax
movl%eax, 108(%esp)
- movl%edi, 112(%esp)
- movl%esi, 116(%esp)
- .p2align 4,,15
-.L84:
+ xorl%eax, %eax
+ movl%eax, 112(%esp)
+ movl%ebp, 116(%esp)
+ movl%edi, 120(%esp)
+ movl%esi, 124(%esp)
+.L88:
#APP
movl $0, %eax
cpuid
rdtsc
#NO_APP
movl%eax, 56(%esp)
movl%edx, 60(%esp)
#APP
movl $0, %eax
cpuid
rdtsc
#NO_APP
movl%eax, %esi
movl%edx, %edi
subl56(%esp), %esi
sbbl60(%esp), %edi
cmpl$0, %edi
ja .L66
cmpl$999, %esi
- jbe .L84
+ jbe .L88
.L66:
+ movl92(%esp), %edx
+ leal(%edx,%edx,2), %eax
+ movlcases+4(,%eax,4), %edi
+ movlcases(,%eax,4), %esi
+ movl%edi, %edx
+ movl%esi, %eax
+ callncubic
#APP
movl $0, %eax
cpuid
rdtsc
#NO_APP
- movl%eax, %esi
- movl%edx, %edi
+ movl$666, %ebx
+ movl%eax, 128(%esp)
+ movl%edx, 132(%esp)
+ .p2align 4,,15
+.L67:
+ movl%esi, %eax
+ movl%edi, %edx
+ callncubic
+ decl%ebx
+ movl%eax, %ebp
+ jne .L67
#APP
movl $0, %eax
cpuid
rdtsc
#NO_APP
- subl%esi, %eax
+ subl128(%esp), %eax
movl$666, %ebx
- sbbl%edi, %edx
- xorl%ecx, %ecx
movl%ebx, 8(%esp)
+ sbbl132(%esp), %edx
+ xorl%ecx, %ecx
movl%ecx, 12(%esp)
movl%eax, (%esp)
movl%edx, 4(%esp)
call__udivdi3
- addl%eax, 104(%esp)
+ addl%eax, 112(%esp)
movl%edx, %ecx
movl%eax, %ebx
movl%edx, %esi
- adcl%edx, 108(%esp)
+ adcl%edx, 116(%esp)
imull %eax, %ecx
mull%ebx
addl%ecx, %ecx
movl%eax, 56(%esp)
addl%ecx, %edx
movl56(%esp), %eax
- addl%eax, 112(%esp)
+ addl%eax, 120(%esp)
movl%edx, 60(%esp)
movl60(%esp), %edx
- adcl%edx, 116(%esp)
- cmpl%esi, 92(%esp)
- ja .L67
- jb .L68
- cmpl%ebx, 88(%esp)
- jae .L67
-.L68:
- movl%ebx, 88(%esp)
- movl%esi, 92(%esp)
-.L67:
- leal(%ebp,%ebp,2), %ebx
- sall$2, %ebx
- movlcases+4(%ebx), %edx
- movlcases(%ebx), %eax
- callncubic
- movlcases+8(%ebx)
Re: [patch v2] epoll use a single inode ...
On Tue, Mar 06, 2007 at 21:20:33 +0100, Eric Dumazet wrote:
...
I rewrote the reciprocal_div() for i386 so that one multiply is used.
static inline u32 reciprocal_divide(u32 A, u32 R)
{
#if __i386
unsigned int edx, eax;
asm(mul %2:=a (eax), =d (edx):rm (R), 0 (A));
^^^
mul does not work if R is memory operand.
mull should be used instead.
--
-
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: [RFC] div64_64 support
On Wed, Mar 07, 2007 at 11:11:49 -0500, Chuck Ebbert wrote: Sami Farin wrote: On Tue, Mar 06, 2007 at 23:53:49 +0200, Sami Farin wrote: ... And I found bug in gcc-4.1.2, it gave 0 for ncubic results when doing 1000 loops test... gcc-4.0.3 works. Found it. --- cbrt-test.c~2007-03-07 00:20:54.735248105 +0200 +++ cbrt-test.c 2007-03-07 00:21:03.964864343 +0200 @@ -209,7 +209,7 @@ __asm__(bsrl %1,%0\n\t cmovzl %2,%0 - : =r (r) : rm (x), rm (-1)); + : =r (r) : rm (x), rm (-1) : memory); return r+1; } Now Linux 2.6 does not have memory in fls, maybe it causes some gcc funnies some people are seeing. Can you post the difference in the generated code with that change? Fun.. looks when not using memory gcc does not even bother calling ncubic() 666 times. So it gets better timings ( 42/666=0 ) =) --- cbrt-test-no_memory.s 2007-03-07 20:22:27.838466385 +0200 +++ cbrt-test-using_memory.s2007-03-07 20:22:38.237013197 +0200 ... main: leal4(%esp), %ecx andl$-16, %esp pushl -4(%ecx) pushl %ebp pushl %edi pushl %esi pushl %ebx pushl %ecx - subl$136, %esp + subl$152, %esp movl$.LC0, (%esp) callputs xorl%edx, %edx movl$27, %eax callncubic cmpl$3, %eax - je .L83 + je .L87 movl$.LC1, (%esp) callputs -.L83: - xorl%eax, %eax - xorl%edi, %edi - movl%eax, 88(%esp) +.L87: xorl%eax, %eax - xorl%esi, %esi + xorl%ebp, %ebp movl%eax, 92(%esp) xorl%eax, %eax - xorl%ebp, %ebp + xorl%edi, %edi movl%eax, 96(%esp) xorl%eax, %eax + xorl%esi, %esi movl%eax, 100(%esp) xorl%eax, %eax movl%eax, 104(%esp) xorl%eax, %eax movl%eax, 108(%esp) - movl%edi, 112(%esp) - movl%esi, 116(%esp) - .p2align 4,,15 -.L84: + xorl%eax, %eax + movl%eax, 112(%esp) + movl%ebp, 116(%esp) + movl%edi, 120(%esp) + movl%esi, 124(%esp) +.L88: #APP movl $0, %eax cpuid rdtsc #NO_APP movl%eax, 56(%esp) movl%edx, 60(%esp) #APP movl $0, %eax cpuid rdtsc #NO_APP movl%eax, %esi movl%edx, %edi subl56(%esp), %esi sbbl60(%esp), %edi cmpl$0, %edi ja .L66 cmpl$999, %esi - jbe .L84 + jbe .L88 .L66: + movl92(%esp), %edx + leal(%edx,%edx,2), %eax + movlcases+4(,%eax,4), %edi + movlcases(,%eax,4), %esi + movl%edi, %edx + movl%esi, %eax + callncubic #APP movl $0, %eax cpuid rdtsc #NO_APP - movl%eax, %esi - movl%edx, %edi + movl$666, %ebx + movl%eax, 128(%esp) + movl%edx, 132(%esp) + .p2align 4,,15 +.L67: + movl%esi, %eax + movl%edi, %edx + callncubic + decl%ebx + movl%eax, %ebp + jne .L67 #APP movl $0, %eax cpuid rdtsc #NO_APP - subl%esi, %eax + subl128(%esp), %eax movl$666, %ebx - sbbl%edi, %edx - xorl%ecx, %ecx movl%ebx, 8(%esp) + sbbl132(%esp), %edx + xorl%ecx, %ecx movl%ecx, 12(%esp) movl%eax, (%esp) movl%edx, 4(%esp) call__udivdi3 - addl%eax, 104(%esp) + addl%eax, 112(%esp) movl%edx, %ecx movl%eax, %ebx movl%edx, %esi - adcl%edx, 108(%esp) + adcl%edx, 116(%esp) imull %eax, %ecx mull%ebx addl%ecx, %ecx movl%eax, 56(%esp) addl%ecx, %edx movl56(%esp), %eax - addl%eax, 112(%esp) + addl%eax, 120(%esp) movl%edx, 60(%esp) movl60(%esp), %edx - adcl%edx, 116(%esp) - cmpl%esi, 92(%esp) - ja .L67 - jb .L68 - cmpl%ebx, 88(%esp) - jae .L67 -.L68: - movl%ebx, 88(%esp) - movl%esi, 92(%esp) -.L67: - leal(%ebp,%ebp,2), %ebx - sall$2, %ebx - movlcases+4(%ebx), %edx - movlcases(%ebx), %eax - callncubic - movlcases+8(%ebx), %edx - subl%eax, %edx - movl%edx, %eax - sarl$31, %eax - xorl%eax, %edx - subl%eax, %edx - movl%edx, %ecx - sarl$31, %ecx - addl%edx, 96(%esp) - adcl%ecx, 100(%esp) - incl%ebp - cmpl$183, %ebp
Re: [RFC] div64_64 support
On Tue, Mar 06, 2007 at 16:00:55 -0800, Stephen Hemminger wrote: ... > > Now Linux 2.6 does not have "memory" in fls, maybe it causes > > some gcc funnies some people are seeing. > > > > That code was copy-paste from: > include/asm-x86_64/bitops.h > > So shouldn't both fls() and ffs() be fixed there as well? Yes. And for both x86_64 and i386. -- - 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: [RFC] div64_64 support
On Tue, Mar 06, 2007 at 23:53:49 +0200, Sami Farin wrote:
...
> And I found bug in gcc-4.1.2, it gave 0 for ncubic results
> when doing 1000 loops test... gcc-4.0.3 works.
Found it.
--- cbrt-test.c~2007-03-07 00:20:54.735248105 +0200
+++ cbrt-test.c 2007-03-07 00:21:03.964864343 +0200
@@ -209,7 +209,7 @@
__asm__("bsrl %1,%0\n\t"
"cmovzl %2,%0"
- : "=" (r) : "rm" (x), "rm" (-1));
+ : "=" (r) : "rm" (x), "rm" (-1) : "memory");
return r+1;
}
Now Linux 2.6 does not have "memory" in fls, maybe it causes
some gcc funnies some people are seeing.
--
-
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: [RFC] div64_64 support
On Tue, Mar 06, 2007 at 10:29:41 -0800, Stephen Hemminger wrote:
> Don't count the existing Newton-Raphson out. It turns out that to get enough
> precision for 32 bits, only 4 iterations are needed. By unrolling those, it
> gets much better timing.
>
> Slightly gross test program (with original cubic wraparound bug fixed).
...
> {~0, 2097151},
^^^
this should be 2642245.
Without serializing instruction before rdtsc and with one loop
I do not get very accurate results (104 for ncubic, > 1000 for others).
#define rdtscll_serialize(val) \
__asm__ __volatile__("movl $0, %%eax\n\tcpuid\n\trdtsc\n" : "=A" (val) : :
"ebx", "ecx")
Here Pentium D timings for 1000 loops.
~0, 2097151
Function clocks mean(us) max(us) std(us) total error
ocubic 9120.306 20.3170.730 545101
ncubic 7770.261 14.7990.486 576263
acbrt 11680.392 21.6810.547 547562
hcbrt 8270.278 15.2440.3872410
~0, 2642245
Function clocks mean(us) max(us) std(us) total error
ocubic 9080.305 20.2100.656 7
ncubic 7750.260 14.7920.550 31169
acbrt 11760.395 22.0170.9702468
hcbrt 8260.278 15.3260.670 547504
And I found bug in gcc-4.1.2, it gave 0 for ncubic results
when doing 1000 loops test... gcc-4.0.3 works.
--
-
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: [RFC] div64_64 support
On Tue, Mar 06, 2007 at 16:00:55 -0800, Stephen Hemminger wrote: ... Now Linux 2.6 does not have memory in fls, maybe it causes some gcc funnies some people are seeing. That code was copy-paste from: include/asm-x86_64/bitops.h So shouldn't both fls() and ffs() be fixed there as well? Yes. And for both x86_64 and i386. -- - 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: [RFC] div64_64 support
On Tue, Mar 06, 2007 at 10:29:41 -0800, Stephen Hemminger wrote:
Don't count the existing Newton-Raphson out. It turns out that to get enough
precision for 32 bits, only 4 iterations are needed. By unrolling those, it
gets much better timing.
Slightly gross test program (with original cubic wraparound bug fixed).
...
{~0, 2097151},
^^^
this should be 2642245.
Without serializing instruction before rdtsc and with one loop
I do not get very accurate results (104 for ncubic, 1000 for others).
#define rdtscll_serialize(val) \
__asm__ __volatile__(movl $0, %%eax\n\tcpuid\n\trdtsc\n : =A (val) : :
ebx, ecx)
Here Pentium D timings for 1000 loops.
~0, 2097151
Function clocks mean(us) max(us) std(us) total error
ocubic 9120.306 20.3170.730 545101
ncubic 7770.261 14.7990.486 576263
acbrt 11680.392 21.6810.547 547562
hcbrt 8270.278 15.2440.3872410
~0, 2642245
Function clocks mean(us) max(us) std(us) total error
ocubic 9080.305 20.2100.656 7
ncubic 7750.260 14.7920.550 31169
acbrt 11760.395 22.0170.9702468
hcbrt 8260.278 15.3260.670 547504
And I found bug in gcc-4.1.2, it gave 0 for ncubic results
when doing 1000 loops test... gcc-4.0.3 works.
--
-
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: [RFC] div64_64 support
On Tue, Mar 06, 2007 at 23:53:49 +0200, Sami Farin wrote: ... And I found bug in gcc-4.1.2, it gave 0 for ncubic results when doing 1000 loops test... gcc-4.0.3 works. Found it. --- cbrt-test.c~2007-03-07 00:20:54.735248105 +0200 +++ cbrt-test.c 2007-03-07 00:21:03.964864343 +0200 @@ -209,7 +209,7 @@ __asm__(bsrl %1,%0\n\t cmovzl %2,%0 - : =r (r) : rm (x), rm (-1)); + : =r (r) : rm (x), rm (-1) : memory); return r+1; } Now Linux 2.6 does not have memory in fls, maybe it causes some gcc funnies some people are seeing. -- - 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: [RFC] div64_64 support
On Fri, Feb 23, 2007 at 17:05:27 -0800, Stephen Hemminger wrote: > Since there already two users of full 64 bit division in the kernel, > and other places maybe hiding out as well. Add a full 64/64 bit divide. > > Yes this expensive, but there are places where it is necessary. > It is not clear if doing the scaling buys any advantage on 64 bit platforms, > so for them a full divide is done. Still does not work after these fixes... how came? WARNING: "div64_64" [net/netfilter/xt_connbytes.ko] undefined! WARNING: "div64_64" [net/ipv4/tcp_cubic.ko] undefined! --- linux-2.6.19/include/asm-i386/div64.h.bak 2006-11-29 23:57:37.0 +0200 +++ linux-2.6.19/include/asm-i386/div64.h 2007-02-24 16:24:55.822529880 +0200 @@ -45,4 +45,7 @@ div_ll_X_l_rem(long long divs, long div, return dum2; } + +extern uint64_t div64_64(uint64_t dividend, uint64_t divisor); + #endif --- linux-2.6.19/lib/div64.c.bak2007-02-24 16:10:03.686084000 +0200 +++ linux-2.6.19/lib/div64.c2007-02-24 17:01:11.224517353 +0200 @@ -80,4 +80,6 @@ uint64_t div64_64(uint64_t dividend, uin return dividend; } +EXPORT_SYMBOL(div64_64); + #endif /* BITS_PER_LONG == 32 */ -- - 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: [RFC] div64_64 support
On Fri, Feb 23, 2007 at 17:05:27 -0800, Stephen Hemminger wrote: Since there already two users of full 64 bit division in the kernel, and other places maybe hiding out as well. Add a full 64/64 bit divide. Yes this expensive, but there are places where it is necessary. It is not clear if doing the scaling buys any advantage on 64 bit platforms, so for them a full divide is done. Still does not work after these fixes... how came? WARNING: div64_64 [net/netfilter/xt_connbytes.ko] undefined! WARNING: div64_64 [net/ipv4/tcp_cubic.ko] undefined! --- linux-2.6.19/include/asm-i386/div64.h.bak 2006-11-29 23:57:37.0 +0200 +++ linux-2.6.19/include/asm-i386/div64.h 2007-02-24 16:24:55.822529880 +0200 @@ -45,4 +45,7 @@ div_ll_X_l_rem(long long divs, long div, return dum2; } + +extern uint64_t div64_64(uint64_t dividend, uint64_t divisor); + #endif --- linux-2.6.19/lib/div64.c.bak2007-02-24 16:10:03.686084000 +0200 +++ linux-2.6.19/lib/div64.c2007-02-24 17:01:11.224517353 +0200 @@ -80,4 +80,6 @@ uint64_t div64_64(uint64_t dividend, uin return dividend; } +EXPORT_SYMBOL(div64_64); + #endif /* BITS_PER_LONG == 32 */ -- - 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/
XFS internal error xfs_da_do_buf
I setup namespace for /tmp and /var/tmp
( pam_namespace.so into /etc/pam.d/{su,login} )
and something did not like something I did:
[322593.844838] 0x0: 00 00 00 00 2b 00 00 11 20 21 00 00 00 68 ff ff
[322593.844854] Filesystem "sda8": XFS internal error xfs_da_do_buf(2) at line
2087 of file fs/xfs/xfs_da_btree.c. Caller 0xc0230808
[322593.844997] [] dump_trace+0x215/0x21a
[322593.845024] [] show_trace_log_lvl+0x1a/0x30
[322593.845044] [] show_trace+0x12/0x14
[322593.845062] [] dump_stack+0x19/0x1b
[322593.845080] [] xfs_error_report+0x55/0x5b
[322593.845430] [] xfs_corruption_error+0x3f/0x59
[322593.845780] [] xfs_da_do_buf+0x716/0x7c1
[322593.846124] [] xfs_da_read_buf+0x2f/0x35
[322593.846464] [] xfs_attr_leaf_get+0x3c/0xa3
[322593.846798] [] xfs_attr_fetch+0xb0/0xfe
[322593.847127] [] xfs_acl_iaccess+0x59/0xc2
[322593.847451] [] xfs_iaccess+0x14b/0x189
[322593.847806] [] xfs_access+0x34/0x53
[322593.848182] [] xfs_vn_permission+0x12/0x17
[322593.848564] [] permission+0xe4/0xe6
[322593.848755] [] vfs_permission+0xf/0x11
[322593.848942] [] sys_faccessat+0xa6/0x144
[322593.849120] [] sys_access+0x20/0x22
[322593.849292] [] syscall_call+0x7/0xb
[322593.849310] [<00f4f410>] 0xf4f410
[322593.849334] ===
[322593.849358] 0x0: 00 00 00 00 2b 00 00 11 20 21 00 00 00 68 ff ff
[322593.849364] Filesystem "sda8": XFS internal error xfs_da_do_buf(2) at line
2087 of file fs/xfs/xfs_da_btree.c. Caller 0xc0230808
[322593.849484] [] dump_trace+0x215/0x21a
[322593.849512] [] show_trace_log_lvl+0x1a/0x30
[322593.849530] [] show_trace+0x12/0x14
[322593.849548] [] dump_stack+0x19/0x1b
[322593.849573] [] xfs_error_report+0x55/0x5b
[322593.849913] [] xfs_corruption_error+0x3f/0x59
[322593.850258] [] xfs_da_do_buf+0x716/0x7c1
[322593.850598] [] xfs_da_read_buf+0x2f/0x35
[322593.850936] [] xfs_attr_leaf_get+0x3c/0xa3
[322593.851266] [] xfs_attr_fetch+0xb0/0xfe
[322593.851593] [] xfs_acl_iaccess+0x59/0xc2
[322593.851917] [] xfs_iaccess+0x14b/0x189
[322593.852268] [] xfs_access+0x34/0x53
[322593.852638] [] xfs_vn_permission+0x12/0x17
[322593.853018] [] permission+0xe4/0xe6
[322593.853204] [] vfs_permission+0xf/0x11
[322593.853387] [] sys_faccessat+0xa6/0x144
[322593.853562] [] sys_access+0x20/0x22
[322593.853734] [] syscall_call+0x7/0xb
[322593.853753] [<00f4f410>] 0xf4f410
[322593.853759] ===
sda8 is /usr , I haven't played with mount --bind or namespaces
at /usr (AFAIK).
My sda hard disk is not broken and I have SMP kernel 2.6.19.2 + Pentium D.
I have got no other BUGs or xfs errors and I can access /usr and other
partitions OK.
--
Do what you love because life is too short for anything else.
-
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/
XFS internal error xfs_da_do_buf
I setup namespace for /tmp and /var/tmp
( pam_namespace.so into /etc/pam.d/{su,login} )
and something did not like something I did:
[322593.844838] 0x0: 00 00 00 00 2b 00 00 11 20 21 00 00 00 68 ff ff
[322593.844854] Filesystem sda8: XFS internal error xfs_da_do_buf(2) at line
2087 of file fs/xfs/xfs_da_btree.c. Caller 0xc0230808
[322593.844997] [c0103cff] dump_trace+0x215/0x21a
[322593.845024] [c0103da7] show_trace_log_lvl+0x1a/0x30
[322593.845044] [c0103dcf] show_trace+0x12/0x14
[322593.845062] [c0103ecc] dump_stack+0x19/0x1b
[322593.845080] [c023a3a3] xfs_error_report+0x55/0x5b
[322593.845430] [c023a4c6] xfs_corruption_error+0x3f/0x59
[322593.845780] [c02306f9] xfs_da_do_buf+0x716/0x7c1
[322593.846124] [c0230808] xfs_da_read_buf+0x2f/0x35
[322593.846464] [c02162bc] xfs_attr_leaf_get+0x3c/0xa3
[322593.846798] [c0214d08] xfs_attr_fetch+0xb0/0xfe
[322593.847127] [c020e56a] xfs_acl_iaccess+0x59/0xc2
[322593.847451] [c02457af] xfs_iaccess+0x14b/0x189
[322593.847806] [c025fb3b] xfs_access+0x34/0x53
[322593.848182] [c026ceea] xfs_vn_permission+0x12/0x17
[322593.848564] [c0175438] permission+0xe4/0xe6
[322593.848755] [c0175449] vfs_permission+0xf/0x11
[322593.848942] [c016d0cf] sys_faccessat+0xa6/0x144
[322593.849120] [c016d18d] sys_access+0x20/0x22
[322593.849292] [c0102e77] syscall_call+0x7/0xb
[322593.849310] [00f4f410] 0xf4f410
[322593.849334] ===
[322593.849358] 0x0: 00 00 00 00 2b 00 00 11 20 21 00 00 00 68 ff ff
[322593.849364] Filesystem sda8: XFS internal error xfs_da_do_buf(2) at line
2087 of file fs/xfs/xfs_da_btree.c. Caller 0xc0230808
[322593.849484] [c0103cff] dump_trace+0x215/0x21a
[322593.849512] [c0103da7] show_trace_log_lvl+0x1a/0x30
[322593.849530] [c0103dcf] show_trace+0x12/0x14
[322593.849548] [c0103ecc] dump_stack+0x19/0x1b
[322593.849573] [c023a3a3] xfs_error_report+0x55/0x5b
[322593.849913] [c023a4c6] xfs_corruption_error+0x3f/0x59
[322593.850258] [c02306f9] xfs_da_do_buf+0x716/0x7c1
[322593.850598] [c0230808] xfs_da_read_buf+0x2f/0x35
[322593.850936] [c02162bc] xfs_attr_leaf_get+0x3c/0xa3
[322593.851266] [c0214d08] xfs_attr_fetch+0xb0/0xfe
[322593.851593] [c020e56a] xfs_acl_iaccess+0x59/0xc2
[322593.851917] [c02457af] xfs_iaccess+0x14b/0x189
[322593.852268] [c025fb3b] xfs_access+0x34/0x53
[322593.852638] [c026ceea] xfs_vn_permission+0x12/0x17
[322593.853018] [c0175438] permission+0xe4/0xe6
[322593.853204] [c0175449] vfs_permission+0xf/0x11
[322593.853387] [c016d0cf] sys_faccessat+0xa6/0x144
[322593.853562] [c016d18d] sys_access+0x20/0x22
[322593.853734] [c0102e77] syscall_call+0x7/0xb
[322593.853753] [00f4f410] 0xf4f410
[322593.853759] ===
sda8 is /usr , I haven't played with mount --bind or namespaces
at /usr (AFAIK).
My sda hard disk is not broken and I have SMP kernel 2.6.19.2 + Pentium D.
I have got no other BUGs or xfs errors and I can access /usr and other
partitions OK.
--
Do what you love because life is too short for anything else.
-
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-rc5: known unfixed regressions
On Wed, Jan 17, 2007 at 14:43:29 +1100, David Chinner wrote: ... > > > Subject: BUG: at mm/truncate.c:60 cancel_dirty_page() (XFS) > > > References : http://lkml.org/lkml/2007/1/5/308 > > > Submitter : Sami Farin <[EMAIL PROTECTED]> > > > Handled-By : David Chinner <[EMAIL PROTECTED]> > > > Status : problem is being discussed > > > > I'm at LCA and been having laptop dramas so the fix is being held up at this > > point. I and trying to test a change right now that adds an optional unmap > > to truncate_inode_pages_range as XFS needs, in some circumstances, to toss > > out dirty pages (with dirty bufferheads) and hence requires truncate > > semantics > > that are currently missing unmap calls. > > > > Semi-untested patch attached below. > > The patch has run XFSQA for about 24 hours now on my test rig without > triggering any problems. I have also ran this for 24h (in patched 2.6.19.2) and no problems noticed :) -- Do what you love because life is too short for anything else. - 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-rc5: known unfixed regressions
On Wed, Jan 17, 2007 at 14:43:29 +1100, David Chinner wrote: ... Subject: BUG: at mm/truncate.c:60 cancel_dirty_page() (XFS) References : http://lkml.org/lkml/2007/1/5/308 Submitter : Sami Farin [EMAIL PROTECTED] Handled-By : David Chinner [EMAIL PROTECTED] Status : problem is being discussed I'm at LCA and been having laptop dramas so the fix is being held up at this point. I and trying to test a change right now that adds an optional unmap to truncate_inode_pages_range as XFS needs, in some circumstances, to toss out dirty pages (with dirty bufferheads) and hence requires truncate semantics that are currently missing unmap calls. Semi-untested patch attached below. The patch has run XFSQA for about 24 hours now on my test rig without triggering any problems. I have also ran this for 24h (in patched 2.6.19.2) and no problems noticed :) -- Do what you love because life is too short for anything else. - 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: I broke my port numbers :(
On Tue, Jan 16, 2007 at 14:57:56 +0100, Jan Engelhardt wrote: > > >Subject: Re: I broke my port numbers :( > > > >On Mon, Jan 15, 2007 at 23:55:15 +0200, Sami Farin wrote: > >> I know this may be entirely my fault but I have tried reversing > >> all of my _own_ patches I applied to 2.6.19.2 but can't find what broke > >> this. > >> I did three times "netcat 127.0.0.69 42", notice the different > >> port numbers. > > > >Hmm... when I do "rmmod iptable_nat ip_nat", it works. > > Then please show us your rulset that was loaded (iptables-save) before > you removed the modules. For -t nat I had only -t nat-P PREROUTING ACCEPT -t nat-P POSTROUTING ACCEPT -t nat-P OUTPUT ACCEPT but due to my modifications to ip_nat_proto_tcp.c it broke (ip_nat_proto_tcp.c wasn't supposed to get used, anyways). -- - 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: I broke my port numbers :(
On Tue, Jan 16, 2007 at 14:57:56 +0100, Jan Engelhardt wrote: Subject: Re: I broke my port numbers :( On Mon, Jan 15, 2007 at 23:55:15 +0200, Sami Farin wrote: I know this may be entirely my fault but I have tried reversing all of my _own_ patches I applied to 2.6.19.2 but can't find what broke this. I did three times netcat 127.0.0.69 42, notice the different port numbers. Hmm... when I do rmmod iptable_nat ip_nat, it works. Then please show us your rulset that was loaded (iptables-save) before you removed the modules. For -t nat I had only -t nat-P PREROUTING ACCEPT -t nat-P POSTROUTING ACCEPT -t nat-P OUTPUT ACCEPT but due to my modifications to ip_nat_proto_tcp.c it broke (ip_nat_proto_tcp.c wasn't supposed to get used, anyways). -- - 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: I broke my port numbers :(
On Mon, Jan 15, 2007 at 23:55:15 +0200, Sami Farin wrote: > I know this may be entirely my fault but I have tried reversing > all of my _own_ patches I applied to 2.6.19.2 but can't find what broke this. > I did three times "netcat 127.0.0.69 42", notice the different > port numbers. Hmm... when I do "rmmod iptable_nat ip_nat", it works. # iptables -t nat --list -nvx Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination I didn't know functions in ip_nat_proto_tcp.o were called when I have empty nat table. Oops... without iptable_nat ip_nat: 64 bytes from 127.0.0.1: icmp_seq=3 ttl=61 time=0.053 ms with them: 64 bytes from 127.0.0.1: icmp_seq=3 ttl=61 time=0.065 ms *shrug* live and learn. 2007-01-16 00:44:43.616266500 <4>[ 5672.924459] [] dump_trace+0x215/0x21a 2007-01-16 00:44:43.616267500 <4>[ 5672.924492] [] show_trace_log_lvl+0x1a/0x30 2007-01-16 00:44:43.616269500 <4>[ 5672.924511] [] show_trace+0x12/0x14 2007-01-16 00:44:43.616270500 <4>[ 5672.924529] [] dump_stack+0x19/0x1b 2007-01-16 00:44:43.616271500 <4>[ 5672.924547] [] tcp_unique_tuple+0xd7/0x130 [ip_nat] 2007-01-16 00:44:43.616272500 <4>[ 5672.924585] [] get_unique_tuple+0x5a/0x6e [ip_nat] 2007-01-16 00:44:43.616285500 <4>[ 5672.924593] [] ip_nat_setup_info+0x73/0x1e6 [ip_nat] 2007-01-16 00:44:43.616287500 <4>[ 5672.924601] [] ip_nat_rule_find+0x90/0xb0 [iptable_nat] 2007-01-16 00:44:43.616288500 <4>[ 5672.924610] [] ip_nat_fn+0xd5/0x1ac [iptable_nat] 2007-01-16 00:44:43.616289500 <4>[ 5672.924617] [] ip_nat_out+0x56/0xd3 [iptable_nat] 2007-01-16 00:44:43.616290500 <4>[ 5672.924624] [] nf_iterate+0x4b/0x77 2007-01-16 00:44:43.616295500 <4>[ 5672.925610] [] nf_hook_slow+0x58/0xdf 2007-01-16 00:44:43.617058500 <4>[ 5672.926562] [] ip_output+0x187/0x26a 2007-01-16 00:44:43.618005500 <4>[ 5672.927511] [] ip_queue_xmit+0x4c9/0x5a4 2007-01-16 00:44:43.618955500 <4>[ 5672.928461] [] tcp_transmit_skb+0x25b/0x466 2007-01-16 00:44:43.619911500 <4>[ 5672.929417] [] tcp_connect+0x133/0x1d1 2007-01-16 00:44:43.620865500 <4>[ 5672.930371] [] tcp_v4_connect+0x404/0x750 2007-01-16 00:44:43.621821500 <4>[ 5672.931327] [] inet_stream_connect+0x123/0x1b1 2007-01-16 00:44:43.622789500 <4>[ 5672.932295] [] sys_connect+0x9c/0xbe 2007-01-16 00:44:43.623679500 <4>[ 5672.933185] [] sys_socketcall+0xd2/0x272 2007-01-16 00:44:43.624612500 <4>[ 5672.934072] [] syscall_call+0x7/0xb 2007-01-16 00:44:43.624614500 <4>[ 5672.934092] [<00645410>] 0x645410 2007-01-16 00:44:43.624615500 <4>[ 5672.934116] === -- - 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/
I broke my port numbers :(
I know this may be entirely my fault but I have tried reversing all of my _own_ patches I applied to 2.6.19.2 but can't find what broke this. I did three times "netcat 127.0.0.69 42", notice the different port numbers. First, if someone could attempt this on 2.6.19.2 or 2.6.20-rc* , and tell it works, I shut up. 2007-01-15 23:42:05.833636 IP (tos 0x0, ttl 61, id 34230, offset 0, flags [DF], proto: TCP (6), length: 60) 127.0.0.69.23287 > 127.0.0.69.42: SWE, cksum 0x0281 (correct), 674651575:674651575(0) win 32792 2007-01-15 23:42:05.833673 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 127.0.0.69.42 > 127.0.0.69.52935: R, cksum 0x5c66 (correct), 0:0(0) ack 674651576 win 0 2007-01-15 23:42:06.009245 IP (tos 0x0, ttl 61, id 11189, offset 0, flags [DF], proto: TCP (6), length: 60) 127.0.0.69.20161 > 127.0.0.69.42: SWE, cksum 0x96b3 (correct), 678941897:678941897(0) win 32792 2007-01-15 23:42:06.009289 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 127.0.0.69.42 > 127.0.0.69.52936: R, cksum 0xe511 (correct), 0:0(0) ack 678941898 win 0 2007-01-15 23:42:06.169587 IP (tos 0x0, ttl 61, id 36607, offset 0, flags [DF], proto: TCP (6), length: 60) 127.0.0.69.52470 > 127.0.0.69.42: SWE, cksum 0x15b5 (correct), 681498315:681498315(0) win 32792 2007-01-15 23:42:06.169624 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 127.0.0.69.42 > 127.0.0.69.52937: R, cksum 0xe2e7 (correct), 0:0(0) ack 681498316 win 0 If something was listening on port 42, it would see the wrong port, e.g. 23287, 20161 or 52470, not 52935, 52936 or 52937. -- - 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/
I broke my port numbers :(
I know this may be entirely my fault but I have tried reversing all of my _own_ patches I applied to 2.6.19.2 but can't find what broke this. I did three times netcat 127.0.0.69 42, notice the different port numbers. First, if someone could attempt this on 2.6.19.2 or 2.6.20-rc* , and tell it works, I shut up. 2007-01-15 23:42:05.833636 IP (tos 0x0, ttl 61, id 34230, offset 0, flags [DF], proto: TCP (6), length: 60) 127.0.0.69.23287 127.0.0.69.42: SWE, cksum 0x0281 (correct), 674651575:674651575(0) win 32792 mss 16396,sackOK,timestamp 1616544 0,nop,wscale 4 2007-01-15 23:42:05.833673 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 127.0.0.69.42 127.0.0.69.52935: R, cksum 0x5c66 (correct), 0:0(0) ack 674651576 win 0 2007-01-15 23:42:06.009245 IP (tos 0x0, ttl 61, id 11189, offset 0, flags [DF], proto: TCP (6), length: 60) 127.0.0.69.20161 127.0.0.69.42: SWE, cksum 0x96b3 (correct), 678941897:678941897(0) win 32792 mss 16396,sackOK,timestamp 1616720 0,nop,wscale 4 2007-01-15 23:42:06.009289 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 127.0.0.69.42 127.0.0.69.52936: R, cksum 0xe511 (correct), 0:0(0) ack 678941898 win 0 2007-01-15 23:42:06.169587 IP (tos 0x0, ttl 61, id 36607, offset 0, flags [DF], proto: TCP (6), length: 60) 127.0.0.69.52470 127.0.0.69.42: SWE, cksum 0x15b5 (correct), 681498315:681498315(0) win 32792 mss 16396,sackOK,timestamp 1616880 0,nop,wscale 4 2007-01-15 23:42:06.169624 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 127.0.0.69.42 127.0.0.69.52937: R, cksum 0xe2e7 (correct), 0:0(0) ack 681498316 win 0 If something was listening on port 42, it would see the wrong port, e.g. 23287, 20161 or 52470, not 52935, 52936 or 52937. -- - 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: I broke my port numbers :(
On Mon, Jan 15, 2007 at 23:55:15 +0200, Sami Farin wrote: I know this may be entirely my fault but I have tried reversing all of my _own_ patches I applied to 2.6.19.2 but can't find what broke this. I did three times netcat 127.0.0.69 42, notice the different port numbers. Hmm... when I do rmmod iptable_nat ip_nat, it works. # iptables -t nat --list -nvx Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination I didn't know functions in ip_nat_proto_tcp.o were called when I have empty nat table. Oops... without iptable_nat ip_nat: 64 bytes from 127.0.0.1: icmp_seq=3 ttl=61 time=0.053 ms with them: 64 bytes from 127.0.0.1: icmp_seq=3 ttl=61 time=0.065 ms *shrug* live and learn. 2007-01-16 00:44:43.616266500 4[ 5672.924459] [c0103cff] dump_trace+0x215/0x21a 2007-01-16 00:44:43.616267500 4[ 5672.924492] [c0103da7] show_trace_log_lvl+0x1a/0x30 2007-01-16 00:44:43.616269500 4[ 5672.924511] [c0103dcf] show_trace+0x12/0x14 2007-01-16 00:44:43.616270500 4[ 5672.924529] [c0103ecc] dump_stack+0x19/0x1b 2007-01-16 00:44:43.616271500 4[ 5672.924547] [f8c3756f] tcp_unique_tuple+0xd7/0x130 [ip_nat] 2007-01-16 00:44:43.616272500 4[ 5672.924585] [f8c363db] get_unique_tuple+0x5a/0x6e [ip_nat] 2007-01-16 00:44:43.616285500 4[ 5672.924593] [f8c36462] ip_nat_setup_info+0x73/0x1e6 [ip_nat] 2007-01-16 00:44:43.616287500 4[ 5672.924601] [f8c3b378] ip_nat_rule_find+0x90/0xb0 [iptable_nat] 2007-01-16 00:44:43.616288500 4[ 5672.924610] [f8c3b53a] ip_nat_fn+0xd5/0x1ac [iptable_nat] 2007-01-16 00:44:43.616289500 4[ 5672.924617] [f8c3b706] ip_nat_out+0x56/0xd3 [iptable_nat] 2007-01-16 00:44:43.616290500 4[ 5672.924624] [c0443dc1] nf_iterate+0x4b/0x77 2007-01-16 00:44:43.616295500 4[ 5672.925610] [c0443e45] nf_hook_slow+0x58/0xdf 2007-01-16 00:44:43.617058500 4[ 5672.926562] [c0451065] ip_output+0x187/0x26a 2007-01-16 00:44:43.618005500 4[ 5672.927511] [c0451611] ip_queue_xmit+0x4c9/0x5a4 2007-01-16 00:44:43.618955500 4[ 5672.928461] [c04628f8] tcp_transmit_skb+0x25b/0x466 2007-01-16 00:44:43.619911500 4[ 5672.929417] [c04656ee] tcp_connect+0x133/0x1d1 2007-01-16 00:44:43.620865500 4[ 5672.930371] [c0467343] tcp_v4_connect+0x404/0x750 2007-01-16 00:44:43.621821500 4[ 5672.931327] [c0474be0] inet_stream_connect+0x123/0x1b1 2007-01-16 00:44:43.622789500 4[ 5672.932295] [c04235ed] sys_connect+0x9c/0xbe 2007-01-16 00:44:43.623679500 4[ 5672.933185] [c04240ae] sys_socketcall+0xd2/0x272 2007-01-16 00:44:43.624612500 4[ 5672.934072] [c0102e77] syscall_call+0x7/0xb 2007-01-16 00:44:43.624614500 4[ 5672.934092] [00645410] 0x645410 2007-01-16 00:44:43.624615500 4[ 5672.934116] === -- - 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: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
On Tue, Jan 09, 2007 at 17:48:04 -0800, Auke Kok wrote: > Sami Farin wrote: > >On Tue, Jan 09, 2007 at 15:59:30 -0800, Auke Kok wrote: > >>Sami Farin wrote: > >... > >>>I do "ethtool -K eth0 tso off" now and check if I get the hang again. =) > >>I'm unsure whether v7.2.x already automatically disables TSO for 100mbit > >>speed link, probably not. It should. > > > >It disabled it but I enabled it just for fun. > > > >>Please try our updated driver from http://e1000.sf.net/ (7.3.20) against > >>the same kernel. There are some changes with regard to the ich8/TSO > >>driver that might affect this, so re-testing is worth it for us. > > > >I now run 7.3.20-NAPI. > > > >BTW. the Makefile is buggy: it does not get CC from kernel's Makefile. > >Using wrong compiler can cause for example a reboot when loading the > >module. > >(At least that's what happened with gcc-2.95.3 vs 3.x.x some years ago...) > > I'll look into that, do you have any suggestions? loop-AES has some hacks which figure out the correct CC http://heanet.dl.sourceforge.net/sourceforge/loop-aes/loop-AES-v3.1e.tar.bz2 > >>also, please always include the full dmesg output. Feel free to CC > >>[EMAIL PROTECTED] on this. > > > >I enabled TSO again. I write again if TSO causes problems. > > There are known problems with that configuration, that's why the newer > drivers disable TSO for 10/100 speeds. > > do you really think that you can see the performance gain fro musing TSO at No. I was thinking that if TSO does not work at 100, why 1000 would be any better. But I can't test at 1000 speeds right now. But if you say driver is supposed to hang at 100 speed, I believe you. Ohh... that was fast. 2007-01-10 04:07:42.303056500 <3>e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-10 04:07:42.303081500 <4> Tx Queue <0> 2007-01-10 04:07:42.303082500 <4> TDH <48> 2007-01-10 04:07:42.303083500 <4> TDT 2007-01-10 04:07:42.303084500 <4> next_to_use 2007-01-10 04:07:42.303085500 <4> next_to_clean<48> 2007-01-10 04:07:42.303086500 <4>buffer_info[next_to_clean] 2007-01-10 04:07:42.303087500 <4> time_stamp <9e332d8> 2007-01-10 04:07:42.303088500 <4> next_to_watch<49> 2007-01-10 04:07:42.303088500 <4> jiffies <9e336df> 2007-01-10 04:07:42.303094500 <4> next_to_watch.status <0> 2007-01-10 04:07:43.302826500 <3>e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-10 04:07:43.302850500 <4> Tx Queue <0> 2007-01-10 04:07:43.302851500 <4> TDH <48> 2007-01-10 04:07:43.302852500 <4> TDT <34> 2007-01-10 04:07:43.302853500 <4> next_to_use <34> 2007-01-10 04:07:43.302854500 <4> next_to_clean<48> 2007-01-10 04:07:43.302855500 <4>buffer_info[next_to_clean] 2007-01-10 04:07:43.302855500 <4> time_stamp <9e332d8> 2007-01-10 04:07:43.302856500 <4> next_to_watch<49> 2007-01-10 04:07:43.302857500 <4> jiffies <9e33ac7> 2007-01-10 04:07:43.302862500 <4> next_to_watch.status <0> ... > those speeds anyway? we don't ;). In any case you should keep TSO off for > 10/100 speeds. ... > >PS. please do not delete Mail-Followup-To header field. > > I hit "reply-all" and I have no control over which field thunderbird I hit list-reply. > removes or adds. I have to manually add your e-mail address too? No. > Maybe your mail client is broken instead? No. > Don't you want to receive replies? Yes. I am subscribed to the mailing list. That's why my email was not in Mail-Followup-To. But if your thunderbird does not support Mail-Followup-To, just ignore it. I can add the header field manually. -- - 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: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
On Tue, Jan 09, 2007 at 15:59:30 -0800, Auke Kok wrote: > Sami Farin wrote: ... > >I do "ethtool -K eth0 tso off" now and check if I get the hang again. =) > > I'm unsure whether v7.2.x already automatically disables TSO for 100mbit > speed link, probably not. It should. It disabled it but I enabled it just for fun. > Please try our updated driver from http://e1000.sf.net/ (7.3.20) against > the same kernel. There are some changes with regard to the ich8/TSO driver > that might affect this, so re-testing is worth it for us. I now run 7.3.20-NAPI. BTW. the Makefile is buggy: it does not get CC from kernel's Makefile. Using wrong compiler can cause for example a reboot when loading the module. (At least that's what happened with gcc-2.95.3 vs 3.x.x some years ago...) > also, please always include the full dmesg output. Feel free to CC > [EMAIL PROTECTED] on this. I enabled TSO again. I write again if TSO causes problems. Why shouldn't it work with 100 Mbps? Not that it would help a lot, but I ask this on principle. /* disable TSO for pcie and 10/100 speeds, to avoid * some hardware issues */ Issues on the motherboard or the NIC? 2007-01-10 02:39:51.889908500 <6>ACPI: PCI interrupt for device :00:19.0 disabled 2007-01-10 02:39:54.545194500 <6>Intel(R) PRO/1000 Network Driver - version 7.3.20-NAPI 2007-01-10 02:39:54.545198500 <6>Copyright (c) 1999-2006 Intel Corporation. 2007-01-10 02:39:54.545395500 <6>ACPI: PCI Interrupt :00:19.0[A] -> GSI 20 (level, low) -> IRQ 22 2007-01-10 02:39:54.545435500 <7>PCI: Setting latency timer of device :00:19.0 to 64 2007-01-10 02:39:54.562905500 <6>e1000: :00:19.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:19:d1:00:5f:01 2007-01-10 02:39:54.638093500 <6>e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection 2007-01-10 02:40:07.513619500 <6>ADDRCONF(NETDEV_UP): eth0: link is not ready 2007-01-10 02:40:07.614768500 <6>e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None 2007-01-10 02:40:07.614770500 <6>e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO 2007-01-10 02:40:07.614771500 <6>ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready 2007-01-10 02:40:09.271631500 <3>e1000: eth0: e1000_reset: Hardware Error 2007-01-10 02:40:10.93500 <6>e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None 2007-01-10 02:40:10.930049500 <6>e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO PS. please do not delete Mail-Followup-To header field. -- - 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/
e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Linux 2.6.19.1 SMP on Pentium D, Intel DQ965GF mobo. Got this while bittorrenting knoppix: 2007-01-09 22:53:40.020693500 <4>NETFILTER drop IN=eth0 OUT= MAC=00:19:d1:00:5f:01:00:05:00:1c:58:1c:08:00 SRC=83.46.5.76 DST=80.223.106.128 LEN=121 TOS=0x00 PREC=0x00 TTL=112 ID=53273 PROTO=ICMP TYPE=3 CODE=3 [SRC=80.223.106.128 DST=192.168.1.37 LEN=93 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=UDP SPT=6881 DPT=6895 LEN=73 ] 2007-01-09 22:53:41.660249500 <3>e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:41.660253500 <4> Tx Queue <0> 2007-01-09 22:53:41.660254500 <4> TDH <3c> 2007-01-09 22:53:41.660255500 <4> TDT 2007-01-09 22:53:41.660255500 <4> next_to_use 2007-01-09 22:53:41.660256500 <4> next_to_clean<3c> 2007-01-09 22:53:41.660257500 <4>buffer_info[next_to_clean] 2007-01-09 22:53:41.660258500 <4> time_stamp <8c3b8e4> 2007-01-09 22:53:41.660259500 <4> next_to_watch<3f> 2007-01-09 22:53:41.660274500 <4> jiffies <8c3bf13> 2007-01-09 22:53:41.660275500 <4> next_to_watch.status <0> 2007-01-09 22:53:42.660365500 <3>e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:42.660368500 <4> Tx Queue <0> 2007-01-09 22:53:42.660369500 <4> TDH <3c> 2007-01-09 22:53:42.660370500 <4> TDT 2007-01-09 22:53:42.660370500 <4> next_to_use 2007-01-09 22:53:42.660371500 <4> next_to_clean<3c> 2007-01-09 22:53:42.660372500 <4>buffer_info[next_to_clean] 2007-01-09 22:53:42.660373500 <4> time_stamp <8c3b8e4> 2007-01-09 22:53:42.660374500 <4> next_to_watch<3f> 2007-01-09 22:53:42.660389500 <4> jiffies <8c3c2fb> 2007-01-09 22:53:42.660390500 <4> next_to_watch.status <0> 2007-01-09 22:53:43.660086500 <3>e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:43.660089500 <4> Tx Queue <0> 2007-01-09 22:53:43.660090500 <4> TDH <3c> 2007-01-09 22:53:43.660091500 <4> TDT 2007-01-09 22:53:43.660092500 <4> next_to_use 2007-01-09 22:53:43.660093500 <4> next_to_clean<3c> 2007-01-09 22:53:43.660093500 <4>buffer_info[next_to_clean] 2007-01-09 22:53:43.660094500 <4> time_stamp <8c3b8e4> 2007-01-09 22:53:43.660095500 <4> next_to_watch<3f> 2007-01-09 22:53:43.660110500 <4> jiffies <8c3c6e3> 2007-01-09 22:53:43.660111500 <4> next_to_watch.status <0> 2007-01-09 22:53:44.660001500 <3>e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:44.660004500 <4> Tx Queue <0> 2007-01-09 22:53:44.660005500 <4> TDH <3c> 2007-01-09 22:53:44.660006500 <4> TDT 2007-01-09 22:53:44.660007500 <4> next_to_use 2007-01-09 22:53:44.660008500 <4> next_to_clean<3c> 2007-01-09 22:53:44.660009500 <4>buffer_info[next_to_clean] 2007-01-09 22:53:44.660009500 <4> time_stamp <8c3b8e4> 2007-01-09 22:53:44.660010500 <4> next_to_watch<3f> 2007-01-09 22:53:44.660026500 <4> jiffies <8c3cacb> 2007-01-09 22:53:44.660027500 <4> next_to_watch.status <0> 2007-01-09 22:53:45.659906500 <3>e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:45.659909500 <4> Tx Queue <0> 2007-01-09 22:53:45.659909500 <4> TDH <3c> 2007-01-09 22:53:45.659910500 <4> TDT 2007-01-09 22:53:45.659911500 <4> next_to_use 2007-01-09 22:53:45.659912500 <4> next_to_clean<3c> 2007-01-09 22:53:45.659913500 <4>buffer_info[next_to_clean] 2007-01-09 22:53:45.659914500 <4> time_stamp <8c3b8e4> 2007-01-09 22:53:45.659915500 <4> next_to_watch<3f> 2007-01-09 22:53:45.659930500 <4> jiffies <8c3ceb3> 2007-01-09 22:53:45.659931500 <4> next_to_watch.status <0> 2007-01-09 22:53:46.659784500 <3>e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:46.659787500 <4> Tx Queue <0> 2007-01-09 22:53:46.659788500 <4> TDH <3c> 2007-01-09 22:53:46.659788500 <4> TDT 2007-01-09 22:53:46.659789500 <4> next_to_use 2007-01-09 22:53:46.659790500 <4> next_to_clean<3c> 2007-01-09 22:53:46.659791500 <4>buffer_info[next_to_clean] 2007-01-09 22:53:46.659792500 <4> time_stamp <8c3b8e4> 2007-01-09 22:53:46.659793500 <4> next_to_watch<3f> 2007-01-09 22:53:46.659807500 <4> jiffies <8c3d29b> 2007-01-09 22:53:46.659808500 <4> next_to_watch.status <0> 2007-01-09 22:53:47.130361500 <6>NETDEV WATCHDOG: eth0: transmit timed out 2007-01-09 22:53:48.771500500 <6>e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex 2007-01-09 22:53:54.838031500 <4>NETFILTER drop IN=eth0 OUT= MAC=00:19:d1:00:5f:01:00:05:00:1c:58:1c:08:00 SRC=84.49.68.15 DST=80.223.106.128 LEN=56 TOS=0x00 PREC=0x00 TTL=142 ID=55046 PROTO=ICMP TYPE=3 CODE=1
e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Linux 2.6.19.1 SMP on Pentium D, Intel DQ965GF mobo. Got this while bittorrenting knoppix: 2007-01-09 22:53:40.020693500 4NETFILTER drop IN=eth0 OUT= MAC=00:19:d1:00:5f:01:00:05:00:1c:58:1c:08:00 SRC=83.46.5.76 DST=80.223.106.128 LEN=121 TOS=0x00 PREC=0x00 TTL=112 ID=53273 PROTO=ICMP TYPE=3 CODE=3 [SRC=80.223.106.128 DST=192.168.1.37 LEN=93 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=UDP SPT=6881 DPT=6895 LEN=73 ] 2007-01-09 22:53:41.660249500 3e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:41.660253500 4 Tx Queue 0 2007-01-09 22:53:41.660254500 4 TDH 3c 2007-01-09 22:53:41.660255500 4 TDT ca 2007-01-09 22:53:41.660255500 4 next_to_use ca 2007-01-09 22:53:41.660256500 4 next_to_clean3c 2007-01-09 22:53:41.660257500 4buffer_info[next_to_clean] 2007-01-09 22:53:41.660258500 4 time_stamp 8c3b8e4 2007-01-09 22:53:41.660259500 4 next_to_watch3f 2007-01-09 22:53:41.660274500 4 jiffies 8c3bf13 2007-01-09 22:53:41.660275500 4 next_to_watch.status 0 2007-01-09 22:53:42.660365500 3e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:42.660368500 4 Tx Queue 0 2007-01-09 22:53:42.660369500 4 TDH 3c 2007-01-09 22:53:42.660370500 4 TDT ca 2007-01-09 22:53:42.660370500 4 next_to_use ca 2007-01-09 22:53:42.660371500 4 next_to_clean3c 2007-01-09 22:53:42.660372500 4buffer_info[next_to_clean] 2007-01-09 22:53:42.660373500 4 time_stamp 8c3b8e4 2007-01-09 22:53:42.660374500 4 next_to_watch3f 2007-01-09 22:53:42.660389500 4 jiffies 8c3c2fb 2007-01-09 22:53:42.660390500 4 next_to_watch.status 0 2007-01-09 22:53:43.660086500 3e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:43.660089500 4 Tx Queue 0 2007-01-09 22:53:43.660090500 4 TDH 3c 2007-01-09 22:53:43.660091500 4 TDT ca 2007-01-09 22:53:43.660092500 4 next_to_use ca 2007-01-09 22:53:43.660093500 4 next_to_clean3c 2007-01-09 22:53:43.660093500 4buffer_info[next_to_clean] 2007-01-09 22:53:43.660094500 4 time_stamp 8c3b8e4 2007-01-09 22:53:43.660095500 4 next_to_watch3f 2007-01-09 22:53:43.660110500 4 jiffies 8c3c6e3 2007-01-09 22:53:43.660111500 4 next_to_watch.status 0 2007-01-09 22:53:44.660001500 3e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:44.660004500 4 Tx Queue 0 2007-01-09 22:53:44.660005500 4 TDH 3c 2007-01-09 22:53:44.660006500 4 TDT ca 2007-01-09 22:53:44.660007500 4 next_to_use ca 2007-01-09 22:53:44.660008500 4 next_to_clean3c 2007-01-09 22:53:44.660009500 4buffer_info[next_to_clean] 2007-01-09 22:53:44.660009500 4 time_stamp 8c3b8e4 2007-01-09 22:53:44.660010500 4 next_to_watch3f 2007-01-09 22:53:44.660026500 4 jiffies 8c3cacb 2007-01-09 22:53:44.660027500 4 next_to_watch.status 0 2007-01-09 22:53:45.659906500 3e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:45.659909500 4 Tx Queue 0 2007-01-09 22:53:45.659909500 4 TDH 3c 2007-01-09 22:53:45.659910500 4 TDT ca 2007-01-09 22:53:45.659911500 4 next_to_use ca 2007-01-09 22:53:45.659912500 4 next_to_clean3c 2007-01-09 22:53:45.659913500 4buffer_info[next_to_clean] 2007-01-09 22:53:45.659914500 4 time_stamp 8c3b8e4 2007-01-09 22:53:45.659915500 4 next_to_watch3f 2007-01-09 22:53:45.659930500 4 jiffies 8c3ceb3 2007-01-09 22:53:45.659931500 4 next_to_watch.status 0 2007-01-09 22:53:46.659784500 3e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:46.659787500 4 Tx Queue 0 2007-01-09 22:53:46.659788500 4 TDH 3c 2007-01-09 22:53:46.659788500 4 TDT ca 2007-01-09 22:53:46.659789500 4 next_to_use ca 2007-01-09 22:53:46.659790500 4 next_to_clean3c 2007-01-09 22:53:46.659791500 4buffer_info[next_to_clean] 2007-01-09 22:53:46.659792500 4 time_stamp 8c3b8e4 2007-01-09 22:53:46.659793500 4 next_to_watch3f 2007-01-09 22:53:46.659807500 4 jiffies 8c3d29b 2007-01-09 22:53:46.659808500 4 next_to_watch.status 0 2007-01-09 22:53:47.130361500 6NETDEV WATCHDOG: eth0: transmit timed out 2007-01-09 22:53:48.771500500 6e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex 2007-01-09 22:53:54.838031500 4NETFILTER drop IN=eth0 OUT= MAC=00:19:d1:00:5f:01:00:05:00:1c:58:1c:08:00 SRC=84.49.68.15 DST=80.223.106.128 LEN=56 TOS=0x00 PREC=0x00 TTL=142 ID=55046 PROTO=ICMP TYPE=3 CODE=1 [SRC=80.223.106.128 DST=10.0.0.2 LEN=91 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=UDP SPT=6881 DPT=4412 LEN=71 ] ...and... 2007-01-09 23:40:42.311352500 4NETFILTER drop IN=eth0 OUT=
Re: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
On Tue, Jan 09, 2007 at 15:59:30 -0800, Auke Kok wrote: Sami Farin wrote: ... I do ethtool -K eth0 tso off now and check if I get the hang again. =) I'm unsure whether v7.2.x already automatically disables TSO for 100mbit speed link, probably not. It should. It disabled it but I enabled it just for fun. Please try our updated driver from http://e1000.sf.net/ (7.3.20) against the same kernel. There are some changes with regard to the ich8/TSO driver that might affect this, so re-testing is worth it for us. I now run 7.3.20-NAPI. BTW. the Makefile is buggy: it does not get CC from kernel's Makefile. Using wrong compiler can cause for example a reboot when loading the module. (At least that's what happened with gcc-2.95.3 vs 3.x.x some years ago...) also, please always include the full dmesg output. Feel free to CC [EMAIL PROTECTED] on this. I enabled TSO again. I write again if TSO causes problems. Why shouldn't it work with 100 Mbps? Not that it would help a lot, but I ask this on principle. /* disable TSO for pcie and 10/100 speeds, to avoid * some hardware issues */ Issues on the motherboard or the NIC? 2007-01-10 02:39:51.889908500 6ACPI: PCI interrupt for device :00:19.0 disabled 2007-01-10 02:39:54.545194500 6Intel(R) PRO/1000 Network Driver - version 7.3.20-NAPI 2007-01-10 02:39:54.545198500 6Copyright (c) 1999-2006 Intel Corporation. 2007-01-10 02:39:54.545395500 6ACPI: PCI Interrupt :00:19.0[A] - GSI 20 (level, low) - IRQ 22 2007-01-10 02:39:54.545435500 7PCI: Setting latency timer of device :00:19.0 to 64 2007-01-10 02:39:54.562905500 6e1000: :00:19.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:19:d1:00:5f:01 2007-01-10 02:39:54.638093500 6e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection 2007-01-10 02:40:07.513619500 6ADDRCONF(NETDEV_UP): eth0: link is not ready 2007-01-10 02:40:07.614768500 6e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None 2007-01-10 02:40:07.614770500 6e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO 2007-01-10 02:40:07.614771500 6ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready 2007-01-10 02:40:09.271631500 3e1000: eth0: e1000_reset: Hardware Error 2007-01-10 02:40:10.93500 6e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None 2007-01-10 02:40:10.930049500 6e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO PS. please do not delete Mail-Followup-To header field. -- - 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: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
On Tue, Jan 09, 2007 at 17:48:04 -0800, Auke Kok wrote: Sami Farin wrote: On Tue, Jan 09, 2007 at 15:59:30 -0800, Auke Kok wrote: Sami Farin wrote: ... I do ethtool -K eth0 tso off now and check if I get the hang again. =) I'm unsure whether v7.2.x already automatically disables TSO for 100mbit speed link, probably not. It should. It disabled it but I enabled it just for fun. Please try our updated driver from http://e1000.sf.net/ (7.3.20) against the same kernel. There are some changes with regard to the ich8/TSO driver that might affect this, so re-testing is worth it for us. I now run 7.3.20-NAPI. BTW. the Makefile is buggy: it does not get CC from kernel's Makefile. Using wrong compiler can cause for example a reboot when loading the module. (At least that's what happened with gcc-2.95.3 vs 3.x.x some years ago...) I'll look into that, do you have any suggestions? loop-AES has some hacks which figure out the correct CC http://heanet.dl.sourceforge.net/sourceforge/loop-aes/loop-AES-v3.1e.tar.bz2 also, please always include the full dmesg output. Feel free to CC [EMAIL PROTECTED] on this. I enabled TSO again. I write again if TSO causes problems. There are known problems with that configuration, that's why the newer drivers disable TSO for 10/100 speeds. do you really think that you can see the performance gain fro musing TSO at No. I was thinking that if TSO does not work at 100, why 1000 would be any better. But I can't test at 1000 speeds right now. But if you say driver is supposed to hang at 100 speed, I believe you. Ohh... that was fast. 2007-01-10 04:07:42.303056500 3e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-10 04:07:42.303081500 4 Tx Queue 0 2007-01-10 04:07:42.303082500 4 TDH 48 2007-01-10 04:07:42.303083500 4 TDT fa 2007-01-10 04:07:42.303084500 4 next_to_use fa 2007-01-10 04:07:42.303085500 4 next_to_clean48 2007-01-10 04:07:42.303086500 4buffer_info[next_to_clean] 2007-01-10 04:07:42.303087500 4 time_stamp 9e332d8 2007-01-10 04:07:42.303088500 4 next_to_watch49 2007-01-10 04:07:42.303088500 4 jiffies 9e336df 2007-01-10 04:07:42.303094500 4 next_to_watch.status 0 2007-01-10 04:07:43.302826500 3e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-10 04:07:43.302850500 4 Tx Queue 0 2007-01-10 04:07:43.302851500 4 TDH 48 2007-01-10 04:07:43.302852500 4 TDT 34 2007-01-10 04:07:43.302853500 4 next_to_use 34 2007-01-10 04:07:43.302854500 4 next_to_clean48 2007-01-10 04:07:43.302855500 4buffer_info[next_to_clean] 2007-01-10 04:07:43.302855500 4 time_stamp 9e332d8 2007-01-10 04:07:43.302856500 4 next_to_watch49 2007-01-10 04:07:43.302857500 4 jiffies 9e33ac7 2007-01-10 04:07:43.302862500 4 next_to_watch.status 0 ... those speeds anyway? we don't ;). In any case you should keep TSO off for 10/100 speeds. ... PS. please do not delete Mail-Followup-To header field. I hit reply-all and I have no control over which field thunderbird I hit list-reply. removes or adds. I have to manually add your e-mail address too? No. Maybe your mail client is broken instead? No. Don't you want to receive replies? Yes. I am subscribed to the mailing list. That's why my email was not in Mail-Followup-To. But if your thunderbird does not support Mail-Followup-To, just ignore it. I can add the header field manually. -- - 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: warning at mm/truncate.c:60/cancel_dirty_page()
On Mon, Jan 08, 2007 at 10:04:36 +1100, David Chinner wrote: > On Sun, Jan 07, 2007 at 02:48:12PM -0800, Andrew Morton wrote: > > On Mon, 8 Jan 2007 09:23:41 +1100 > > David Chinner <[EMAIL PROTECTED]> wrote: > > > > > How are you supposed to invalidate a range of pages in a mapping for > > > this case, then? invalidate_mapping_pages() would appear to be the > > > candidate (the generic code uses this), but it _skips_ pages that > > > are already mapped. > > > > unmap_mapping_range()? > > /me looks at how it's used in invalidate_inode_pages2_range() and > decides it's easier not to call this directly. > > > > So, am I correct in assuming we should be calling > > > invalidate_inode_pages2_range() > > > instead of truncate_inode_pages()? > > > > That would be conventional. > > in that case the following patch should fix the warning: I tried dt+strace+cinfo with this patch applied and got no warnings. Thanks for quick fix. -- Do what you love because life is too short for anything else. - 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: xfs_file_ioctl / xfs_freeze: BUG: warning at kernel/mutex-debug.c:80/debug_mutex_unlock()
On Mon, Jan 08, 2007 at 08:37:34 +1100, David Chinner wrote: ... > > fstab was there just fine after -u. > > Oh, that still hasn't been fixed? Looked like it =) > Generic bug, not XFS - the global > semaphore->mutex cleanup converted the bd_mount_sem to a mutex, and > mutexes complain loudly when a the process unlocking the mutex is > not the process that locked it. > > Basically, the generic code is broken - the bd_mount_mutex needs to > be reverted back to a semaphore because it is locked and unlocked > by different processes. The following patch does this > > BTW, Sami, can you cc [EMAIL PROTECTED] on XFS bug reports in future; > you'll get more XFS savvy eyes there. Forgot to. Thanks for patch. It fixed the issue, no more warnings. BTW. the fix is not in 2.6.git, either. -- Do what you love because life is too short for anything else. - 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: xfs_file_ioctl / xfs_freeze: BUG: warning at kernel/mutex-debug.c:80/debug_mutex_unlock()
On Mon, Jan 08, 2007 at 08:37:34 +1100, David Chinner wrote: ... fstab was there just fine after -u. Oh, that still hasn't been fixed? Looked like it =) Generic bug, not XFS - the global semaphore-mutex cleanup converted the bd_mount_sem to a mutex, and mutexes complain loudly when a the process unlocking the mutex is not the process that locked it. Basically, the generic code is broken - the bd_mount_mutex needs to be reverted back to a semaphore because it is locked and unlocked by different processes. The following patch does this BTW, Sami, can you cc [EMAIL PROTECTED] on XFS bug reports in future; you'll get more XFS savvy eyes there. Forgot to. Thanks for patch. It fixed the issue, no more warnings. BTW. the fix is not in 2.6.git, either. -- Do what you love because life is too short for anything else. - 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: warning at mm/truncate.c:60/cancel_dirty_page()
On Mon, Jan 08, 2007 at 10:04:36 +1100, David Chinner wrote: On Sun, Jan 07, 2007 at 02:48:12PM -0800, Andrew Morton wrote: On Mon, 8 Jan 2007 09:23:41 +1100 David Chinner [EMAIL PROTECTED] wrote: How are you supposed to invalidate a range of pages in a mapping for this case, then? invalidate_mapping_pages() would appear to be the candidate (the generic code uses this), but it _skips_ pages that are already mapped. unmap_mapping_range()? /me looks at how it's used in invalidate_inode_pages2_range() and decides it's easier not to call this directly. So, am I correct in assuming we should be calling invalidate_inode_pages2_range() instead of truncate_inode_pages()? That would be conventional. in that case the following patch should fix the warning: I tried dt+strace+cinfo with this patch applied and got no warnings. Thanks for quick fix. -- Do what you love because life is too short for anything else. - 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: warning at mm/truncate.c:60/cancel_dirty_page()
On Sat, Jan 06, 2007 at 21:11:07 +, Hugh Dickins wrote:
> On Sat, 6 Jan 2007, Sami Farin wrote:
>
> > Linux 2.6.19.1 SMP [2] on Pentium D...
> > I was running dt-15.14 [2] and I ran
> > "cinfo datafile" (it does mincore()).
> > Well it went OK but when I ran "strace cinfo datafile"...:
> > 04:18:48.062466 mincore(0x37f1f000, 2147266560,
>
> You rightly noted in a followup that there have been changes to
> mincore, but I doubt they have any bearing on this: I think the
> BUG just happened at the same time as your mincore.
BUG does not happen if I do not do "strace cinfo dtfile" with O_DIRECT
test file. It's easy to reproduce.
Without strace BUG does not happen.
Now I got it again, with also the mincore patch applied:
01:48:42.831060 mincore(0x37ff1000, 2147254272, ^[
2007-01-07 01:48:51.480531500 <4>BUG: warning at
mm/truncate.c:60/cancel_dirty_page()
2007-01-07 01:48:51.480532500 <4> [] dump_trace+0x215/0x21a
2007-01-07 01:48:51.480557500 <4> [] show_trace_log_lvl+0x1a/0x30
2007-01-07 01:48:51.480559500 <4> [] show_trace+0x12/0x14
2007-01-07 01:48:51.480560500 <4> [] dump_stack+0x19/0x1b
2007-01-07 01:48:51.480561500 <4> [] cancel_dirty_page+0x7e/0x80
2007-01-07 01:48:51.480562500 <4> [] truncate_complete_page+0x1a/0x47
2007-01-07 01:48:51.480563500 <4> []
truncate_inode_pages_range+0x114/0x2ae
2007-01-07 01:48:51.480564500 <4> [] truncate_inode_pages+0x1a/0x1c
2007-01-07 01:48:51.480574500 <4> [] fs_flushinval_pages+0x40/0x77
2007-01-07 01:48:51.480575500 <4> [] xfs_write+0x8c4/0xb68
2007-01-07 01:48:51.480576500 <4> [] xfs_file_aio_write+0x7e/0x95
2007-01-07 01:48:51.480577500 <4> [] do_sync_write+0xca/0x119
2007-01-07 01:48:51.480578500 <4> [] vfs_write+0x187/0x18c
2007-01-07 01:48:51.480579500 <4> [] sys_write+0x3d/0x64
2007-01-07 01:48:51.480589500 <4> [] syscall_call+0x7/0xb
2007-01-07 01:48:51.480590500 <4> [<00bed410>] 0xbed410
$ /sbin/sysctl -n vm.dirty_expire_centisecs
999
cancel_dirty_page would be more useful if it executed WARN_ON
at max once per 10s or something instead of five times out of 2^32 or 2^64
errors... I mean, user might think program/kernel started to work OK when
BUGs stop if he/she doesn't check cancel_dirty_page() function.
--- linux-2.6.19/mm/truncate.c.bak 2007-01-01 19:10:00.62731 +0200
+++ linux-2.6.19/mm/truncate.c 2007-01-07 02:35:53.786636897 +0200
@@ -55,11 +55,16 @@ void cancel_dirty_page(struct page *page
{
/* If we're cancelling the page, it had better not be mapped any more */
if (page_mapped(page)) {
- static unsigned int warncount;
+ static int first = 1;
+ static unsigned long lastwarn;
- WARN_ON(++warncount < 5);
+ if (unlikely(first) || time_after(jiffies, (lastwarn + 10*HZ)))
{
+ first = 0;
+ lastwarn = jiffies;
+ WARN_ON(42);
+ }
}
-
+
if (TestClearPageDirty(page)) {
struct address_space *mapping = page->mapping;
if (mapping && mapping_cap_account_dirty(mapping)) {
> > ...
> > 2007-01-06 04:19:03.788181500 <4>BUG: warning at
> > mm/truncate.c:60/cancel_dirty_page()
> > 2007-01-06 04:19:03.788221500 <4> [] dump_trace+0x215/0x21a
> > 2007-01-06 04:19:03.788223500 <4> [] show_trace_log_lvl+0x1a/0x30
> > 2007-01-06 04:19:03.788224500 <4> [] show_trace+0x12/0x14
> > 2007-01-06 04:19:03.788225500 <4> [] dump_stack+0x19/0x1b
> > 2007-01-06 04:19:03.788227500 <4> [] cancel_dirty_page+0x7e/0x80
> > 2007-01-06 04:19:03.788228500 <4> []
> > truncate_complete_page+0x1a/0x47
> > 2007-01-06 04:19:03.788229500 <4> []
> > truncate_inode_pages_range+0x114/0x2ae
> > 2007-01-06 04:19:03.788245500 <4> []
> > truncate_inode_pages+0x1a/0x1c
> > 2007-01-06 04:19:03.788247500 <4> [] fs_flushinval_pages+0x40/0x77
> > 2007-01-06 04:19:03.788248500 <4> [] xfs_write+0x8c4/0xb68
> > 2007-01-06 04:19:03.788250500 <4> [] xfs_file_aio_write+0x7e/0x95
> > 2007-01-06 04:19:03.788251500 <4> [] do_sync_write+0xca/0x119
> > 2007-01-06 04:19:03.788265500 <4> [] vfs_write+0x187/0x18c
> > 2007-01-06 04:19:03.788267500 <4> [] sys_write+0x3d/0x64
> > 2007-01-06 04:19:03.788268500 <4> [] syscall_call+0x7/0xb
> > 2007-01-06 04:19:03.788269500 <4> [<001cf410>] 0x1cf410
> > 2007-01-06 04:19:03.788289500 <4> ===
>
> So... XFS uses truncate_inode_pages when serving the write system call.
> That's very inventive, and now it looks like Linus' cancel_dirty_page
> and
Re: BUG: warning at mm/truncate.c:60/cancel_dirty_page()
On Sat, Jan 06, 2007 at 21:11:07 +, Hugh Dickins wrote:
On Sat, 6 Jan 2007, Sami Farin wrote:
Linux 2.6.19.1 SMP [2] on Pentium D...
I was running dt-15.14 [2] and I ran
cinfo datafile (it does mincore()).
Well it went OK but when I ran strace cinfo datafile...:
04:18:48.062466 mincore(0x37f1f000, 2147266560,
You rightly noted in a followup that there have been changes to
mincore, but I doubt they have any bearing on this: I think the
BUG just happened at the same time as your mincore.
BUG does not happen if I do not do strace cinfo dtfile with O_DIRECT
test file. It's easy to reproduce.
Without strace BUG does not happen.
Now I got it again, with also the mincore patch applied:
01:48:42.831060 mincore(0x37ff1000, 2147254272, ^[
2007-01-07 01:48:51.480531500 4BUG: warning at
mm/truncate.c:60/cancel_dirty_page()
2007-01-07 01:48:51.480532500 4 [c0103cff] dump_trace+0x215/0x21a
2007-01-07 01:48:51.480557500 4 [c0103da7] show_trace_log_lvl+0x1a/0x30
2007-01-07 01:48:51.480559500 4 [c0103dcf] show_trace+0x12/0x14
2007-01-07 01:48:51.480560500 4 [c0103ecc] dump_stack+0x19/0x1b
2007-01-07 01:48:51.480561500 4 [c0155616] cancel_dirty_page+0x7e/0x80
2007-01-07 01:48:51.480562500 4 [c0155632] truncate_complete_page+0x1a/0x47
2007-01-07 01:48:51.480563500 4 [c01557c4]
truncate_inode_pages_range+0x114/0x2ae
2007-01-07 01:48:51.480564500 4 [c0155978] truncate_inode_pages+0x1a/0x1c
2007-01-07 01:48:51.480574500 4 [c026a558] fs_flushinval_pages+0x40/0x77
2007-01-07 01:48:51.480575500 4 [c026e7a8] xfs_write+0x8c4/0xb68
2007-01-07 01:48:51.480576500 4 [c0269e28] xfs_file_aio_write+0x7e/0x95
2007-01-07 01:48:51.480577500 4 [c016e5d0] do_sync_write+0xca/0x119
2007-01-07 01:48:51.480578500 4 [c016e7a6] vfs_write+0x187/0x18c
2007-01-07 01:48:51.480579500 4 [c016e84c] sys_write+0x3d/0x64
2007-01-07 01:48:51.480589500 4 [c0102e77] syscall_call+0x7/0xb
2007-01-07 01:48:51.480590500 4 [00bed410] 0xbed410
$ /sbin/sysctl -n vm.dirty_expire_centisecs
999
cancel_dirty_page would be more useful if it executed WARN_ON
at max once per 10s or something instead of five times out of 2^32 or 2^64
errors... I mean, user might think program/kernel started to work OK when
BUGs stop if he/she doesn't check cancel_dirty_page() function.
--- linux-2.6.19/mm/truncate.c.bak 2007-01-01 19:10:00.62731 +0200
+++ linux-2.6.19/mm/truncate.c 2007-01-07 02:35:53.786636897 +0200
@@ -55,11 +55,16 @@ void cancel_dirty_page(struct page *page
{
/* If we're cancelling the page, it had better not be mapped any more */
if (page_mapped(page)) {
- static unsigned int warncount;
+ static int first = 1;
+ static unsigned long lastwarn;
- WARN_ON(++warncount 5);
+ if (unlikely(first) || time_after(jiffies, (lastwarn + 10*HZ)))
{
+ first = 0;
+ lastwarn = jiffies;
+ WARN_ON(42);
+ }
}
-
+
if (TestClearPageDirty(page)) {
struct address_space *mapping = page-mapping;
if (mapping mapping_cap_account_dirty(mapping)) {
...
2007-01-06 04:19:03.788181500 4BUG: warning at
mm/truncate.c:60/cancel_dirty_page()
2007-01-06 04:19:03.788221500 4 [c0103cfb] dump_trace+0x215/0x21a
2007-01-06 04:19:03.788223500 4 [c0103da3] show_trace_log_lvl+0x1a/0x30
2007-01-06 04:19:03.788224500 4 [c0103dcb] show_trace+0x12/0x14
2007-01-06 04:19:03.788225500 4 [c0103ec8] dump_stack+0x19/0x1b
2007-01-06 04:19:03.788227500 4 [c01546a6] cancel_dirty_page+0x7e/0x80
2007-01-06 04:19:03.788228500 4 [c01546c2]
truncate_complete_page+0x1a/0x47
2007-01-06 04:19:03.788229500 4 [c0154854]
truncate_inode_pages_range+0x114/0x2ae
2007-01-06 04:19:03.788245500 4 [c0154a08]
truncate_inode_pages+0x1a/0x1c
2007-01-06 04:19:03.788247500 4 [c0269244] fs_flushinval_pages+0x40/0x77
2007-01-06 04:19:03.788248500 4 [c026d48c] xfs_write+0x8c4/0xb68
2007-01-06 04:19:03.788250500 4 [c0268b14] xfs_file_aio_write+0x7e/0x95
2007-01-06 04:19:03.788251500 4 [c016d66c] do_sync_write+0xca/0x119
2007-01-06 04:19:03.788265500 4 [c016d842] vfs_write+0x187/0x18c
2007-01-06 04:19:03.788267500 4 [c016d8e8] sys_write+0x3d/0x64
2007-01-06 04:19:03.788268500 4 [c0102e73] syscall_call+0x7/0xb
2007-01-06 04:19:03.788269500 4 [001cf410] 0x1cf410
2007-01-06 04:19:03.788289500 4 ===
So... XFS uses truncate_inode_pages when serving the write system call.
That's very inventive, and now it looks like Linus' cancel_dirty_page
and new warning have caught it out. VM people expect it to be called
either when freeing an inode no longer in use, or when doing a truncate,
after ensuring that all pages mapped into userspace have been taken out.
Maybe XFS people can tell is their code doing something unwise?
And about my earlier xfs_freeze issue... =)
...
Gosh. Might be better to reproduce
Re: BUG: warning at mm/truncate.c:60/cancel_dirty_page()
On Sat, Jan 06, 2007 at 04:39:07 +0200, Sami Farin wrote: > Linux 2.6.19.1 SMP [2] on Pentium D... > I was running dt-15.14 [2] and I ran > "cinfo datafile" (it does mincore()). > Well it went OK but when I ran "strace cinfo datafile"...: > 04:18:48.062466 mincore(0x37f1f000, 2147266560, Forgot to do "git-whatchanged mm/mincore.c"... Looks like git and 2.6.19.2 review patch include a fix for mincore. Maybe it fixes this issue. -- - 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/
BUG: warning at mm/truncate.c:60/cancel_dirty_page()
Linux 2.6.19.1 SMP [2] on Pentium D... I was running dt-15.14 [2] and I ran "cinfo datafile" (it does mincore()). Well it went OK but when I ran "strace cinfo datafile"...: 04:18:48.062466 mincore(0x37f1f000, 2147266560, ... 2007-01-06 04:19:03.788181500 <4>BUG: warning at mm/truncate.c:60/cancel_dirty_page() 2007-01-06 04:19:03.788221500 <4> [] dump_trace+0x215/0x21a 2007-01-06 04:19:03.788223500 <4> [] show_trace_log_lvl+0x1a/0x30 2007-01-06 04:19:03.788224500 <4> [] show_trace+0x12/0x14 2007-01-06 04:19:03.788225500 <4> [] dump_stack+0x19/0x1b 2007-01-06 04:19:03.788227500 <4> [] cancel_dirty_page+0x7e/0x80 2007-01-06 04:19:03.788228500 <4> [] truncate_complete_page+0x1a/0x47 2007-01-06 04:19:03.788229500 <4> [] truncate_inode_pages_range+0x114/0x2ae 2007-01-06 04:19:03.788245500 <4> [] truncate_inode_pages+0x1a/0x1c 2007-01-06 04:19:03.788247500 <4> [] fs_flushinval_pages+0x40/0x77 2007-01-06 04:19:03.788248500 <4> [] xfs_write+0x8c4/0xb68 2007-01-06 04:19:03.788250500 <4> [] xfs_file_aio_write+0x7e/0x95 2007-01-06 04:19:03.788251500 <4> [] do_sync_write+0xca/0x119 2007-01-06 04:19:03.788265500 <4> [] vfs_write+0x187/0x18c 2007-01-06 04:19:03.788267500 <4> [] sys_write+0x3d/0x64 2007-01-06 04:19:03.788268500 <4> [] syscall_call+0x7/0xb 2007-01-06 04:19:03.788269500 <4> [<001cf410>] 0x1cf410 2007-01-06 04:19:03.788289500 <4> === funny that when stracing, mincore does not return? $ time cinfo dtfile-2091 dtfile-2091: 524285 pages, 0 pages cached (0.00%) real0m0.049s user0m0.003s sys 0m0.046s safari6941 29.9 10.8 2098768 108788 pts/2 D+ 04:20 3:41 strace -vfttT cinfo dtfile-2091 straceD C179A000 0 6941 8737 6942 2089 (NOTLB) e790 0046 c172e240 c179a000 c1731880 c17c51a0 c17b5be0 c1771c20 e9b1f740 0086 d55dd74c e76c c02666b8 c17fd700 c2c2513c fdac b2203610 616f c2c25030 c17fd700 e7f8 c17d31f0 e79c Call Trace: [] io_schedule+0x26/0x30 [] sync_page+0x3d/0x48 [] __wait_on_bit_lock+0x45/0x67 [] __lock_page+0x88/0x95 [] filemap_nopage+0x1f4/0x386 [] do_no_page+0x82/0x2fa [] __handle_mm_fault+0x1fe/0x2eb [] get_user_pages+0xc7/0x2e5 [] access_process_vm+0x74/0x116 [] arch_ptrace+0x388/0x539 [] sys_ptrace+0x58/0xb9 [] syscall_call+0x7/0xb [<0081e410>] 0x81e410 === cinfo t CB7DA040 0 6942 6941 (NOTLB) e5fcdee8 0046 ce7d9284 cb7da040 ce7d9284 cb7da078 cb7da040 e5fcdf10 cb7da040 13a973f5 60e3 0078 c2c25030 c1805700 d483013c 0021fd53 13a97513 60e3 d4830030 e5fcdf04 0005 e5fcdefc Call Trace: [] ptrace_stop+0xf8/0x17f [] ptrace_notify+0x6a/0x92 [] do_syscall_trace+0xd4/0x1eb [] syscall_exit_work+0x16/0x1b [<00878410>] 0x878410 === [1] includes these 8c08540f8755c451d8b96ea14cfe796bc3cd712d [PATCH] clean up __set_page_dirty_nobuffers() 55e829af06681e5d731c03ba04febbd1c76ca293 [PATCH] io-accounting: write accounting e08748ce01e02f0ec154b141f392ccb9555333f4 [PATCH] io-accounting: write-cancel accounting fba2591bf4e418b6c3f9f8794c9dd8fe40ae7bd9 VM: Remove "clear_page_dirty()" and "test_clear_page_dirty()" functions 3e67c0987d7567ad41164a153dca9a43b11d [PATCH] truncate: clear page dirtiness before running try_to_free_buffers() 5f2a105d5e33a038a717995d2738434f9c25aed2 [PATCH] truncate: dirty memory accounting fix 8368e328dfe1c534957051333a87b3210a12743b Clean up and export cancel_dirty_page() to modules 7658cc289288b8ae7dd2c2224549a048431222b3 VM: Fix nasty and subtle race in shared mmap'ed page writeback 7c3ab7381e79dfc7db14a67c6f4f3285664e1ec2 [PATCH] io-accounting: core statistics cb876f451455b6187a7d69de2c112c45ec4b7f99 Fix up CIFS for "test_clear_page_dirty()" removal 7dfb71030f7636a0d65200158113c37764552f93 [PATCH] Add include/linux/freezer.h and move definitions from sched.h 46d2277c796f9f4937bfa668c40b2e3f43e93dd0 Clean up and make try_to_free_buffers() not race with dirty e61c90188b9956edae1105eef361d8981a352fcd [PATCH] optimize o_direct on block devices 5fcf7bb73f66cc1c4ad90788b0f367c4d6852b75 [PATCH] read_zero_pagealigned() locking fix ffaa82008f1aad52a6d3979f49d2a76c2928b60f Fix reiserfs after "test_clear_page_dirty()" removal d0e671a932cb9c653b27393cec26aec012a8d97e [PATCH] Fix JFS after clear_page_dirty() removal 9280f6822c2d7112b47107251fce307aefb31f35 [PATCH] fuse: remove clear_page_dirty() call 921320210bd2ec4f17053d283355b73048ac0e56 [PATCH] Fix XFS after clear_page_dirty() removal [2] dt pattern=iot incr=variable records=32768 lbs=65536 bs=65536 of=dtfile log=dtfile.log.direct.random passes=1 procs=2 iotype=random flags=direct http://home.comcast.net/~SCSIguy/SCSI_FAQ/RMiller_Tools/ftp/dt/dt-source.tar.gz -- - To unsubscribe from this list: send the
BUG: warning at mm/truncate.c:60/cancel_dirty_page()
Linux 2.6.19.1 SMP [2] on Pentium D... I was running dt-15.14 [2] and I ran cinfo datafile (it does mincore()). Well it went OK but when I ran strace cinfo datafile...: 04:18:48.062466 mincore(0x37f1f000, 2147266560, ... 2007-01-06 04:19:03.788181500 4BUG: warning at mm/truncate.c:60/cancel_dirty_page() 2007-01-06 04:19:03.788221500 4 [c0103cfb] dump_trace+0x215/0x21a 2007-01-06 04:19:03.788223500 4 [c0103da3] show_trace_log_lvl+0x1a/0x30 2007-01-06 04:19:03.788224500 4 [c0103dcb] show_trace+0x12/0x14 2007-01-06 04:19:03.788225500 4 [c0103ec8] dump_stack+0x19/0x1b 2007-01-06 04:19:03.788227500 4 [c01546a6] cancel_dirty_page+0x7e/0x80 2007-01-06 04:19:03.788228500 4 [c01546c2] truncate_complete_page+0x1a/0x47 2007-01-06 04:19:03.788229500 4 [c0154854] truncate_inode_pages_range+0x114/0x2ae 2007-01-06 04:19:03.788245500 4 [c0154a08] truncate_inode_pages+0x1a/0x1c 2007-01-06 04:19:03.788247500 4 [c0269244] fs_flushinval_pages+0x40/0x77 2007-01-06 04:19:03.788248500 4 [c026d48c] xfs_write+0x8c4/0xb68 2007-01-06 04:19:03.788250500 4 [c0268b14] xfs_file_aio_write+0x7e/0x95 2007-01-06 04:19:03.788251500 4 [c016d66c] do_sync_write+0xca/0x119 2007-01-06 04:19:03.788265500 4 [c016d842] vfs_write+0x187/0x18c 2007-01-06 04:19:03.788267500 4 [c016d8e8] sys_write+0x3d/0x64 2007-01-06 04:19:03.788268500 4 [c0102e73] syscall_call+0x7/0xb 2007-01-06 04:19:03.788269500 4 [001cf410] 0x1cf410 2007-01-06 04:19:03.788289500 4 === funny that when stracing, mincore does not return? $ time cinfo dtfile-2091 dtfile-2091: 524285 pages, 0 pages cached (0.00%) real0m0.049s user0m0.003s sys 0m0.046s safari6941 29.9 10.8 2098768 108788 pts/2 D+ 04:20 3:41 strace -vfttT cinfo dtfile-2091 straceD C179A000 0 6941 8737 6942 2089 (NOTLB) e790 0046 c172e240 c179a000 c1731880 c17c51a0 c17b5be0 c1771c20 e9b1f740 0086 d55dd74c e76c c02666b8 c17fd700 c2c2513c fdac b2203610 616f c2c25030 c17fd700 e7f8 c17d31f0 e79c Call Trace: [c04b4568] io_schedule+0x26/0x30 [c014cdad] sync_page+0x3d/0x48 [c04b47b1] __wait_on_bit_lock+0x45/0x67 [c014d556] __lock_page+0x88/0x95 [c014e5a7] filemap_nopage+0x1f4/0x386 [c015b24c] do_no_page+0x82/0x2fa [c015b8a3] __handle_mm_fault+0x1fe/0x2eb [c0159a99] get_user_pages+0xc7/0x2e5 [c015bb8a] access_process_vm+0x74/0x116 [c010639e] arch_ptrace+0x388/0x539 [c012ad7f] sys_ptrace+0x58/0xb9 [c0102e73] syscall_call+0x7/0xb [0081e410] 0x81e410 === cinfo t CB7DA040 0 6942 6941 (NOTLB) e5fcdee8 0046 ce7d9284 cb7da040 ce7d9284 cb7da078 cb7da040 e5fcdf10 cb7da040 13a973f5 60e3 0078 c2c25030 c1805700 d483013c 0021fd53 13a97513 60e3 d4830030 e5fcdf04 0005 e5fcdefc Call Trace: [c012e32b] ptrace_stop+0xf8/0x17f [c012e41c] ptrace_notify+0x6a/0x92 [c01066a9] do_syscall_trace+0xd4/0x1eb [c0102f66] syscall_exit_work+0x16/0x1b [00878410] 0x878410 === [1] includes these 8c08540f8755c451d8b96ea14cfe796bc3cd712d [PATCH] clean up __set_page_dirty_nobuffers() 55e829af06681e5d731c03ba04febbd1c76ca293 [PATCH] io-accounting: write accounting e08748ce01e02f0ec154b141f392ccb9555333f4 [PATCH] io-accounting: write-cancel accounting fba2591bf4e418b6c3f9f8794c9dd8fe40ae7bd9 VM: Remove clear_page_dirty() and test_clear_page_dirty() functions 3e67c0987d7567ad41164a153dca9a43b11d [PATCH] truncate: clear page dirtiness before running try_to_free_buffers() 5f2a105d5e33a038a717995d2738434f9c25aed2 [PATCH] truncate: dirty memory accounting fix 8368e328dfe1c534957051333a87b3210a12743b Clean up and export cancel_dirty_page() to modules 7658cc289288b8ae7dd2c2224549a048431222b3 VM: Fix nasty and subtle race in shared mmap'ed page writeback 7c3ab7381e79dfc7db14a67c6f4f3285664e1ec2 [PATCH] io-accounting: core statistics cb876f451455b6187a7d69de2c112c45ec4b7f99 Fix up CIFS for test_clear_page_dirty() removal 7dfb71030f7636a0d65200158113c37764552f93 [PATCH] Add include/linux/freezer.h and move definitions from sched.h 46d2277c796f9f4937bfa668c40b2e3f43e93dd0 Clean up and make try_to_free_buffers() not race with dirty e61c90188b9956edae1105eef361d8981a352fcd [PATCH] optimize o_direct on block devices 5fcf7bb73f66cc1c4ad90788b0f367c4d6852b75 [PATCH] read_zero_pagealigned() locking fix ffaa82008f1aad52a6d3979f49d2a76c2928b60f Fix reiserfs after test_clear_page_dirty() removal d0e671a932cb9c653b27393cec26aec012a8d97e [PATCH] Fix JFS after clear_page_dirty() removal 9280f6822c2d7112b47107251fce307aefb31f35 [PATCH] fuse: remove clear_page_dirty() call 921320210bd2ec4f17053d283355b73048ac0e56 [PATCH] Fix XFS after clear_page_dirty() removal [2] dt pattern=iot incr=variable records=32768 lbs=65536 bs=65536 of=dtfile
Re: BUG: warning at mm/truncate.c:60/cancel_dirty_page()
On Sat, Jan 06, 2007 at 04:39:07 +0200, Sami Farin wrote: Linux 2.6.19.1 SMP [2] on Pentium D... I was running dt-15.14 [2] and I ran cinfo datafile (it does mincore()). Well it went OK but when I ran strace cinfo datafile...: 04:18:48.062466 mincore(0x37f1f000, 2147266560, Forgot to do git-whatchanged mm/mincore.c... Looks like git and 2.6.19.2 review patch include a fix for mincore. Maybe it fixes this issue. -- - 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: execve hanging in selinux_bprm_post_apply_creds
On Thu, Jan 04, 2007 at 16:03:34 -0800, Andrew Morton wrote: > On Fri, 5 Jan 2007 00:26:42 +0200 > Sami Farin <[EMAIL PROTECTED]> wrote: > > > Kernel 2.6.19.1 SMP on Pentium D. I ran command restorecon -R /wrk. > > After a while or two programs stopped responding and I had to reboot. > > > > I'm not sure is this bug or feature... > > bug ;) =) > > 2007-01-04 22:41:55.360538500 <4>softlimit D 61707865 0 18679 > > 18678 (NOTLB) > > 2007-01-04 22:41:55.360549500 <4> ec5efdd0 0046 f8964fda 61707865 > > 006a 0072 0043 005b > > 2007-01-04 22:41:55.360551500 <4> f7264580 00a9 00fb 000e > > 00cc 0055 c1805700 f4f2e13c > > 2007-01-04 22:41:55.360553500 <4> 0001be4d 1f64183b 073d f4f2e030 > > c05785ac 0246 f4f2e030 ec5efe18 > > 2007-01-04 22:41:55.360554500 <4>Call Trace: > > 2007-01-04 22:41:55.360571500 <4> [] > > __mutex_lock_slowpath+0x85/0x1df > > 2007-01-04 22:41:55.360572500 <4> [] mutex_lock+0x21/0x24 > > 2007-01-04 22:41:55.360573500 <4> [] > > selinux_bprm_post_apply_creds+0x65/0x40a > > 2007-01-04 22:41:55.360575500 <4> [] compute_creds+0x4f/0x52 > > 2007-01-04 22:41:55.360576500 <4> [] load_elf_binary+0x944/0xd0e > > 2007-01-04 22:41:55.360589500 <4> [] > > search_binary_handler+0x9a/0x24c > > 2007-01-04 22:41:55.360590500 <4> [] do_execve+0x163/0x1f1 > > 2007-01-04 22:41:55.360592500 <4> [] sys_execve+0x32/0x84 > > 2007-01-04 22:41:55.360593500 <4> [] syscall_call+0x7/0xb > > 2007-01-04 22:41:55.360594500 <4> [<00ecc410>] 0xecc410 > > 2007-01-04 22:41:55.360620500 <4> === > > > > ... > > > > 2007-01-04 22:41:55.359020500 <4>crond D DDC59E64 0 18627 > > 1837 18668 (NOTLB) > > 2007-01-04 22:41:55.359022500 <4> ddc59e78 0046 c01454c5 ddc59e64 > > ddc59e58 c04f4d56 ddc59e74 00d0 > > 2007-01-04 22:41:55.359033500 <4> f7a50ac0 f78d8a5e 06e3 11f7 > > c1967030 c17fd700 d10a6b7c > > 2007-01-04 22:41:55.359034500 <4> 000166f0 f78db4eb 06e3 d10a6a70 > > c05785ac 0246 d10a6a70 ddc59ec0 > > 2007-01-04 22:41:55.359036500 <4>Call Trace: > > 2007-01-04 22:41:55.359037500 <4> [] > > __mutex_lock_slowpath+0x85/0x1df > > 2007-01-04 22:41:55.359047500 <4> [] mutex_lock+0x21/0x24 > > 2007-01-04 22:41:55.359049500 <4> [] audit_log_exit+0x120/0x799 > > 2007-01-04 22:41:55.359050500 <4> [] audit_syscall_exit+0x75/0x325 > > 2007-01-04 22:41:55.359051500 <4> [] do_syscall_trace+0x1a5/0x1eb > > -- > > 2007-01-04 22:41:55.359305500 <4> 2d6d 33456ed0 06e5 e7163a70 > > 7fff 7fff ed0aa9e0 e4c03d5c > > 2007-01-04 22:41:55.359306500 <4>Call Trace: > > 2007-01-04 22:41:55.359319500 <4> [] schedule_timeout+0x94/0x96 > > 2007-01-04 22:41:55.359321500 <4> [] > > unix_stream_data_wait+0xa0/0xe7 > > 2007-01-04 22:41:55.359322500 <4> [] > > unix_stream_recvmsg+0x2c1/0x414 > > 2007-01-04 22:41:55.359323500 <4> [] do_sock_read+0xc4/0xcc > > 2007-01-04 22:41:55.359334500 <4> [] sock_aio_read+0x6a/0x7b > > 2007-01-04 22:41:55.359335500 <4> [] do_sync_read+0xca/0x119 > > 2007-01-04 22:41:55.359337500 <4> [] vfs_read+0xb4/0x18a > > 2007-01-04 22:41:55.359338500 <4> [] sys_read+0x3d/0x64 > > 2007-01-04 22:41:55.359349500 <4> [] syscall_call+0x7/0xb > > 2007-01-04 22:41:55.359350500 <4> [<00ecc410>] 0xecc410 > > Curious. It look like running restorecon left tty_mutex held. I just did > a full tty_mutex audit on 2.6.20-rc3 and all looks to be OK. > > Is it repeatable? Once in a lifetime. But... system didn't blow up when I ran "restorecon -R /wrk" again after reboot. -- - 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/
execve hanging in selinux_bprm_post_apply_creds
Kernel 2.6.19.1 SMP on Pentium D. I ran command restorecon -R /wrk. After a while or two programs stopped responding and I had to reboot. I'm not sure is this bug or feature... I upgraded selinux policy before running restorecon. 2007-01-04 22:41:55.360538500 <4>softlimit D 61707865 0 18679 18678 (NOTLB) 2007-01-04 22:41:55.360549500 <4> ec5efdd0 0046 f8964fda 61707865 006a 0072 0043 005b 2007-01-04 22:41:55.360551500 <4> f7264580 00a9 00fb 000e 00cc 0055 c1805700 f4f2e13c 2007-01-04 22:41:55.360553500 <4> 0001be4d 1f64183b 073d f4f2e030 c05785ac 0246 f4f2e030 ec5efe18 2007-01-04 22:41:55.360554500 <4>Call Trace: 2007-01-04 22:41:55.360571500 <4> [] __mutex_lock_slowpath+0x85/0x1df 2007-01-04 22:41:55.360572500 <4> [] mutex_lock+0x21/0x24 2007-01-04 22:41:55.360573500 <4> [] selinux_bprm_post_apply_creds+0x65/0x40a 2007-01-04 22:41:55.360575500 <4> [] compute_creds+0x4f/0x52 2007-01-04 22:41:55.360576500 <4> [] load_elf_binary+0x944/0xd0e 2007-01-04 22:41:55.360589500 <4> [] search_binary_handler+0x9a/0x24c 2007-01-04 22:41:55.360590500 <4> [] do_execve+0x163/0x1f1 2007-01-04 22:41:55.360592500 <4> [] sys_execve+0x32/0x84 2007-01-04 22:41:55.360593500 <4> [] syscall_call+0x7/0xb 2007-01-04 22:41:55.360594500 <4> [<00ecc410>] 0xecc410 2007-01-04 22:41:55.360620500 <4> === ... 2007-01-04 22:41:55.359020500 <4>crond D DDC59E64 0 18627 1837 18668 (NOTLB) 2007-01-04 22:41:55.359022500 <4> ddc59e78 0046 c01454c5 ddc59e64 ddc59e58 c04f4d56 ddc59e74 00d0 2007-01-04 22:41:55.359033500 <4> f7a50ac0 f78d8a5e 06e3 11f7 c1967030 c17fd700 d10a6b7c 2007-01-04 22:41:55.359034500 <4> 000166f0 f78db4eb 06e3 d10a6a70 c05785ac 0246 d10a6a70 ddc59ec0 2007-01-04 22:41:55.359036500 <4>Call Trace: 2007-01-04 22:41:55.359037500 <4> [] __mutex_lock_slowpath+0x85/0x1df 2007-01-04 22:41:55.359047500 <4> [] mutex_lock+0x21/0x24 2007-01-04 22:41:55.359049500 <4> [] audit_log_exit+0x120/0x799 2007-01-04 22:41:55.359050500 <4> [] audit_syscall_exit+0x75/0x325 2007-01-04 22:41:55.359051500 <4> [] do_syscall_trace+0x1a5/0x1eb -- 2007-01-04 22:41:55.359305500 <4> 2d6d 33456ed0 06e5 e7163a70 7fff 7fff ed0aa9e0 e4c03d5c 2007-01-04 22:41:55.359306500 <4>Call Trace: 2007-01-04 22:41:55.359319500 <4> [] schedule_timeout+0x94/0x96 2007-01-04 22:41:55.359321500 <4> [] unix_stream_data_wait+0xa0/0xe7 2007-01-04 22:41:55.359322500 <4> [] unix_stream_recvmsg+0x2c1/0x414 2007-01-04 22:41:55.359323500 <4> [] do_sock_read+0xc4/0xcc 2007-01-04 22:41:55.359334500 <4> [] sock_aio_read+0x6a/0x7b 2007-01-04 22:41:55.359335500 <4> [] do_sync_read+0xca/0x119 2007-01-04 22:41:55.359337500 <4> [] vfs_read+0xb4/0x18a 2007-01-04 22:41:55.359338500 <4> [] sys_read+0x3d/0x64 2007-01-04 22:41:55.359349500 <4> [] syscall_call+0x7/0xb 2007-01-04 22:41:55.359350500 <4> [<00ecc410>] 0xecc410 -- - 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/
execve hanging in selinux_bprm_post_apply_creds
Kernel 2.6.19.1 SMP on Pentium D. I ran command restorecon -R /wrk. After a while or two programs stopped responding and I had to reboot. I'm not sure is this bug or feature... I upgraded selinux policy before running restorecon. 2007-01-04 22:41:55.360538500 4softlimit D 61707865 0 18679 18678 (NOTLB) 2007-01-04 22:41:55.360549500 4 ec5efdd0 0046 f8964fda 61707865 006a 0072 0043 005b 2007-01-04 22:41:55.360551500 4 f7264580 00a9 00fb 000e 00cc 0055 c1805700 f4f2e13c 2007-01-04 22:41:55.360553500 4 0001be4d 1f64183b 073d f4f2e030 c05785ac 0246 f4f2e030 ec5efe18 2007-01-04 22:41:55.360554500 4Call Trace: 2007-01-04 22:41:55.360571500 4 [c04b490e] __mutex_lock_slowpath+0x85/0x1df 2007-01-04 22:41:55.360572500 4 [c04b487c] mutex_lock+0x21/0x24 2007-01-04 22:41:55.360573500 4 [c0279dde] selinux_bprm_post_apply_creds+0x65/0x40a 2007-01-04 22:41:55.360575500 4 [c01720cb] compute_creds+0x4f/0x52 2007-01-04 22:41:55.360576500 4 [c019a788] load_elf_binary+0x944/0xd0e 2007-01-04 22:41:55.360589500 4 [c01721f3] search_binary_handler+0x9a/0x24c 2007-01-04 22:41:55.360590500 4 [c0172508] do_execve+0x163/0x1f1 2007-01-04 22:41:55.360592500 4 [c01019fd] sys_execve+0x32/0x84 2007-01-04 22:41:55.360593500 4 [c0102e73] syscall_call+0x7/0xb 2007-01-04 22:41:55.360594500 4 [00ecc410] 0xecc410 2007-01-04 22:41:55.360620500 4 === ... 2007-01-04 22:41:55.359020500 4crond D DDC59E64 0 18627 1837 18668 (NOTLB) 2007-01-04 22:41:55.359022500 4 ddc59e78 0046 c01454c5 ddc59e64 ddc59e58 c04f4d56 ddc59e74 00d0 2007-01-04 22:41:55.359033500 4 f7a50ac0 f78d8a5e 06e3 11f7 c1967030 c17fd700 d10a6b7c 2007-01-04 22:41:55.359034500 4 000166f0 f78db4eb 06e3 d10a6a70 c05785ac 0246 d10a6a70 ddc59ec0 2007-01-04 22:41:55.359036500 4Call Trace: 2007-01-04 22:41:55.359037500 4 [c04b490e] __mutex_lock_slowpath+0x85/0x1df 2007-01-04 22:41:55.359047500 4 [c04b487c] mutex_lock+0x21/0x24 2007-01-04 22:41:55.359049500 4 [c01491b7] audit_log_exit+0x120/0x799 2007-01-04 22:41:55.359050500 4 [c0149c1b] audit_syscall_exit+0x75/0x325 2007-01-04 22:41:55.359051500 4 [c010677a] do_syscall_trace+0x1a5/0x1eb -- 2007-01-04 22:41:55.359305500 4 2d6d 33456ed0 06e5 e7163a70 7fff 7fff ed0aa9e0 e4c03d5c 2007-01-04 22:41:55.359306500 4Call Trace: 2007-01-04 22:41:55.359319500 4 [c04b464c] schedule_timeout+0x94/0x96 2007-01-04 22:41:55.359321500 4 [c048802c] unix_stream_data_wait+0xa0/0xe7 2007-01-04 22:41:55.359322500 4 [c0488334] unix_stream_recvmsg+0x2c1/0x414 2007-01-04 22:41:55.359323500 4 [c0418be3] do_sock_read+0xc4/0xcc 2007-01-04 22:41:55.359334500 4 [c0418c55] sock_aio_read+0x6a/0x7b 2007-01-04 22:41:55.359335500 4 [c016d3c9] do_sync_read+0xca/0x119 2007-01-04 22:41:55.359337500 4 [c016d4cc] vfs_read+0xb4/0x18a 2007-01-04 22:41:55.359338500 4 [c016d884] sys_read+0x3d/0x64 2007-01-04 22:41:55.359349500 4 [c0102e73] syscall_call+0x7/0xb 2007-01-04 22:41:55.359350500 4 [00ecc410] 0xecc410 -- - 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: execve hanging in selinux_bprm_post_apply_creds
On Thu, Jan 04, 2007 at 16:03:34 -0800, Andrew Morton wrote: On Fri, 5 Jan 2007 00:26:42 +0200 Sami Farin [EMAIL PROTECTED] wrote: Kernel 2.6.19.1 SMP on Pentium D. I ran command restorecon -R /wrk. After a while or two programs stopped responding and I had to reboot. I'm not sure is this bug or feature... bug ;) =) 2007-01-04 22:41:55.360538500 4softlimit D 61707865 0 18679 18678 (NOTLB) 2007-01-04 22:41:55.360549500 4 ec5efdd0 0046 f8964fda 61707865 006a 0072 0043 005b 2007-01-04 22:41:55.360551500 4 f7264580 00a9 00fb 000e 00cc 0055 c1805700 f4f2e13c 2007-01-04 22:41:55.360553500 4 0001be4d 1f64183b 073d f4f2e030 c05785ac 0246 f4f2e030 ec5efe18 2007-01-04 22:41:55.360554500 4Call Trace: 2007-01-04 22:41:55.360571500 4 [c04b490e] __mutex_lock_slowpath+0x85/0x1df 2007-01-04 22:41:55.360572500 4 [c04b487c] mutex_lock+0x21/0x24 2007-01-04 22:41:55.360573500 4 [c0279dde] selinux_bprm_post_apply_creds+0x65/0x40a 2007-01-04 22:41:55.360575500 4 [c01720cb] compute_creds+0x4f/0x52 2007-01-04 22:41:55.360576500 4 [c019a788] load_elf_binary+0x944/0xd0e 2007-01-04 22:41:55.360589500 4 [c01721f3] search_binary_handler+0x9a/0x24c 2007-01-04 22:41:55.360590500 4 [c0172508] do_execve+0x163/0x1f1 2007-01-04 22:41:55.360592500 4 [c01019fd] sys_execve+0x32/0x84 2007-01-04 22:41:55.360593500 4 [c0102e73] syscall_call+0x7/0xb 2007-01-04 22:41:55.360594500 4 [00ecc410] 0xecc410 2007-01-04 22:41:55.360620500 4 === ... 2007-01-04 22:41:55.359020500 4crond D DDC59E64 0 18627 1837 18668 (NOTLB) 2007-01-04 22:41:55.359022500 4 ddc59e78 0046 c01454c5 ddc59e64 ddc59e58 c04f4d56 ddc59e74 00d0 2007-01-04 22:41:55.359033500 4 f7a50ac0 f78d8a5e 06e3 11f7 c1967030 c17fd700 d10a6b7c 2007-01-04 22:41:55.359034500 4 000166f0 f78db4eb 06e3 d10a6a70 c05785ac 0246 d10a6a70 ddc59ec0 2007-01-04 22:41:55.359036500 4Call Trace: 2007-01-04 22:41:55.359037500 4 [c04b490e] __mutex_lock_slowpath+0x85/0x1df 2007-01-04 22:41:55.359047500 4 [c04b487c] mutex_lock+0x21/0x24 2007-01-04 22:41:55.359049500 4 [c01491b7] audit_log_exit+0x120/0x799 2007-01-04 22:41:55.359050500 4 [c0149c1b] audit_syscall_exit+0x75/0x325 2007-01-04 22:41:55.359051500 4 [c010677a] do_syscall_trace+0x1a5/0x1eb -- 2007-01-04 22:41:55.359305500 4 2d6d 33456ed0 06e5 e7163a70 7fff 7fff ed0aa9e0 e4c03d5c 2007-01-04 22:41:55.359306500 4Call Trace: 2007-01-04 22:41:55.359319500 4 [c04b464c] schedule_timeout+0x94/0x96 2007-01-04 22:41:55.359321500 4 [c048802c] unix_stream_data_wait+0xa0/0xe7 2007-01-04 22:41:55.359322500 4 [c0488334] unix_stream_recvmsg+0x2c1/0x414 2007-01-04 22:41:55.359323500 4 [c0418be3] do_sock_read+0xc4/0xcc 2007-01-04 22:41:55.359334500 4 [c0418c55] sock_aio_read+0x6a/0x7b 2007-01-04 22:41:55.359335500 4 [c016d3c9] do_sync_read+0xca/0x119 2007-01-04 22:41:55.359337500 4 [c016d4cc] vfs_read+0xb4/0x18a 2007-01-04 22:41:55.359338500 4 [c016d884] sys_read+0x3d/0x64 2007-01-04 22:41:55.359349500 4 [c0102e73] syscall_call+0x7/0xb 2007-01-04 22:41:55.359350500 4 [00ecc410] 0xecc410 Curious. It look like running restorecon left tty_mutex held. I just did a full tty_mutex audit on 2.6.20-rc3 and all looks to be OK. Is it repeatable? Once in a lifetime. But... system didn't blow up when I ran restorecon -R /wrk again after reboot. -- - 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/
xfs_file_ioctl / xfs_freeze: BUG: warning at kernel/mutex-debug.c:80/debug_mutex_unlock()
just a simple test I did... xfs_freeze -f /mnt/newtest cp /etc/fstab /mnt/newtest xfs_freeze -u /mnt/newtest 2007-01-04 01:44:30.341979500 <4>BUG: warning at kernel/mutex-debug.c:80/debug_mutex_unlock() 2007-01-04 01:44:30.385771500 <4> [] dump_trace+0x215/0x21a 2007-01-04 01:44:30.385774500 <4> [] show_trace_log_lvl+0x1a/0x30 2007-01-04 01:44:30.385775500 <4> [] show_trace+0x12/0x14 2007-01-04 01:44:30.385777500 <4> [] dump_stack+0x19/0x1b 2007-01-04 01:44:30.385778500 <4> [] debug_mutex_unlock+0x69/0x120 2007-01-04 01:44:30.385779500 <4> [] __mutex_unlock_slowpath+0x44/0xf0 2007-01-04 01:44:30.385780500 <4> [] mutex_unlock+0x8/0xa 2007-01-04 01:44:30.385782500 <4> [] thaw_bdev+0x57/0x6e 2007-01-04 01:44:30.385791500 <4> [] xfs_ioctl+0x7ce/0x7d3 2007-01-04 01:44:30.385793500 <4> [] xfs_file_ioctl+0x33/0x54 2007-01-04 01:44:30.385794500 <4> [] do_ioctl+0x76/0x85 2007-01-04 01:44:30.385795500 <4> [] vfs_ioctl+0x59/0x1aa 2007-01-04 01:44:30.385796500 <4> [] sys_ioctl+0x67/0x77 2007-01-04 01:44:30.385797500 <4> [] syscall_call+0x7/0xb 2007-01-04 01:44:30.385799500 <4> [<001be410>] 0x1be410 2007-01-04 01:44:30.385800500 <4> === fstab was there just fine after -u. Linux 2.6.19.1 SMP on Pentium D. -- - 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/
