fedora 14 kernel performance with ip forwarding workload
by Jesse Brandeburg
The other day I was running the stock fedora kernel on my ip
forwarding setup, to see what the performance was, and the performance
wasn't very good.
system is S5520HC dual socket 2.93GHz Xeon 5570 (Nehalem) with 3 quad
port 82580 adapters (12 ports). Traffic is bidirectional 64 byte
packets being forwarded and received on each port, basically port to
port routing. I am only using 12 flows currently.
The driver is igb, and I am using an affinity script that lines up
each pair of ports that are forwarding traffic into optimal
configurations for cache locality. I am also disabling
remote_node_defrag_ratio to stop cross node traffic.
With the fedora default kernel from F14 it appears that
CONFIG_NETFILTER=y means that I cannot unload all of netfilter even if
I stop iptables service.
perf showed netfilter being prominent, and removing it gives me much
higher throughput. Is there a reason CONFIG_NETFILTER=y ? Isn't it a
good thing to be able to disable netfilter if you want to?
Jesse
8 years, 10 months
nvidia card and kernel 3.1
by Dmitriy Tochansky
Hello!
I bough new videocard yesterday and have some problems with it.
After inserting it to my PC, I found in dmesg:
[ 9.877721] PERCPU: allocation failed, size=240 align=4, failed to
allocate new chunk
[ 9.877729] Pid: 755, comm: modprobe Not tainted 3.1.0-7.fc16.i686 #1
[ 9.877732] Call Trace:
[ 9.877743] [<c0808e3e>] ? printk+0x2d/0x2f
[ 9.877752] [<c04c6904>] pcpu_alloc+0x659/0x6c1
[ 9.877759] [<c0468e19>] ? sys_init_module+0x5b/0x15c7
[ 9.877767] [<c04d3233>] ? __vmalloc_node+0x54/0x5b
[ 9.877773] [<c0429d7c>] ? should_resched+0xd/0x27
[ 9.877788] [<c04c6b69>] __alloc_reserved_percpu+0x12/0x14
[ 9.877794] [<c0469169>] sys_init_module+0x3ab/0x15c7
[ 9.877801] [<c0813ad9>] ? do_page_fault+0x2a9/0x304
[ 9.877807] [<c04ff24c>] ? mntput_no_expire+0x27/0xb9
[ 9.877816] [<c0810b0c>] syscall_call+0x7/0xb
[ 9.877823] [<c044007b>] ? sys_waitid+0x4a/0x141
[ 9.877827] nf_conntrack: Could not allocate 240 bytes percpu data
[ 9.878335] modprobe[755]: FATAL: Error inserting xt_state
(/lib/modules/3.1.0-7.fc16.i686/kernel/net/netfilter/xt_state.ko): Cannot
allocate memory
[ 9.878664] iptables.init[738]: iptables: Applying firewall rules:
iptables-restore: line 12 failed
[ 9.883352] iptables.init[738]: [FAILED]
[ 9.909336] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 9.917425] PERCPU: allocation failed, size=240 align=4, failed to
allocate new chunk
[ 9.917433] Pid: 777, comm: modprobe Not tainted 3.1.0-7.fc16.i686 #1
[ 9.917437] Call Trace:
[ 9.917448] [<c0808e3e>] ? printk+0x2d/0x2f
[ 9.917456] [<c04c6904>] pcpu_alloc+0x659/0x6c1
[ 9.917463] [<c0468e19>] ? sys_init_module+0x5b/0x15c7
[ 9.917471] [<c04d3233>] ? __vmalloc_node+0x54/0x5b
[ 9.917477] [<c0429d7c>] ? should_resched+0xd/0x27
[ 9.917492] [<c04c6b69>] __alloc_reserved_percpu+0x12/0x14
[ 9.917497] [<c0469169>] sys_init_module+0x3ab/0x15c7
[ 9.917504] [<c0813ad9>] ? do_page_fault+0x2a9/0x304
[ 9.917511] [<c04ff24c>] ? mntput_no_expire+0x27/0xb9
[ 9.917520] [<c0810b0c>] syscall_call+0x7/0xb
[ 9.917527] [<c044007b>] ? sys_waitid+0x4a/0x141
[ 9.917531] nf_conntrack: Could not allocate 240 bytes percpu data
[ 9.917802] modprobe[777]: FATAL: Error inserting xt_state
(/lib/modules/3.1.0-7.fc16.i686/kernel/net/netfilter/xt_state.ko): Cannot
allocate memory
Much other problems like:
[root@home toch]# modprobe fuse
FATAL: Error inserting fuse
(/lib/modules/3.1.0-7.fc16.i686/kernel/fs/fuse/fuse.ko): Cannot allocate
memory
Boot with kernel 3.3 is failed with blackscreen.
--
Dmitriy
12 years
Kernel: low stack detected by irq handler
by radiatejava
Hello experts,
I have recently moved from kernel 2.6.18-128 to 2.6.18-194. I have my
own kernel module also called click. This click is for trapping and
processing all the network packets. All was fine till we were on
kernel 2.6.18-128 but after we moved to 2.6.18-194 kernel, we are
seeing the issue below (Low stack detected by IRQ handler) and the OS
is rebooting.
1. This is coming once in 2-3 hrs during normal operation and it is
not tolerable. This stack trace is printed in /var/log/messages and on
the console. I am not a kernel expert.I am just looking for any
pointer where someone experienced can tell me what is the reason of
this or such error ?
2. Additionally, after upgrading to kernel 2.6.18-194 we had put in
some code for logging as well. Logging functions in C were 'inline'
functions. As part of debugging this issue, when we removed the
'inline' keyword from the logging methods, we did not observe this
issue and our issue was resolved. Can anyone tell me why 'inline'
functions in the kernel module would cause such issues ?
I asked this to vger.kernel.org kernel list and they have directed me
ask here as the kernel is redhat kernel.
Appreciate your response. Thanks in adv.
Oct 31 10:47:53 KC-CAS-N1 kernel: low stack detected by irq handler
Oct 31 10:47:53 KC-CAS-N1 kernel: [<c0405e9b>] do_IRQ+0x86/0xc3
Oct 31 10:47:53 KC-CAS-N1 kernel: [<c04046e6>] common_interrupt+0x1a/0x20
Oct 31 10:47:53 KC-CAS-N1 kernel: [<c05b6b1e>] rt_garbage_collect+0x0/0x213
Oct 31 10:47:53 KC-CAS-N1 kernel: [<c05a44d7>] dst_alloc+0x1d/0x7e
Oct 31 10:47:53 KC-CAS-N1 kernel: [<c05b8195>]
__ip_route_output_key+0x543/0x79e
Oct 31 10:47:53 KC-CAS-N1 kernel: [<c05b8403>] ip_route_output_flow+0x13/0x1d4
Oct 31 10:47:53 KC-CAS-N1 kernel: [<c05b85cd>] ip_route_output_key+0x9/0xb
Oct 31 10:47:53 KC-CAS-N1 kernel: [<c05bdd5d>] ip_send_reply+0xf8/0x209
Oct 31 10:47:53 KC-CAS-N1 kernel: [<c05eaf79>] __xfrm_policy_check+0x35c/0x671
Oct 31 10:47:53 KC-CAS-N1 kernel: [<c05ea74e>] xfrm_policy_lookup+0x0/0x313
Oct 31 10:47:53 KC-CAS-N1 kernel: [<c05b7c2f>] rt_intern_hash+0x45d/0x480
Oct 31 10:47:53 KC-CAS-N1 kernel: [<c05cfc56>] tcp_v4_send_reset+0x104/0x11c
Oct 31 10:47:53 KC-CAS-N1 kernel: [<c05d0879>] tcp_v4_do_rcv+0x240/0x269
Oct 31 10:47:53 KC-CAS-N1 kernel: [<c05d28cb>] tcp_v4_rcv+0x7f7/0x848
Oct 31 10:47:53 KC-CAS-N1 kernel: [<c05bb173>] ip_local_deliver+0x157/0x1d0
Oct 31 10:47:54 KC-CAS-N1 kernel: [<c05baff2>] ip_rcv+0x3cb/0x3f5
Oct 31 10:47:54 KC-CAS-N1 kernel: [<c05a141d>] __netif_receive_skb+0x3b3/0x3d5
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb32e21e>]
_ZN6ToHost4pushEiP6Packet+0xee/0x210 [click]
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb34b85d>]
_ZN12EnsureEther24pushEiP6Packet+0x1d/0x20 [click]
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb33d895>]
_ZN11ARPQuerier44pushEiP6Packet+0x4c5/0x2370 [click]
Oct 31 10:47:54 KC-CAS-N1 kernel: [<c05bb173>] ip_local_deliver+0x157/0x1d0
Oct 31 10:47:54 KC-CAS-N1 kernel: [<c05baff2>] ip_rcv+0x3cb/0x3f5
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb31b42d>]
_ZN4IPRw7Mapping9make_pairEiRK8IPFlowIDS3_iiPS0_S4_+0xad/0xd0 [click]
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb31ccfb>]
_ZN4IPRw7Pattern14create_mappingEiRK8IPFlowIDiiPNS_7MappingES5_RK7HashMapIS1_S5_E+0x1cb/0x1f0
[click]
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb395ce3>]
_ZN10IPRewriter13apply_patternEPN4IPRw7PatternEiRK8IPFlowIDii+0x153/0x160
[click]
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb395d9e>]
_ZN10IPRewriter4pushEiP6Packet+0xae/0x260 [click]
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb367535>]
_ZN11MacThrottle10l2PushProcEiP6Packet+0x55/0x3b0 [click]
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb33d895>]
_ZN11ARPQuerier44pushEiP6Packet+0x4c5/0x2370 [click]
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb395ce3>]
_ZN10IPRewriter13apply_patternEPN4IPRw7PatternEiRK8IPFlowIDii+0x153/0x160
[click]
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb395d9e>]
_ZN10IPRewriter4pushEiP6Packet+0xae/0x260 [click]
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb367b96>]
_ZN11MacThrottle4pushEiP6Packet+0x306/0x1890 [click]
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb3439d8>]
_ZN8BWShaper4pushEiP6Packet+0x58/0xe90 [click]
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb2d2806>]
_ZN7Element4pushEiP6Packet+0x26/0x40 [click]
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb384674>]
_ZN11PaintSwitch4pushEiP6Packet+0x44/0xe0 [click]
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb36b075>]
_ZN17NtlmLoginDetector4pushEiP6Packet+0x65/0x15d0 [click]
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb2d2806>]
_ZN7Element4pushEiP6Packet+0x26/0x40 [click]
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb384674>]
_ZN11PaintSwitch4pushEiP6Packet+0x44/0xe0 [click]
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb39c881>]
_ZN15RecycledSkbPool7recycleEP7sk_buff+0x31/0xf0 [click]
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb378fdb>]
_ZN14PerfigoDiscard4pushEiP6Packet+0x4b/0x1c0 [click]
Oct 31 10:47:54 KC-CAS-N1 kernel: [<c05bb173>] ip_local_deliver+0x157/0x1d0
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb355e86>]
_ZN11HashIPTable4pushEiP6Packet+0xf6/0x2d0 [click]
Oct 31 10:47:54 KC-CAS-N1 kernel: [<c05a141d>] __netif_receive_skb+0x3b3/0x3d5
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb3439d8>]
_ZN8BWShaper4pushEiP6Packet+0x58/0xe90 [click]
Oct 31 10:47:54 KC-CAS-N1 kernel: [<c04046e6>] common_interrupt+0x1a/0x20
Oct 31 10:47:54 KC-CAS-N1 kernel: [<fb30f904>]
_ZN8IPFilter4pushEiP6Packet+0x64/0xf0 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb361517>]
_ZN12IPPortLookup4pushEiP6Packet+0x47/0x9e0 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<c0405ecc>] do_IRQ+0xb7/0xc3
Oct 31 10:47:55 KC-CAS-N1 kernel: [<c04046e6>] common_interrupt+0x1a/0x20
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb34a5fc>]
_ZN10DnsHandler17is_packet_allowedEPK6Packeti+0x8c/0x5e0 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb3439d8>]
_ZN8BWShaper4pushEiP6Packet+0x58/0xe90 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb3455d7>]
_ZN10DnsHandler12get_dns_nameEPKcS1_S1_R16perfigo_dns_nameR6String+0x177/0x200
[click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb384674>]
_ZN11PaintSwitch4pushEiP6Packet+0x44/0xe0 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb3456a3>]
_ZN10DnsHandler10get_dns_rrEPKcS1_RS1_R14perfigo_dns_rrR6String+0x43/0xb0
[click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb34abb8>]
_ZN10DnsHandler4pushEiP6Packet+0x68/0xb00 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb2cea6f>]
_ZN6Packet19expensive_uniqueifyEiib+0x18f/0x1c0 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb32edba>]
_ZN11ARPQuerier29handle_ipEP6Packet+0x2aa/0x5f0 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<c04046e6>] common_interrupt+0x1a/0x20
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb3301bd>]
_ZN11ARPQuerier24pushEiP6Packet+0xcd/0x110 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb2d2806>]
_ZN7Element4pushEiP6Packet+0x26/0x40 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb384674>]
_ZN11PaintSwitch4pushEiP6Packet+0x44/0xe0 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb34abb8>]
_ZN10DnsHandler4pushEiP6Packet+0x68/0xb00 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb3439d8>]
_ZN8BWShaper4pushEiP6Packet+0x58/0xe90 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb32edba>]
_ZN11ARPQuerier29handle_ipEP6Packet+0x2aa/0x5f0 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb35f34f>]
_ZN13IPFilterGroup4pushEiP6Packet+0x19f/0xa80 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb3301bd>]
_ZN11ARPQuerier24pushEiP6Packet+0xcd/0x110 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb2d2806>]
_ZN7Element4pushEiP6Packet+0x26/0x40 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb384674>]
_ZN11PaintSwitch4pushEiP6Packet+0x44/0xe0 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb3439d8>]
_ZN8BWShaper4pushEiP6Packet+0x58/0xe90 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb350492>]
_ZN13HashIPLookup34pushEiP6Packet+0x112/0x1c0 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb3636cf>]
_ZN15LinearIPFilter24pushEiP6Packet+0x4f/0x3f0 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb31e1d1>]
_ZN14LinearIPLookup4pushEiP6Packet+0x71/0x100 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<f8c5b0fc>]
crypto_cbc_decrypt_inplace+0xb2/0xd1 [cbc]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb35a344>]
_ZN14HashMACLookup54pushEiP6Packet+0x304/0x890 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb3515b7>]
_ZN13HashIPLookup54pushEiP6Packet+0xc7/0x110 [click]
Oct 31 10:47:55 KC-CAS-N1 kernel: [<fb3636cf>]
_ZN15LinearIPFilter24pushEiP6Packet+0x4f/0x3f0 [click]
Oct 31 10:47:56 KC-CAS-N1 kernel: [<fb31e1d1>]
_ZN14LinearIPLookup4pushEiP6Packet+0x71/0x100 [click]
Oct 31 10:47:56 KC-CAS-N1 kernel: [<fb36b075>]
_ZN17NtlmLoginDetector4pushEiP6Packet+0x65/0x15d0 [click]
Oct 31 10:47:56 KC-CAS-N1 kernel: [<fb359bc1>]
_ZN14HashMACLookup514push_extern_ipEP6Packet+0x51/0x4d0 [click]
Oct 31 10:47:56 KC-CAS-N1 kernel: [<fb35462e>]
_ZN12HashIPTable24pushEiP6Packet+0x18e/0x580 [click]
Oct 31 10:47:56 KC-CAS-N1 kernel: [<c0418baf>] __wake_up+0x11/0x1a
Oct 31 10:47:56 KC-CAS-N1 kernel: [<c059b077>] sock_def_readable+0x26/0x4b
Oct 31 10:47:56 KC-CAS-N1 kernel: [<c059b454>] sock_queue_rcv_skb+0x102/0x10e
Oct 31 10:47:56 KC-CAS-N1 kernel: [<c05d4cbb>] __udp_queue_rcv_skb+0x8/0x31
Oct 31 10:47:56 KC-CAS-N1 kernel: [<c05d639d>] udp_rcv+0x35a/0x44a
Oct 31 10:47:56 KC-CAS-N1 kernel: [<fb39c881>]
_ZN15RecycledSkbPool7recycleEP7sk_buff+0x31/0xf0 [click]
Oct 31 10:47:56 KC-CAS-N1 kernel: [<fb35a57a>]
_ZN14HashMACLookup54pushEiP6Packet+0x53a/0x890 [click]
Oct 31 10:47:56 KC-CAS-N1 kernel: [<fb378fdb>]
_ZN14PerfigoDiscard4pushEiP6Packet+0x4b/0x1c0 [click]
Oct 31 10:47:56 KC-CAS-N1 kernel: [<fb30f904>]
_ZN8IPFilter4pushEiP6Packet+0x64/0xf0 [click]
Oct 31 10:47:56 KC-CAS-N1 kernel: [<fb33d895>]
_ZN11ARPQuerier44pushEiP6Packet+0x4c5/0x2370 [click]
Oct 31 10:47:56 KC-CAS-N1 kernel: [<fb32e21e>]
_ZN6ToHost4pushEiP6Packet+0xee/0x210 [click]
Oct 31 10:47:56 KC-CAS-N1 kernel: [<fb37879e>]
_ZN6Passer4pushEiP6Packet+0x12e/0x860 [click]
Oct 31 10:47:56 KC-CAS-N1 kernel: [<fb35462e>]
_ZN12HashIPTable24pushEiP6Packet+0x18e/0x580 [click]
Oct 31 10:47:56 KC-CAS-N1 kernel: [<fb384674>]
_ZN11PaintSwitch4pushEiP6Packet+0x44/0xe0 [click]
Oct 31 10:47:56 KC-CAS-N1 kernel: [<c043f334>] __do_IRQ+0x0/0x9f
Oct 31 10:47:56 KC-CAS-N1 kernel: [<c0405ecc>] do_IRQ+0xb7/0xc3
Oct 31 10:47:56 KC-CAS-N1 kernel: [<c0411f41>]
smp_apic_timer_interrupt+0x32/0x45
Oct 31 10:47:56 KC-CAS-N1 kernel: [<c0411f41>]
smp_apic_timer_interrupt+0x32/0x45
Oct 31 10:47:56 KC-CAS-N1 kernel: [<fb37b516>]
_ZN10Classifier4pushEiP6Packet+0x76/0xe0 [click]
Oct 31 10:47:56 KC-CAS-N1 kernel: [<fb2d2806>]
_ZN7Element4pushEiP6Packet+0x26/0x40 [click]
Oct 31 10:47:56 KC-CAS-N1 kernel: [<fb3282a5>]
_ZN10FromDevice8run_taskEP4Task+0xa5/0x120 [click]
Oct 31 10:47:56 KC-CAS-N1 kernel: [<fb2e9127>]
_ZN12RouterThread6driverEv+0x177/0x290 [click]
Oct 31 10:47:56 KC-CAS-N1 kernel: [<fb399822>]
_Z11click_schedPv+0x82/0x130 [click]
Oct 31 10:47:56 KC-CAS-N1 kernel: [<fb3997a0>]
_Z11click_schedPv+0x0/0x130 [click]
Oct 31 10:47:56 KC-CAS-N1 kernel: [<c0404987>] kernel_thread_helper+0x7/0x10
Oct 31 10:47:57 KC-CAS-N1 kernel: =======================
Oct 31 10:47:57 KC-CAS-N1 kernel: low stack detected by irq handler
Oct 31 10:47:57 KC-CAS-N1 kernel: [<c0405e9b>] do_IRQ+0x86/0xc3
Oct 31 10:47:57 KC-CAS-N1 kernel: [<c04046e6>] common_interrupt+0x1a/0x20
Oct 31 10:47:57 KC-CAS-N1 kernel: [<c05b6b1e>] rt_garbage_collect+0x0/0x213
Oct 31 10:47:57 KC-CAS-N1 kernel: [<c05a44d7>] dst_alloc+0x1d/0x7e
Oct 31 10:47:57 KC-CAS-N1 kernel: [<c05b8195>]
__ip_route_output_key+0x543/0x79e
Oct 31 10:47:57 KC-CAS-N1 kernel: [<c05b8403>] ip_route_output_flow+0x13/0x1d4
Oct 31 10:47:57 KC-CAS-N1 kernel: [<c05b85cd>] ip_route_output_key+0x9/0xb
Oct 31 10:47:57 KC-CAS-N1 kernel: [<c05bdd5d>] ip_send_reply+0xf8/0x209
Oct 31 10:47:57 KC-CAS-N1 kernel: [<c05eaf79>] __xfrm_policy_check+0x35c/0x671
Oct 31 10:47:57 KC-CAS-N1 kernel: [<c05ea74e>] xfrm_policy_lookup+0x0/0x313
Oct 31 10:47:57 KC-CAS-N1 kernel: [<c05b7c2f>] rt_intern_hash+0x45d/0x480
Oct 31 10:47:57 KC-CAS-N1 kernel: [<c05cfc56>] tcp_v4_send_reset+0x104/0x11c
Oct 31 10:47:57 KC-CAS-N1 kernel: [<c05d0879>] tcp_v4_do_rcv+0x240/0x269
Oct 31 10:47:57 KC-CAS-N1 kernel: [<c05d28cb>] tcp_v4_rcv+0x7f7/0x848
Oct 31 10:47:57 KC-CAS-N1 kernel: [<c05bb173>] ip_local_deliver+0x157/0x1d0
Oct 31 10:47:57 KC-CAS-N1 kernel: [<c05baff2>] ip_rcv+0x3cb/0x3f5
Oct 31 10:47:57 KC-CAS-N1 kernel: [<c05a141d>] __netif_receive_skb+0x3b3/0x3d5
Oct 31 10:47:57 KC-CAS-N1 kernel: [<fb32e21e>]
_ZN6ToHost4pushEiP6Packet+0xee/0x210 [click]
Oct 31 10:47:57 KC-CAS-N1 kernel: [<fb34b85d>]
_ZN12EnsureEther24pushEiP6Packet+0x1d/0x20 [click]
Oct 31 10:47:57 KC-CAS-N1 kernel: [<fb33d895>]
_ZN11ARPQuerier44pushEiP6Packet+0x4c5/0x2370 [click]
Oct 31 10:47:57 KC-CAS-N1 kernel: [<c05bb173>] ip_local_deliver+0x157/0x1d0
Oct 31 10:47:57 KC-CAS-N1 kernel: [<c05baff2>] ip_rcv+0x3cb/0x3f5
Oct 31 10:47:57 KC-CAS-N1 kernel: [<fb31b42d>]
_ZN4IPRw7Mapping9make_pairEiRK8IPFlowIDS3_iiPS0_S4_+0xad/0xd0 [click]
Oct 31 10:47:57 KC-CAS-N1 kernel: [<fb31ccfb>]
_ZN4IPRw7Pattern14create_mappingEiRK8IPFlowIDiiPNS_7MappingES5_RK7HashMapIS1_S5_E+0x1cb/0x1f0
[click]
Oct 31 10:47:57 KC-CAS-N1 kernel: [<fb395ce3>]
_ZN10IPRewriter13apply_patternEPN4IPRw7PatternEiRK8IPFlowIDii+0x153/0x160
[click]
Oct 31 10:47:57 KC-CAS-N1 kernel: [<fb395d9e>]
_ZN10IPRewriter4pushEiP6Packet+0xae/0x260 [click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb367535>]
_ZN11MacThrottle10l2PushProcEiP6Packet+0x55/0x3b0 [click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb33d895>]
_ZN11ARPQuerier44pushEiP6Packet+0x4c5/0x2370 [click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb395ce3>]
_ZN10IPRewriter13apply_patternEPN4IPRw7PatternEiRK8IPFlowIDii+0x153/0x160
[click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb395d9e>]
_ZN10IPRewriter4pushEiP6Packet+0xae/0x260 [click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb367b96>]
_ZN11MacThrottle4pushEiP6Packet+0x306/0x1890 [click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb3439d8>]
_ZN8BWShaper4pushEiP6Packet+0x58/0xe90 [click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb2d2806>]
_ZN7Element4pushEiP6Packet+0x26/0x40 [click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb384674>]
_ZN11PaintSwitch4pushEiP6Packet+0x44/0xe0 [click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb36b075>]
_ZN17NtlmLoginDetector4pushEiP6Packet+0x65/0x15d0 [click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb2d2806>]
_ZN7Element4pushEiP6Packet+0x26/0x40 [click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb384674>]
_ZN11PaintSwitch4pushEiP6Packet+0x44/0xe0 [click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb39c881>]
_ZN15RecycledSkbPool7recycleEP7sk_buff+0x31/0xf0 [click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb378fdb>]
_ZN14PerfigoDiscard4pushEiP6Packet+0x4b/0x1c0 [click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<c05bb173>] ip_local_deliver+0x157/0x1d0
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb355e86>]
_ZN11HashIPTable4pushEiP6Packet+0xf6/0x2d0 [click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<c05a141d>] __netif_receive_skb+0x3b3/0x3d5
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb3439d8>]
_ZN8BWShaper4pushEiP6Packet+0x58/0xe90 [click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<c04046e6>] common_interrupt+0x1a/0x20
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb30f904>]
_ZN8IPFilter4pushEiP6Packet+0x64/0xf0 [click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb361517>]
_ZN12IPPortLookup4pushEiP6Packet+0x47/0x9e0 [click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<c0405ecc>] do_IRQ+0xb7/0xc3
Oct 31 10:47:58 KC-CAS-N1 kernel: [<c04046e6>] common_interrupt+0x1a/0x20
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb34a5fc>]
_ZN10DnsHandler17is_packet_allowedEPK6Packeti+0x8c/0x5e0 [click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb3439d8>]
_ZN8BWShaper4pushEiP6Packet+0x58/0xe90 [click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb3455d7>]
_ZN10DnsHandler12get_dns_nameEPKcS1_S1_R16perfigo_dns_nameR6String+0x177/0x200
[click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb384674>]
_ZN11PaintSwitch4pushEiP6Packet+0x44/0xe0 [click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb3456a3>]
_ZN10DnsHandler10get_dns_rrEPKcS1_RS1_R14perfigo_dns_rrR6String+0x43/0xb0
[click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb34abb8>]
_ZN10DnsHandler4pushEiP6Packet+0x68/0xb00 [click]
Oct 31 10:47:58 KC-CAS-N1 kernel: [<fb2cea6f>]
_ZN6Packet19expensive_uniqueifyEiib+0x18f/0x1c0 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb32edba>]
_ZN11ARPQuerier29handle_ipEP6Packet+0x2aa/0x5f0 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<c04046e6>] common_interrupt+0x1a/0x20
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb3301bd>]
_ZN11ARPQuerier24pushEiP6Packet+0xcd/0x110 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb2d2806>]
_ZN7Element4pushEiP6Packet+0x26/0x40 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb384674>]
_ZN11PaintSwitch4pushEiP6Packet+0x44/0xe0 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb34abb8>]
_ZN10DnsHandler4pushEiP6Packet+0x68/0xb00 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb3439d8>]
_ZN8BWShaper4pushEiP6Packet+0x58/0xe90 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb32edba>]
_ZN11ARPQuerier29handle_ipEP6Packet+0x2aa/0x5f0 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb35f34f>]
_ZN13IPFilterGroup4pushEiP6Packet+0x19f/0xa80 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb3301bd>]
_ZN11ARPQuerier24pushEiP6Packet+0xcd/0x110 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb2d2806>]
_ZN7Element4pushEiP6Packet+0x26/0x40 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb384674>]
_ZN11PaintSwitch4pushEiP6Packet+0x44/0xe0 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb3439d8>]
_ZN8BWShaper4pushEiP6Packet+0x58/0xe90 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb350492>]
_ZN13HashIPLookup34pushEiP6Packet+0x112/0x1c0 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb3636cf>]
_ZN15LinearIPFilter24pushEiP6Packet+0x4f/0x3f0 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb31e1d1>]
_ZN14LinearIPLookup4pushEiP6Packet+0x71/0x100 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<f8c5b0fc>]
crypto_cbc_decrypt_inplace+0xb2/0xd1 [cbc]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb35a344>]
_ZN14HashMACLookup54pushEiP6Packet+0x304/0x890 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb3515b7>]
_ZN13HashIPLookup54pushEiP6Packet+0xc7/0x110 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb3636cf>]
_ZN15LinearIPFilter24pushEiP6Packet+0x4f/0x3f0 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb31e1d1>]
_ZN14LinearIPLookup4pushEiP6Packet+0x71/0x100 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb36b075>]
_ZN17NtlmLoginDetector4pushEiP6Packet+0x65/0x15d0 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb359bc1>]
_ZN14HashMACLookup514push_extern_ipEP6Packet+0x51/0x4d0 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb35462e>]
_ZN12HashIPTable24pushEiP6Packet+0x18e/0x580 [click]
Oct 31 10:47:59 KC-CAS-N1 kernel: [<c0418baf>] __wake_up+0x11/0x1a
Oct 31 10:47:59 KC-CAS-N1 kernel: [<c059b077>] sock_def_readable+0x26/0x4b
Oct 31 10:47:59 KC-CAS-N1 kernel: [<c059b454>] sock_queue_rcv_skb+0x102/0x10e
Oct 31 10:47:59 KC-CAS-N1 kernel: [<c05d4cbb>] __udp_queue_rcv_skb+0x8/0x31
Oct 31 10:47:59 KC-CAS-N1 kernel: [<c05d639d>] udp_rcv+0x35a/0x44a
Oct 31 10:47:59 KC-CAS-N1 kernel: [<fb39c881>]
_ZN15RecycledSkbPool7recycleEP7sk_buff+0x31/0xf0 [click]
Oct 31 10:48:00 KC-CAS-N1 kernel: [<fb35a57a>]
_ZN14HashMACLookup54pushEiP6Packet+0x53a/0x890 [click]
Oct 31 10:48:00 KC-CAS-N1 kernel: [<fb378fdb>]
_ZN14PerfigoDiscard4pushEiP6Packet+0x4b/0x1c0 [click]
Oct 31 10:48:00 KC-CAS-N1 kernel: [<fb30f904>]
_ZN8IPFilter4pushEiP6Packet+0x64/0xf0 [click]
Oct 31 10:48:00 KC-CAS-N1 kernel: [<fb33d895>]
_ZN11ARPQuerier44pushEiP6Packet+0x4c5/0x2370 [click]
Oct 31 10:48:00 KC-CAS-N1 kernel: [<fb32e21e>]
_ZN6ToHost4pushEiP6Packet+0xee/0x210 [click]
Oct 31 10:48:00 KC-CAS-N1 kernel: [<fb37879e>]
_ZN6Passer4pushEiP6Packet+0x12e/0x860 [click]
Oct 31 10:48:00 KC-CAS-N1 kernel: [<fb35462e>]
_ZN12HashIPTable24pushEiP6Packet+0x18e/0x580 [click]
Oct 31 10:48:00 KC-CAS-N1 kernel: [<fb384674>]
_ZN11PaintSwitch4pushEiP6Packet+0x44/0xe0 [click]
Oct 31 10:48:00 KC-CAS-N1 kernel: [<c043f334>] __do_IRQ+0x0/0x9f
Oct 31 10:48:00 KC-CAS-N1 kernel: [<c0405ecc>] do_IRQ+0xb7/0xc3
Oct 31 10:48:00 KC-CAS-N1 kernel: [<c0411f41>]
smp_apic_timer_interrupt+0x32/0x45
Oct 31 10:48:00 KC-CAS-N1 kernel: [<c0411f41>]
smp_apic_timer_interrupt+0x32/0x45
Oct 31 10:48:00 KC-CAS-N1 kernel: [<fb37b516>]
_ZN10Classifier4pushEiP6Packet+0x76/0xe0 [click]
Oct 31 10:48:00 KC-CAS-N1 kernel: [<fb2d2806>]
_ZN7Element4pushEiP6Packet+0x26/0x40 [click]
Oct 31 10:48:00 KC-CAS-N1 kernel: [<fb3282a5>]
_ZN10FromDevice8run_taskEP4Task+0xa5/0x120 [click]
Oct 31 10:48:00 KC-CAS-N1 kernel: [<fb2e9127>]
_ZN12RouterThread6driverEv+0x177/0x290 [click]
Oct 31 10:48:00 KC-CAS-N1 kernel: [<fb399822>]
_Z11click_schedPv+0x82/0x130 [click]
Oct 31 10:48:00 KC-CAS-N1 kernel: [<fb3997a0>]
_Z11click_schedPv+0x0/0x130 [click]
Oct 31 10:48:00 KC-CAS-N1 kernel: [<c0404987>] kernel_thread_helper+0x7/0x10
12 years
$(uname -p) in kernel.spec
by DJ Delorie
This change breaks my arm build:
384fed00 (Dave Jones 2012-03-19 17:30:04 -0400 1485)
-for i in *.config
+for i in kernel-*-$(uname -p)*.config
"uname -p" returns armv7l but the configs we use are more varied than that:
$(CFG)-arm.config $(CFG)-armv5tel.config $(CFG)-armv7hl.config \
$(CFG)-armv5tel-kirkwood.config \
$(CFG)-armv7l-imx.config $(CFG)-armv7l-omap.config \
$(CFG)-armv7l-tegra.config $(CFG)-armv7l-highbank.config \
$(CFG)-armv7hl-imx.config $(CFG)-armv7hl-omap.config \
$(CFG)-armv7hl-tegra.config $(CFG)-armv7hl-highbank.config \
Typically, we use "rpmbuild --target=armv7hl" to specify the platform
to build for, do we need to change the way we're doing things? Is
--target no longer supported?
12 years
Fedora Kernel Meeting 03-30-2012 Minutes
by Josh Boyer
======================================
#fedora-meeting: Fedora Kernel meeting
======================================
Meeting started by jwb at 18:00:13 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2012-03-30/fedora_kernel_...
.
Meeting summary
---------------
* init (jwb, 18:01:08)
* F15 (jwb, 18:02:14)
* F15 currently at 2.6.42.13 (3.2.13). Waiting for 3.3.1 (jwb,
18:04:49)
* F16/F17 (jwb, 18:05:36)
* testers/karma needed for F15 as it stagnates in updates-testing
(jwb, 18:06:03)
* Weekly bug stats:
http://codemonkey.org.uk/2012/03/30/weekly-fedora-kernel-bug-statistics-m...
(jwb, 18:10:21)
* i915 and ASPM fixes queued up in f16/f17 (jwb, 18:13:36)
* F17 Beta kernel is 3.3.0-1.fc17 (jwb, 18:15:17)
* ACTION: davej/jwb to write patch to shut up timekeeping 11% skew
message (jwb, 18:18:03)
* Rawhide (jwb, 18:18:51)
* rawhide currently at 3.4-rc0 (post 3.3 git snapshots) (jwb,
18:20:30)
* AGREED: increase the size of the dmesg buffer for rawhide/debug
builds (jwb, 18:25:16)
* ACTION: set CONFIG_LOG_BUF_SHIFT=18 in config-generic. other arches
can override in arch specific configs (jwb, 18:29:32)
* kernel autotest (jwb, 18:30:24)
* kernel performance/regression testing one of the goals the Fedora
kernel team is working on this year (jwb, 18:32:38)
* HELP: If community members want to contribute regression tests,
please email the kernel list with suggestions/tests. (jwb,
18:36:22)
* Open Floor (jwb, 18:44:32)
Meeting ended at 18:49:36 UTC.
Action Items
------------
* davej/jwb to write patch to shut up timekeeping 11% skew message
* set CONFIG_LOG_BUF_SHIFT=18 in config-generic. other arches can
override in arch specific configs
Action Items, by person
-----------------------
* davej
* davej/jwb to write patch to shut up timekeeping 11% skew message
* jwb
* davej/jwb to write patch to shut up timekeeping 11% skew message
* **UNASSIGNED**
* set CONFIG_LOG_BUF_SHIFT=18 in config-generic. other arches can
override in arch specific configs
People Present (lines said)
---------------------------
* jwb (104)
* davej (39)
* jforbes (27)
* drago01 (7)
* zodbot (3)
* adamw (1)
* nirik (1)
* brunowolff (1)
* jsmith (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
12 years
Re: [kernel] Created branch private-jcm-arm-nosmp-kallsyms
by Dave Jones
On Sun, Mar 25, 2012 at 02:45:46AM +0000, Jon Masters wrote:
> The branch 'private-jcm-arm-nosmp-kallsyms' was created.
>
> Summary of new commits:
>
> 96c6928... kallsyms: Temporary fix for kallsyms on !CONFIG_SMP
Please don't do this. It makes a huge mess for clone -B checkouts.
For something that's been broken for weeks, there's really no reason
this had to be rushed on a weekend.
Dave
12 years, 1 month
[PATCH] rawhide: enable HYPERV drivers
by Kyle McMartin
Never noticed these had made it out of the staging doghouse in 3.2...
should we enable them like the other v12n stuff?
(Not on the list for some reason, I should probably fix that.)
--Kyle
--- a/config-x86-generic
+++ b/config-x86-generic
@@ -394,7 +394,11 @@ CONFIG_SCHED_SMT=y
CONFIG_CC_STACKPROTECTOR=y
CONFIG_RELOCATABLE=y
-# CONFIG_HYPERV is not set
+CONFIG_HYPERV=m
+CONFIG_HYPERV_UTILS=m
+CONFIG_HID_HYPERV_MOUSE=m
+CONFIG_HYPERV_NET=m
+CONFIG_HYPERV_STORAGE=m
# Depends on HOTPLUG_PCI_PCIE
CONFIG_BLK_DEV_PCIESSD_MTIP32XX=m
12 years, 1 month
Fwd: [fedora-arm] Fwd: Re: Inconsistent kallsyms data on ARM.
by Jon Masters
Just FYI we'll pull this in tomorrow so we can build kernels again. I
don't have commit access, so once there's a patch, I'll ping one of you
to help get that in for me. Also, can we decide what we're doing about
the FIPS-140 stuff on ARM? Are you ok with just removing the BuildReq
for the moment since we haven't satisfied that yet with a build? (a
conditional just for ARM, not for everyone)
Jon.
-------- Original Message --------
Subject: [fedora-arm] Fwd: Re: Inconsistent kallsyms data on ARM.
Date: Sun, 25 Mar 2012 20:02:42 -0400
From: Jon Masters <jonathan(a)jonmasters.org>
Organization: World Organi{s,z}ation of Broken Dreams
To: arm(a)lists.fedoraproject.org
Hi everyone,
My test kernel build succeeded, and it looks like Russell independently
found the same problem that I did. I've pinged him on IRC and sent this
followup, and a few of us have discussed it some. I suspect we'll just
pull in either of the two approaches rmk suggests as a trivial patch.
Either we add an extra byte, screw with alignment, whatever.
The upshot of this whole exercise is that next time you see a kallsyms
pass failure you can ping me and I know it in painful detail.
For planning, let's give rmk chance to post his preferred patch and then
probably tomorrow we can pull that into the Fedora ARM kernel. Now, as
to the HMAC stuff, let's figure out that in the morning. I think we just
turn it off on ARM for the moment.
Jon.
-------- Original Message --------
Subject: Re: Inconsistent kallsyms data on ARM.
Date: Sun, 25 Mar 2012 19:59:44 -0400
From: Jon Masters <jonathan(a)jonmasters.org>
Organization: World Organi{s,z}ation of Broken Dreams
To: Russell King - ARM Linux <linux(a)arm.linux.org.uk>
CC: Arnd Bergmann <arnd(a)arndb.de>, Paul Gortmaker
<paul.gortmaker(a)windriver.com>, linux-next(a)vger.kernel.org,
linux-arm-kernel(a)lists.infradead.org, linux-kbuild(a)vger.kernel.org
On 03/25/2012 07:20 AM, Russell King - ARM Linux wrote:
> On Wed, Mar 14, 2012 at 01:21:46PM +0000, Arnd Bergmann wrote:
>> On Tuesday 13 March 2012, Paul Gortmaker wrote:
>>> This bug(?) has been seen to float from one ARM build to another since
>>> I started tracking the day-to-day changes in Stephen's linux-next builds.
>>>
>>> I see it was discussed earlier:
>>>
>>> https://lkml.org/lkml/2011/8/2/233
>>> https://lkml.org/lkml/2011/10/8/70
>>>
>>> but no concrete cause was nailed down. Can the linux-next build results
>>> help shed some light on this in any way? Since it seems sporadic, is
>>> there value in embedding a diagnostic of some sort in the infrastructure
>>> so that when the error is detected, that it prints out more detailed info?
>>>
>>> I can provide links to failed linux-next builds, but at the moment, all they
>>> really seem to have is the same repeated error message, like this one:
>>>
>>> http://kisskb.ellerman.id.au/kisskb/buildresult/5869367/
>>>
>>> and I don't see that helping folks all that much....
>>>
>>
>> I'm sure I can reproduce it if necessary, but I need to know what to
>> look for to find out what the problem is.
>
> Right, last night's omap3430ldp build failed because of this, so I've
> re-run the build and taken a look at what's happened:
>
> $ arm-linux-nm -n .tmp_vmlinux1 > vm1.syms
> $ arm-linux-nm -n .tmp_vmlinux2 > vm2.syms
> $ arm-linux-nm -n vmlinux > vm3.syms
> $ diff -u <(sed s,^...........,, vm2.syms) <(sed s,^...........,, vm3.syms)
> $
>
> .tmp_vmlinux1 is the vmlinux file with no kallsyms data. .tmp_vmlinux2 is
> the vmlinux file with kallsyms data generated from the first image.
> vmlinux is the vmlinux file with kallsyms data generated from the second
> image.
>
> What the above shows is that we have the same symbols in the same order
> in the second and third stage. However:
>
> $ diff -u vm2.syms vm3.syms
> ...
> c0352900 R kallsyms_names
> -c03acd00 R kallsyms_markers
> -c03acf10 R kallsyms_token_table
> -c03ad290 R kallsyms_token_index
> ...
> +c03accf0 R kallsyms_markers
> +c03acf00 R kallsyms_token_table
> +c03ad280 R kallsyms_token_index
>
> So, the size of the kallsyms names has changed.
>
> Now, looking at the differences between stage 1 and stage 2:
>
> @@ -1,9 +1,3 @@
> -kallsyms_addresses
> -kallsyms_markers
> -kallsyms_names
> -kallsyms_num_syms
> -kallsyms_token_index
> -kallsyms_token_table
> syscalls_padding
> cpu_v7_suspend_size
> NR_syscalls
> @@ -17151,6 +17145,12 @@
> rpc_info_operations
> svc_pool_stats_seq_ops
> rpc_proc_fops
> +kallsyms_addresses
> +kallsyms_num_syms
> +kallsyms_names
> +kallsyms_markers
> +kallsyms_token_table
> +kallsyms_token_index
> __end_builtin_fw
> __end_pci_fixups_early
> __end_pci_fixups_enable
> @@ -28372,11 +28372,11 @@
> __security_initcall_start
> __initramfs_size
> __irf_end
> -__data_loc
> __init_end
> __per_cpu_end
> __per_cpu_load
> __per_cpu_start
> +__data_loc
> _data
> _sdata
> init_thread_union
>
>
> The difference in placement for the kallsyms symbols is more or less
> expected, because these appear as weak symbols in stage 1. However,
> notice that __data_loc has moved in relative position.
>
> As the names are compressed, this causes the size of the kallsyms name
> data to change size (because we end up with a different compression)
> which then causes the subsequent kallsyms data and other read-only data
> to move. This then causes 'inconsistent kallsyms data' error.
>
> Now, looking at the __data_loc values in these files:
>
> vm1.syms-c03bd408 t __irf_start
> vm1.syms-c03bd408 T __security_initcall_end
> vm1.syms-c03bd408 T __security_initcall_start
> vm1.syms-c03bd608 T __initramfs_size
> vm1.syms-c03bd608 t __irf_end
> vm1.syms:c03be000 A __data_loc
> vm1.syms-c03be000 A __init_end
> vm1.syms-c03be000 D __per_cpu_end
> vm1.syms-c03be000 D __per_cpu_load
> vm1.syms-c03be000 D __per_cpu_start
> vm1.syms-c03be000 D _data
> --
> vm2.syms-c0438608 t __irf_end
> vm2.syms-c0439000 A __init_end
> vm2.syms-c0439000 T __per_cpu_end
> vm2.syms-c0439000 T __per_cpu_load
> vm2.syms-c0439000 T __per_cpu_start
> vm2.syms:c043a000 A __data_loc
> vm2.syms-c043a000 D _data
> vm2.syms-c043a000 D _sdata
> vm2.syms-c043a000 D init_thread_union
> vm2.syms-c043c000 D __nosave_begin
> vm2.syms-c043c000 D __nosave_end
>
> What we see here is the start of the data section aligned to 8K as
> required for the init task data. The per-cpu data is aligned to a 4K
> boundary immediately before it. However, as it is an empty section,
> it can be aligned to the same 8K boundary as the data section depending
> on the size and placement of the previous sections which include the
> kallsyms data.
>
> The solution? We could artificially increase the alignment of the
> per-cpu data, or waste a byte after the per-cpu data to ensure that we
> don't align both together. That could mean wasting up to 12K of space
> for no reason other than to avoid this error which is exceedingly silly.
>
> I'm not sure whether the kallsyms name data generation could be
> changed so that this kind of thing doesn't matter but I suspect
> that's an exceedingly difficult problem to crack.
>
> In the mean time, I'd suggest building with the additional kallsyms pass
> when it's required.
We've been hitting this in Fedora on particularly UP kernel builds. I
also came to the same conclusions that you did (see Google+) and had a
chat with Arnd about it. A test build with the __per_cpu_* data removed
from the linker vmlinux.lds succeeds in building for the reasons cited.
That's not to say that was the intended fix, just an experiment to
confirm that this is the problem we've been hitting on some builds.
The "problem" is that kallsyms uses a "compression" algorithm that
derives the name compressed from the type+symbol_name so
"T__per_cpu_start" becomes "D__per_cpu_start". The compression is very
trivial in that unused characters in the set of input symbols are used
to represent popular character pairs, etc. So when the symbol changes
type according to nm output (as you explain), the size of kallsyms_names
will likely change, changing all the offsets. I was going to report this
either this evening or in the morning, but I have been waiting for some
tests to complete. Glad you found it.
As to longer term, I am happy to work up something that will spot this
particular kind of failure (symbol changes type) and output something
more useful during the kallsyms generation if you would like.
Are you planning to pull in either of the fixes you mention?
Jon.
_______________________________________________
arm mailing list
arm(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
12 years, 1 month
Soliciting for input on ARM
by Jon Masters
Hi everyone,
As you probably know, we had a FESCo meeting the other day, where we
raised our "work in progress" proposal for Fedora ARM Primary Arch
status in F18. This is a work in progress, and isn't final yet. We meant
to ping you about now, but probably should have done so even before
posting that draft so you don't feel left out :) Note that we know
Fedora 18 is an optimistic goal, but this is Fedora, and there will of
course be a Fedora 19, and 20, and so on if it takes that.
Why are we doing this? We think it's consistent with Fedora's mission
statement. After all, Fedora is all about driving technology, and if you
want to see where the buzz and excitement is, any IT magazine will tell
you that ARM is the "next big thing". We think it already is pretty big,
and it's growing. In a few years, it's going to be just amazing. We can
get there as a Secondary if we have to, but we think it's time to start
looking at changing that. Unlike other secondaries, ARM is growing
rapidly, and it's cheap. You can buy an ARM board for less than an order
of magnitude cheaper than a cheap Intel box.
All this awesomeness does mean you get some compromises. For example,
typical Fedora ARM users don't run Anaconda today, they dd a pre-built
image onto an SD Card and boot that (and we're working on getting these
built using the standard "appliance" like Fedora tooling). In the coming
months though, we'll see ARM servers with PXE and TFTP. In the future,
you'll have ARM servers booting using UEFI and smelling increasingly
like x86 over time. But it's not just server. The Raspberry Pi is going
to be - *is* - blowing everyone away. It reminds me of being a kid and
getting a BBC Master/B computer and being able to write programs and
understand how the computer actually worked. As Eben says, he's trying
to rekindle that kind of feeling kids used to have. We have made good
choices to keep armv5 support around and that means many Pi users will
be running Fedora by *default*. In the future, the next OLPC device (as
you know) will join the Pi in being ARM based.
Anyway. Here is the proposal we're working on:
https://fedoraproject.org/wiki/Features/FedoraARM
I want to get some specific input on a few questions if I may, and then
also ask you that you please let me/us know of any concerns/input:
0). Hardware. We are making certain plans for ARM hardware to be made
available for Fedora developers, in addition to the existing FAS-based
approach we have in Seneca today. What developer hardware would you
consider that you would want/need in order to be able to support ARM as
a target in Fedora? Do we need to buy each of you an ARM board? :)
1). Kernel sub-packages. 32-bit ARM is a bit of a zoo, and everyone
knows it. It's being worked on by Deepak's ARM kernel team at Linaro,
but well, nobody is kidding around in thinking we're at a single zimage
stage quite yet. That being the case, and for general sanity and
supportability, we do not intend to target kernels for every ARM
platform in existence. Instead, we propose a small number of kernels
(e.g. for omap, tegra, versatile, pi, and Calxeda highbank) as our upper
limit, all derived from pure-upstream sources. We currently build a
default of the versatile kernel (for Versatile Express, the ARM built
development platform that qemu also provides a simulation thereof) as
our fallback because it represents real hardware, and is qemu-able.
We want to be able to build a number of official ARM kernels (which will
shrink over time), and for those weird and whacky things that nobody is
even remotely calling mainline Fedora ARM, we're sure third parties will
provide independent non-Fedora bits for the adventurous. Anyway, back to
our official Fedora plan. What we don't want to do is disrupt your
workflows by taking massively longer to build a kernel. Right now, Koji
tells me an x86 build takes as little as 12 minutes, whereas an ARM
build (on non-Enterprise hardware, the kind that will be replaced with
real early 32-bit ARM server builders as part of this) takes 4 hours
today and will hopefully fall to 1.5, but still won't be instantaneous.
And that won't give us all the variants either. So we have some
possibilities:
- We build every ARM kernel every time
- We build e.g. versatile in general and periodically build the other
kernels by use of a SPEC file macro knob
I think the second is probably a non-starter for you. So assuming, the
first is the preferred option, then my question becomes:
- How long is acceptable for a kernel build to take?
Now, a trivial SPEC file or general non-arch kernel bug is likely to
fail on x86 well before it fails on ARM. That will of course take care
of many generic build issues that will fail a parent Koji build quickly.
And we're looking to base the official Fedora ARM builder hardware in
Phoenix on the first generation 32-bit servers, and these will have up
to 288 cores in 2U. Several of those should provide enough builders that
we don't get to a point of not accepting additional builds. Still,
that's great, but pipelining doesn't really solve the fundamental speed
issue. So, another option is that we modify Koji to submit sub-package
tasks across multiple builders. i.e. all of the ARM subpackages (and
this would happen for x86 variants too) would get submitted to builders
at the same time, rather than linearly. It's a lot of work, but it's
doable. Especially if it's the only option. It comes down to how long
you guys think is the longest you are willing to wait for an overall
all-arch build of the kernel to take in Koji.
To be clear, nothing in here is concerned with 64-bit yet. Those crazy
core counts I'm talking about in servers we'll use for building are all
happening this year, in the next 6 months. They'll be individually
coherent quad core Cortex-A9-like systems, like your Android tablet on
steroids, but not (yet) taking on x86. We don't ever expect ARM to take
on Intel head-to-head for performance, they're in it for density and
power saving, amongst other things. Next year, we'll see A15 based
servers. And the following year or thereabouts, I suspect we'll see the
first ARMv8 (AArch64) servers in testing. At that point, you're looking
at individual coherence domains of 8 cores+ (and it's a lot +), at a few
GHz, and so on. So we'll get you higher performing builders :)
2). Impact. What does making ARM a primary arch mean to you? Not what do
we think it means, but what do you think it means to you in terms of:
- How will this positively or negatively impact your role?
- What level of disruption are you willing to accept?
- Are you willing to make any changes to workflow?
We don't intend for this to be a trainwreck. If it's not ready, it won't
be PA, period. But we want to know how flexible you guys are willing to
be as we figure this out. If you want to wait until we have total
parity, single zimage, and we're just like x86, that is good to know
(and discuss) right now :)
I'm sure there's other stuff we can discuss. So let's do that :) If we
have useful input on IRC, I'll followup to this thread, but I like the
idea of doing it by email to keep a record of the discussion.
Thanks for reading - whew! I am...verbose.
Jon.
12 years, 1 month
