VLAN tag stacking with bridge/tap device ?
Hello all, I try to do a setup with qemu and tap devices attached to bridges where 802.1Q vlan packets that are tag stacked are running through the tap device/bridge where the outer tag is stripped. But it seems on the way back out of qemu/guest and back through the tap and bridge no additional vlan tags are added back. The very same setup with only one vlan tag that is stripped and added back works as expected. Is there something in the tap device or bridge code that prevents stacking? Can this be done by configuration or by additional coding in the tap or bridge? -- Regards, Stephan PS: please add me as cc in reply
Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()
On Tue, 15 Jan 2019 14:42:21 +0100 Greg Kroah-Hartman wrote: > On Tue, Jan 15, 2019 at 02:01:48PM +0100, Rene Schickbauer wrote: > > To be frank, your argument, which boils down to "GPL is the only correct > > open source license", makes me ashamed to have been advocating people > > switching to Linux. This is exactly the kind of argument that made me > > switch away from closed source operating systems like Windows, only then > > it was Steve Ballmer using it against open source. > > What? > > No, my argument is, "If you want to interact directly with Linux kernel > code in kernel-space, then you have to abide by it's license, which is > GPLv2". That's it. If you wish to use open source code by another > license, wonderful, I'm not telling you what you can, and can not do, > but please, do not violate the license of the code I contributed under > GPLv2. > > ZFS could be the best filesystem ever to grace this planet, that's > fantastic, but given that the creators of that code placed it under a > license that was specifically designed to not be compatible with Linux > to prevent it from ever being used on Linux, well, you can see why I > really don't care about it. Why would I? > > Those copyright owners (well license owner at this point in time) could > fix this all tomorrow if they wanted to. But they do not, so _THEY_ are > the people you should be upset at. Not at the Linux kernel developers > who are giving you a kernel on which to use on your systems, for free, > under the GPLv2. Our position has always been very clear and upfront. > And really, so has the ZFS license creators. So why is anyone upset > about all of this? Nothing new has changed here with the license of > anything. > > best of luck! > > greg k-h Hi Greg, I'd say this is in fact more a moral question than a technical or legal issue. The true background is the simple question what the project (i.e. linux) is in fact all about, is it about helping people with lower skills or is it about ruling people. A company (more or less every company) is more about ruling, its aim is to move people into buying and using its products. Me (and quite surely Rene at least) think that the linux _community_ is more about helping others and hopefully less about legal and technical ruling. So your argument "go to the company XYZ and blame them" isn't really targetting in the right direction - as long as you see linux still as a community thing and not as a cash-cow company-alike. Maybe it would be a lot better to think about why there are people using ZFS and not some GPLed fs instead. Me too being a ZFS user I can tell you the simple fact that there is no GPL fs with equal features and stability (eh BTRFS). In fact quite some of us would probably use HAMMER2 (thanks Matt) instead if sure that it equals ZFS in terms of stability, still not BTRFS. So all you promote currently is the fs deficit linux actually still has (and had for years, or say decades). I doubt that this is/was helping the linux community a lot... Sure maintainers have to rule sometimes, but it only makes sense if you are able to present a working equal alternative. If you have none (and in this case you have no alternative to offer) you will only push people away from the community and that's probably not the right path for a community maintainer. -- Only my 2ct, Stephan
How to find the correct source address to a destination in a kernel driver?
Hello all, in former kernels with routing cache things were easy. We just used : rt = ip_route_output_key(XXX) src = rt->rt_src; Now if there is no routing cache, we tried this: rt = ip_route_output_key(XXX) src = inet_select_addr(rt->dst.dev, dst, RT_SCOPE_UNIVERSE); Unfortunately this does not work with interfaces having multiple ip addresses and the routing in question is not over the first configured ip. How do I get the correct src for all possible cases? -- Regards, Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How to find the correct source address to a destination in a kernel driver?
Hello all, in former kernels with routing cache things were easy. We just used : rt = ip_route_output_key(XXX) src = rt-rt_src; Now if there is no routing cache, we tried this: rt = ip_route_output_key(XXX) src = inet_select_addr(rt-dst.dev, dst, RT_SCOPE_UNIVERSE); Unfortunately this does not work with interfaces having multiple ip addresses and the routing in question is not over the first configured ip. How do I get the correct src for all possible cases? -- Regards, Stephan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
fstrim with raid controllers
Hello all, since SSDs are pretty widespread now the question seems valid. We have some raid controllers, namely: RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 2208 [Thunderbolt] (rev 05) We would like to use SSDs for raid1/5/6 setups but found out that the drivers don't seem to support the trim command yet. Are there any ideas how to make that work, or are there any other controllers that already support this? -- Regards, Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
fstrim with raid controllers
Hello all, since SSDs are pretty widespread now the question seems valid. We have some raid controllers, namely: RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 2208 [Thunderbolt] (rev 05) We would like to use SSDs for raid1/5/6 setups but found out that the drivers don't seem to support the trim command yet. Are there any ideas how to make that work, or are there any other controllers that already support this? -- Regards, Stephan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NUMA processor numbering
On Thu, 3 Oct 2013 07:22:55 -0300 Henrique de Moraes Holschuh wrote: > On Thu, 03 Oct 2013, Stephan von Krawczynski wrote: > > Does the above output mean that the cores are numbered right across the two > > physical cpus? Does this mean one has to pin processes to 0,2,4,... to stay > > in > > "short distance" to node 0 RAM? > > ... > > > If so, it would be a lot better to have them numbered 0-15 and 16-31 for > > pinning. > > Is there a way to achieve this? > > Yes, use hwloc to get the pinning masks for whatever property you want (e.g. > all threads in a given core, all threads in a given node, all threads that > share a given L3 cache...). > > http://www.open-mpi.org/projects/hwloc/ Ok, let me re-phrase the question a bit. Is it really possible what you see here: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 45 model name : Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz stepping: 7 microcode : 0x70d cpu MHz : 2002.000 cache size : 20480 KB physical id : 0 siblings: 16 core id : 0 cpu cores : 8 apicid : 0 initial apicid : 0 [...] processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 45 model name : Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz stepping: 7 microcode : 0x70d cpu MHz : 1518.000 cache size : 20480 KB physical id : 1 siblings: 16 core id : 0 cpu cores : 8 apicid : 32 initial apicid : 32 [...] These are the first two in the cpu list. If you look at that they are both on core id 0, but have different physical ids. Up to now I thought that processor 1 is the HT of core id 0. But with a different physical id this would mean that they are different NUMA nodes, right? How can that be? Someone from Intel with a hint? -- Regards, Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NUMA processor numbering
Hello all, I have a box with this kind of processor (0-31) and 128 GB RAM: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 45 model name : Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz stepping: 7 microcode : 0x70d cpu MHz : 2486.000 cache size : 20480 KB physical id : 0 siblings: 16 core id : 0 cpu cores : 8 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfp u pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_tim er aes xsave avx lahf_lm ida arat xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid bogomips: 4400.12 clflush size: 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: Now, numactl --hardware shows this: available: 2 nodes (0-1) node 0 cpus: 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 node 0 size: 64581 MB node 0 free: 12676 MB node 1 cpus: 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 node 1 size: 64637 MB node 1 free: 10660 MB node distances: node 0 1 0: 10 20 1: 20 10 Physically these are two processors with 8 Cores and 8 HT each. Does the above output mean that the cores are numbered right across the two physical cpus? Does this mean one has to pin processes to 0,2,4,... to stay in "short distance" to node 0 RAM? If so, it would be a lot better to have them numbered 0-15 and 16-31 for pinning. Is there a way to achieve this? Please cc me when answering. -- Regards, Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NUMA processor numbering
Hello all, I have a box with this kind of processor (0-31) and 128 GB RAM: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 45 model name : Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz stepping: 7 microcode : 0x70d cpu MHz : 2486.000 cache size : 20480 KB physical id : 0 siblings: 16 core id : 0 cpu cores : 8 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfp u pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_tim er aes xsave avx lahf_lm ida arat xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid bogomips: 4400.12 clflush size: 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: Now, numactl --hardware shows this: available: 2 nodes (0-1) node 0 cpus: 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 node 0 size: 64581 MB node 0 free: 12676 MB node 1 cpus: 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 node 1 size: 64637 MB node 1 free: 10660 MB node distances: node 0 1 0: 10 20 1: 20 10 Physically these are two processors with 8 Cores and 8 HT each. Does the above output mean that the cores are numbered right across the two physical cpus? Does this mean one has to pin processes to 0,2,4,... to stay in short distance to node 0 RAM? If so, it would be a lot better to have them numbered 0-15 and 16-31 for pinning. Is there a way to achieve this? Please cc me when answering. -- Regards, Stephan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NUMA processor numbering
On Thu, 3 Oct 2013 07:22:55 -0300 Henrique de Moraes Holschuh h...@hmh.eng.br wrote: On Thu, 03 Oct 2013, Stephan von Krawczynski wrote: Does the above output mean that the cores are numbered right across the two physical cpus? Does this mean one has to pin processes to 0,2,4,... to stay in short distance to node 0 RAM? ... If so, it would be a lot better to have them numbered 0-15 and 16-31 for pinning. Is there a way to achieve this? Yes, use hwloc to get the pinning masks for whatever property you want (e.g. all threads in a given core, all threads in a given node, all threads that share a given L3 cache...). http://www.open-mpi.org/projects/hwloc/ Ok, let me re-phrase the question a bit. Is it really possible what you see here: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 45 model name : Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz stepping: 7 microcode : 0x70d cpu MHz : 2002.000 cache size : 20480 KB physical id : 0 siblings: 16 core id : 0 cpu cores : 8 apicid : 0 initial apicid : 0 [...] processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 45 model name : Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz stepping: 7 microcode : 0x70d cpu MHz : 1518.000 cache size : 20480 KB physical id : 1 siblings: 16 core id : 0 cpu cores : 8 apicid : 32 initial apicid : 32 [...] These are the first two in the cpu list. If you look at that they are both on core id 0, but have different physical ids. Up to now I thought that processor 1 is the HT of core id 0. But with a different physical id this would mean that they are different NUMA nodes, right? How can that be? Someone from Intel with a hint? -- Regards, Stephan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problem with ping command on 3.9.X compared to 3.2.45
Hello all,
is there a good reason why the ping command gets different answers from 3.[2-8]
and 3.9 kernels? Please have a look at this output from strace:
First 3.2.45:
sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("1.2.3.4")},
msg_iov(1)=[{"\10\0\312\tO\17\0\1\207\252\250Q\0\0\0\0\352\26\6\0\0\0\0\0\20\21\22\23\24\25\26\27"...,
64}], msg_controllen=0, msg_flags=0}, 0) = 64
recvmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("5.6.7.8")},
msg_iov(1)=[{"E\300\0p\276\217\0\0@\1\210\257\331@@\5\331@@\10\5\1\341\272\331@@\3E\0\0T"...,
192}], msg_controllen=32, {cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=0x1d
/* SCM_??? */, ...}, msg_flags=0}, 0) = 112
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER,
"\10\0\0\0\0\0\0\0@R\17\336\6\177\0\0", 16) = 0
recvmsg(3, 0x7fff1d5858f0, MSG_DONTWAIT) = -1 EAGAIN (Resource temporarily
unavailable)
(Host X pinging to 1.2.3.4 gets a redirect from 5.6.7.8)
Now same situation on 3.9:
sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("1.2.3.4")},
msg_iov(1)=[{"\10\0tb\f\313\0\1q\250\250Q\0\0\0\0\232\4\4\0\0\0\0\0\20\21\22\23\24\25\26\27"...,
64}], msg_controllen=0, msg_flags=0}, 0) = 64
recvmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("5.6.7.8")},
msg_iov(1)=[{"E\300\0pI:\0\0@\1\375\376\331@@\5\331@@\16\5\1\341\272\331@@\3E\0\0T"...,
192}], msg_controllen=32, {cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=0x1d
/* SCM_??? */, ...}, msg_flags=0}, 0) = 112
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER,
"\10\0\0\0\0\0\0\0\300\322M\5\315\177\0\0", 16) = 0
recvmsg(3, 0x7fff3c52a390, MSG_DONTWAIT) = -1 EHOSTUNREACH (No route to host)
This leads to a situation where "ping -w " comes back immediately
because it thinks there is some error. Whereas under 3.2.45 (upto 3.8 AFAIR) it
waits and receives answers.
Is there a reason for this behaviour change? Can this be tuned by some kernel
options?
Please cc me in case of answer, it's hard to follow the complete list nowadays.
--
Regards,
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Problem with ping command on 3.9.X compared to 3.2.45
Hello all,
is there a good reason why the ping command gets different answers from 3.[2-8]
and 3.9 kernels? Please have a look at this output from strace:
First 3.2.45:
sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr(1.2.3.4)},
msg_iov(1)=[{\10\0\312\tO\17\0\1\207\252\250Q\0\0\0\0\352\26\6\0\0\0\0\0\20\21\22\23\24\25\26\27...,
64}], msg_controllen=0, msg_flags=0}, 0) = 64
recvmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr(5.6.7.8)},
msg_iov(1)=[{E\300\0p\276\217\0\0@\1\210\257\331@@\5\331@@\10\5\1\341\272\331@@\3E\0\0T...,
192}], msg_controllen=32, {cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=0x1d
/* SCM_??? */, ...}, msg_flags=0}, 0) = 112
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER,
\10\0\0\0\0\0\0\0@R\17\336\6\177\0\0, 16) = 0
recvmsg(3, 0x7fff1d5858f0, MSG_DONTWAIT) = -1 EAGAIN (Resource temporarily
unavailable)
(Host X pinging to 1.2.3.4 gets a redirect from 5.6.7.8)
Now same situation on 3.9:
sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr(1.2.3.4)},
msg_iov(1)=[{\10\0tb\f\313\0\1q\250\250Q\0\0\0\0\232\4\4\0\0\0\0\0\20\21\22\23\24\25\26\27...,
64}], msg_controllen=0, msg_flags=0}, 0) = 64
recvmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr(5.6.7.8)},
msg_iov(1)=[{E\300\0pI:\0\0@\1\375\376\331@@\5\331@@\16\5\1\341\272\331@@\3E\0\0T...,
192}], msg_controllen=32, {cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=0x1d
/* SCM_??? */, ...}, msg_flags=0}, 0) = 112
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER,
\10\0\0\0\0\0\0\0\300\322M\5\315\177\0\0, 16) = 0
recvmsg(3, 0x7fff3c52a390, MSG_DONTWAIT) = -1 EHOSTUNREACH (No route to host)
This leads to a situation where ping -w deadline comes back immediately
because it thinks there is some error. Whereas under 3.2.45 (upto 3.8 AFAIR) it
waits deadline and receives answers.
Is there a reason for this behaviour change? Can this be tuned by some kernel
options?
Please cc me in case of answer, it's hard to follow the complete list nowadays.
--
Regards,
Stephan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
acpi_cpufreq on Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz problem (3.[4-9].X)
Hello all, I see some kind of bug with acpi_cpufreq on Intels Q6600 cpus. If you load the module you see this in proc: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz stepping: 11 cpu MHz : 600.000 cache size : 4096 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dtherm tpr_shadow vnmi flexpriority bogomips: 4800.22 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: (repeated for other cores) As you can see cpu MHz shows 600. Now take a look at cpufreq-info output and see: hardware limits: 600 MHz - 900 MHz Obviously this is wrong, I don't know what the minimum should be, but the max should be 2.40 GHz. If you stress the cpu you will notice MHz go up to 900, but that's it. I have several such boxes, and all act the same with all kernels I tried so far (3.4.X, 3.8.X, 3.9.X). If you unload acpi_cpufreq you see the correct values. To me seems to be no display problem. The box "feels" slower when the module is loaded. With a cpu type Q9300 btw everything works as expected. If there are ideas or patches to test how to remove this problem, feel free to mail/cc me. I can check out whatever looks promising. -- Regards, Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
acpi_cpufreq on Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz problem (3.[4-9].X)
Hello all, I see some kind of bug with acpi_cpufreq on Intels Q6600 cpus. If you load the module you see this in proc: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz stepping: 11 cpu MHz : 600.000 cache size : 4096 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dtherm tpr_shadow vnmi flexpriority bogomips: 4800.22 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: (repeated for other cores) As you can see cpu MHz shows 600. Now take a look at cpufreq-info output and see: hardware limits: 600 MHz - 900 MHz Obviously this is wrong, I don't know what the minimum should be, but the max should be 2.40 GHz. If you stress the cpu you will notice MHz go up to 900, but that's it. I have several such boxes, and all act the same with all kernels I tried so far (3.4.X, 3.8.X, 3.9.X). If you unload acpi_cpufreq you see the correct values. To me seems to be no display problem. The box feels slower when the module is loaded. With a cpu type Q9300 btw everything works as expected. If there are ideas or patches to test how to remove this problem, feel free to mail/cc me. I can check out whatever looks promising. -- Regards, Stephan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
virtio-net in 3.9 and below
Hello all, during heavy testing I found out that kernel 3.9 virtio-net seems to have a lot better performance than former kernel versions. I am not quite sure if this is due to general enhancements in 3.9 or specific to the virtio-net code. In case someone thinks its really virtio-net, is there a chance to backport this code to 3.4.X or even 3.2.X ? Some older boxes just don't compile 3.9, so this could be quite helpful. Please cc me in case of answer. -- Regards, Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
virtio-net in 3.9 and below
Hello all, during heavy testing I found out that kernel 3.9 virtio-net seems to have a lot better performance than former kernel versions. I am not quite sure if this is due to general enhancements in 3.9 or specific to the virtio-net code. In case someone thinks its really virtio-net, is there a chance to backport this code to 3.4.X or even 3.2.X ? Some older boxes just don't compile 3.9, so this could be quite helpful. Please cc me in case of answer. -- Regards, Stephan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Question regarding include/linux/linkage.h (3.8.8)
Hello all, if you look at the above file it contains: #include where should this file come from? There is no "asm" directory inside linux-3.8.8/include/ ... ? If you need additional info please cc me. -- Regards, Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Question regarding include/linux/linkage.h (3.8.8)
Hello all, if you look at the above file it contains: #include asm/linkage.h where should this file come from? There is no asm directory inside linux-3.8.8/include/ ... ? If you need additional info please cc me. -- Regards, Stephan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problem compiling firmware/yam/9600.bin in 3.8.8
Hello all, I just tried to compile a complete kernel 3.8.8 including firmwares. First I linked /usr/include/linux to /usr/src/linux/include/linux. I think this is for user-space compilations to use the right header files, correct? Then I tried the kernel and this is what happened: IHEXfirmware/yam/9600.bin In file included from /usr/include/bits/errno.h:24:0, from /usr/include/errno.h:35, from firmware/ihex2fw.c:15: /usr/include/linux/errno.h:4:30: fatal error: uapi/linux/errno.h: No such file or directory compilation terminated. make[1]: *** [firmware/ihex2fw] Error 1 make: *** [modules] Error 2 /usr/include/uapi is empty, but /usr/src/linux/include/uapi is not Did I miss something or are there more links to make nowadays for a complete setup? Please cc me in case ... -- Regards, Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problem compiling firmware/yam/9600.bin in 3.8.8
Hello all, I just tried to compile a complete kernel 3.8.8 including firmwares. First I linked /usr/include/linux to /usr/src/linux/include/linux. I think this is for user-space compilations to use the right header files, correct? Then I tried the kernel and this is what happened: IHEXfirmware/yam/9600.bin In file included from /usr/include/bits/errno.h:24:0, from /usr/include/errno.h:35, from firmware/ihex2fw.c:15: /usr/include/linux/errno.h:4:30: fatal error: uapi/linux/errno.h: No such file or directory compilation terminated. make[1]: *** [firmware/ihex2fw] Error 1 make: *** [modules] Error 2 /usr/include/uapi is empty, but /usr/src/linux/include/uapi is not Did I miss something or are there more links to make nowadays for a complete setup? Please cc me in case ... -- Regards, Stephan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No serial since kernel 3.8
On Wed, 17 Apr 2013 20:55:04 +0200 "Rafael J. Wysocki" wrote: > On Wednesday, April 17, 2013 11:38:30 AM Bjorn Helgaas wrote: > > [+cc Rafael & linux-acpi] > > Thanks. > > > On Tue, Apr 16, 2013 at 10:14 AM, Stephan von Krawczynski > > wrote: > > > On Tue, 16 Apr 2013 10:59:53 -0400 > > > Josh Boyer wrote: > > > > > >> On Tue, Apr 16, 2013 at 04:55:25PM +0200, richard -rw- weinberger wrote: > > >> >On Tue, Apr 16, 2013 at 4:20 PM, Stephan von Krawczynski > > >> > wrote: > > >> >> Hello, > > >> >> > > >> >> can some kind soul please explain how I can get my serial port back > > >> >> under > > >> >> kernel 3.8.X. Earlier kernels showed: > > >> >> > > >> >> Jan 10 13:57:18 mybox kernel: [0.712829] serial8250: ttyS0 at I/O > > >> >> 0x3f8 > > >> >> (irq = 4) is a 16550A > > >> >> > > >> >> But 3.8.4: > > >> >> > > >> >> Mar 26 10:39:14 admin kernel: [0.603647] serial 00:0a: disabled > > >> >> > > >> >> Only kernel is replaced, no change in distro > > >> >> Is there some kernel boot parameter needed now? > > >> >> I tried 3.4.X and it works, even 3.7.X works... > > >> > > > >> >So, 3.8.3 worked and 3.8.4 introduced a regression? > > >> >If so please confirm. > > >> > > > >> >CC'ing gregkh, just in case... > > >> > > >> We had a report of this in Fedora that was fixed with 3.8.7. An upstream > > >> change had been brought back to the 3.8.x series, and it was subsequently > > >> reverted. 3.8.7 picked up the revert. > > >> > > >> josh > > > > > > 3.8.7 does not work either. I just checked it. I tried shared and not > > > shared IRQ: > > > > > > Apr 16 17:47:05 mybox kernel: [0.604826] Serial: 8250/16550 driver, 8 > > > ports, IRQ sharing disabled > > > > > > and another test: > > > > > > Apr 16 18:07:08 mybox kernel: [0.601203] Serial: 8250/16550 driver, 8 > > > ports, IRQ sharing enabled > > > > > > I must say that 3.8.7 does not even tell the "serial 00:0a: disabled" any > > > more. > > > This is no special board, it is a pretty mainstream asus xeon board with > > > onboard serial. > > > Loading 3.4.24 (just an example) makes the port work immediately. > > > Anything else I can test? > > > > 3.7.6 works, and 3.8.3, 3.8.4, 3.8.7 all fail. So it looks like a > > regression between 3.7.6 and 3.8.3. > > > > The "serial 00:0a: disabled" message is from PNP, so I added Rafael > > and linux-acpi. Complete dmesg logs from 3.7.6 and 3.8.4 would be a > > place to start. Also maybe an acpidump, since the 00:0a PNP device > > probably came from PNPACPI. You could attach all these to a > > https://bugzilla.kernel.org report if you want a place to stash them. > > > > Josh, do you have a pointer (URL) to the Fedora issue so we can rule > > that in or out? > > Stephan, below is a list of commits touching the PNP code between 3.7 and 3.8. > > Can you please check if any of them has triggered the problem you're seeing? > > Rafael > > > 13cde3b PNP: Handle IORESOURCE_BITS in resource allocation > c937766 PNP: Simplify setting of resources > cdc87c5 pnpacpi: fix incorrect TEST_ALPHA() test > a6b5e88 ACPI / PNP: Do not crash due to stale pointer use during system resume > 38de279 pnpbios: remove CONFIG_HOTPLUG ifdefs > 2905875 ACPI / PNP: skip ACPI device nodes associated with physical nodes > already > 046d9ce ACPI: Move device resources interpretation code from PNP to ACPI core > > -- > I speak only for myself. > Rafael J. Wysocki, Intel Open Source Technology Center. Hello all, I checked 3.8.8 today and it _does_ work. Shall we burn some time to find out why? The only significant output difference between working and not working we could find is: not working: Apr 2 17:28:23 mybox kernel: [0.603270] serial 00:0a: disabled working (3.8.8): Apr 18 12:58:50 mybox kernel: [2.855929] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A -- Regards, Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No serial since kernel 3.8
On Wed, 17 Apr 2013 20:55:04 +0200 Rafael J. Wysocki r...@sisk.pl wrote: On Wednesday, April 17, 2013 11:38:30 AM Bjorn Helgaas wrote: [+cc Rafael linux-acpi] Thanks. On Tue, Apr 16, 2013 at 10:14 AM, Stephan von Krawczynski sk...@ithnet.com wrote: On Tue, 16 Apr 2013 10:59:53 -0400 Josh Boyer jwbo...@gmail.com wrote: On Tue, Apr 16, 2013 at 04:55:25PM +0200, richard -rw- weinberger wrote: On Tue, Apr 16, 2013 at 4:20 PM, Stephan von Krawczynski sk...@ithnet.com wrote: Hello, can some kind soul please explain how I can get my serial port back under kernel 3.8.X. Earlier kernels showed: Jan 10 13:57:18 mybox kernel: [0.712829] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A But 3.8.4: Mar 26 10:39:14 admin kernel: [0.603647] serial 00:0a: disabled Only kernel is replaced, no change in distro Is there some kernel boot parameter needed now? I tried 3.4.X and it works, even 3.7.X works... So, 3.8.3 worked and 3.8.4 introduced a regression? If so please confirm. CC'ing gregkh, just in case... We had a report of this in Fedora that was fixed with 3.8.7. An upstream change had been brought back to the 3.8.x series, and it was subsequently reverted. 3.8.7 picked up the revert. josh 3.8.7 does not work either. I just checked it. I tried shared and not shared IRQ: Apr 16 17:47:05 mybox kernel: [0.604826] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled and another test: Apr 16 18:07:08 mybox kernel: [0.601203] Serial: 8250/16550 driver, 8 ports, IRQ sharing enabled I must say that 3.8.7 does not even tell the serial 00:0a: disabled any more. This is no special board, it is a pretty mainstream asus xeon board with onboard serial. Loading 3.4.24 (just an example) makes the port work immediately. Anything else I can test? 3.7.6 works, and 3.8.3, 3.8.4, 3.8.7 all fail. So it looks like a regression between 3.7.6 and 3.8.3. The serial 00:0a: disabled message is from PNP, so I added Rafael and linux-acpi. Complete dmesg logs from 3.7.6 and 3.8.4 would be a place to start. Also maybe an acpidump, since the 00:0a PNP device probably came from PNPACPI. You could attach all these to a https://bugzilla.kernel.org report if you want a place to stash them. Josh, do you have a pointer (URL) to the Fedora issue so we can rule that in or out? Stephan, below is a list of commits touching the PNP code between 3.7 and 3.8. Can you please check if any of them has triggered the problem you're seeing? Rafael 13cde3b PNP: Handle IORESOURCE_BITS in resource allocation c937766 PNP: Simplify setting of resources cdc87c5 pnpacpi: fix incorrect TEST_ALPHA() test a6b5e88 ACPI / PNP: Do not crash due to stale pointer use during system resume 38de279 pnpbios: remove CONFIG_HOTPLUG ifdefs 2905875 ACPI / PNP: skip ACPI device nodes associated with physical nodes already 046d9ce ACPI: Move device resources interpretation code from PNP to ACPI core -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. Hello all, I checked 3.8.8 today and it _does_ work. Shall we burn some time to find out why? The only significant output difference between working and not working we could find is: not working: Apr 2 17:28:23 mybox kernel: [0.603270] serial 00:0a: disabled working (3.8.8): Apr 18 12:58:50 mybox kernel: [2.855929] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A -- Regards, Stephan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No serial since kernel 3.8
On Tue, 16 Apr 2013 10:59:53 -0400 Josh Boyer wrote: > On Tue, Apr 16, 2013 at 04:55:25PM +0200, richard -rw- weinberger wrote: > >On Tue, Apr 16, 2013 at 4:20 PM, Stephan von Krawczynski > > wrote: > >> Hello, > >> > >> can some kind soul please explain how I can get my serial port back under > >> kernel 3.8.X. Earlier kernels showed: > >> > >> Jan 10 13:57:18 mybox kernel: [0.712829] serial8250: ttyS0 at I/O 0x3f8 > >> (irq = 4) is a 16550A > >> > >> But 3.8.4: > >> > >> Mar 26 10:39:14 admin kernel: [0.603647] serial 00:0a: disabled > >> > >> Only kernel is replaced, no change in distro > >> Is there some kernel boot parameter needed now? > >> I tried 3.4.X and it works, even 3.7.X works... > > > >So, 3.8.3 worked and 3.8.4 introduced a regression? > >If so please confirm. > > > >CC'ing gregkh, just in case... > > We had a report of this in Fedora that was fixed with 3.8.7. An upstream > change had been brought back to the 3.8.x series, and it was subsequently > reverted. 3.8.7 picked up the revert. > > josh 3.8.7 does not work either. I just checked it. I tried shared and not shared IRQ: Apr 16 17:47:05 mybox kernel: [0.604826] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled and another test: Apr 16 18:07:08 mybox kernel: [0.601203] Serial: 8250/16550 driver, 8 ports, IRQ sharing enabled I must say that 3.8.7 does not even tell the "serial 00:0a: disabled" any more. This is no special board, it is a pretty mainstream asus xeon board with onboard serial. Loading 3.4.24 (just an example) makes the port work immediately. Anything else I can test? -- Regards, Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No serial since kernel 3.8
On Tue, 16 Apr 2013 16:55:25 +0200 richard -rw- weinberger wrote: > On Tue, Apr 16, 2013 at 4:20 PM, Stephan von Krawczynski > wrote: > > Hello, > > > > can some kind soul please explain how I can get my serial port back under > > kernel 3.8.X. Earlier kernels showed: > > > > Jan 10 13:57:18 mybox kernel: [0.712829] serial8250: ttyS0 at I/O 0x3f8 > > (irq = 4) is a 16550A > > > > But 3.8.4: > > > > Mar 26 10:39:14 admin kernel: [0.603647] serial 00:0a: disabled > > > > Only kernel is replaced, no change in distro > > Is there some kernel boot parameter needed now? > > I tried 3.4.X and it works, even 3.7.X works... > > So, 3.8.3 worked and 3.8.4 introduced a regression? > If so please confirm. > > CC'ing gregkh, just in case... No, neither 3.8.4 nor 3.8.3 worked. The last working version I know for sure is 3.7.6 FYI: I don't load serial as a module -- Regards, Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
No serial since kernel 3.8
Hello, can some kind soul please explain how I can get my serial port back under kernel 3.8.X. Earlier kernels showed: Jan 10 13:57:18 mybox kernel: [0.712829] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A But 3.8.4: Mar 26 10:39:14 admin kernel: [0.603647] serial 00:0a: disabled Only kernel is replaced, no change in distro Is there some kernel boot parameter needed now? I tried 3.4.X and it works, even 3.7.X works... -- Regards, Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
No serial since kernel 3.8
Hello, can some kind soul please explain how I can get my serial port back under kernel 3.8.X. Earlier kernels showed: Jan 10 13:57:18 mybox kernel: [0.712829] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A But 3.8.4: Mar 26 10:39:14 admin kernel: [0.603647] serial 00:0a: disabled Only kernel is replaced, no change in distro Is there some kernel boot parameter needed now? I tried 3.4.X and it works, even 3.7.X works... -- Regards, Stephan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No serial since kernel 3.8
On Tue, 16 Apr 2013 16:55:25 +0200 richard -rw- weinberger richard.weinber...@gmail.com wrote: On Tue, Apr 16, 2013 at 4:20 PM, Stephan von Krawczynski sk...@ithnet.com wrote: Hello, can some kind soul please explain how I can get my serial port back under kernel 3.8.X. Earlier kernels showed: Jan 10 13:57:18 mybox kernel: [0.712829] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A But 3.8.4: Mar 26 10:39:14 admin kernel: [0.603647] serial 00:0a: disabled Only kernel is replaced, no change in distro Is there some kernel boot parameter needed now? I tried 3.4.X and it works, even 3.7.X works... So, 3.8.3 worked and 3.8.4 introduced a regression? If so please confirm. CC'ing gregkh, just in case... No, neither 3.8.4 nor 3.8.3 worked. The last working version I know for sure is 3.7.6 FYI: I don't load serial as a module -- Regards, Stephan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No serial since kernel 3.8
On Tue, 16 Apr 2013 10:59:53 -0400 Josh Boyer jwbo...@gmail.com wrote: On Tue, Apr 16, 2013 at 04:55:25PM +0200, richard -rw- weinberger wrote: On Tue, Apr 16, 2013 at 4:20 PM, Stephan von Krawczynski sk...@ithnet.com wrote: Hello, can some kind soul please explain how I can get my serial port back under kernel 3.8.X. Earlier kernels showed: Jan 10 13:57:18 mybox kernel: [0.712829] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A But 3.8.4: Mar 26 10:39:14 admin kernel: [0.603647] serial 00:0a: disabled Only kernel is replaced, no change in distro Is there some kernel boot parameter needed now? I tried 3.4.X and it works, even 3.7.X works... So, 3.8.3 worked and 3.8.4 introduced a regression? If so please confirm. CC'ing gregkh, just in case... We had a report of this in Fedora that was fixed with 3.8.7. An upstream change had been brought back to the 3.8.x series, and it was subsequently reverted. 3.8.7 picked up the revert. josh 3.8.7 does not work either. I just checked it. I tried shared and not shared IRQ: Apr 16 17:47:05 mybox kernel: [0.604826] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled and another test: Apr 16 18:07:08 mybox kernel: [0.601203] Serial: 8250/16550 driver, 8 ports, IRQ sharing enabled I must say that 3.8.7 does not even tell the serial 00:0a: disabled any more. This is no special board, it is a pretty mainstream asus xeon board with onboard serial. Loading 3.4.24 (just an example) makes the port work immediately. Anything else I can test? -- Regards, Stephan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with tg3 in 2.6.23.12
On Sun, 13 Jan 2008 15:04:07 +0100 Stephan von Krawczynski <[EMAIL PROTECTED]> wrote: > Hello all, > > we recently tried to stress several netblk configurations and got this kernel > log (amongst others). If additional information is required feel free to ask. > We can try patches as well the config is not in production yet. Does anybody have an idea what my original posting is all about? Regards, Stephan -- 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: Problem with tg3 in 2.6.23.12
On Sun, 13 Jan 2008 15:04:07 +0100 Stephan von Krawczynski [EMAIL PROTECTED] wrote: Hello all, we recently tried to stress several netblk configurations and got this kernel log (amongst others). If additional information is required feel free to ask. We can try patches as well the config is not in production yet. Does anybody have an idea what my original posting is all about? Regards, Stephan -- 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/
Problem with tg3 in 2.6.23.12
Hello all, we recently tried to stress several netblk configurations and got this kernel log (amongst others). If additional information is required feel free to ask. We can try patches as well the config is not in production yet. Jan 12 15:46:54 fs2 kernel: swapper: page allocation failure. order:0, mode:0x20 Jan 12 15:46:54 fs2 kernel: [] __alloc_pages+0x283/0x294 Jan 12 15:46:54 fs2 kernel: [] cache_alloc_refill+0x286/0x45f Jan 12 15:46:54 fs2 kernel: [] kmem_cache_alloc+0x37/0x72 Jan 12 15:46:54 fs2 kernel: [] __alloc_skb+0x29/0x104 Jan 12 15:46:54 fs2 kernel: [] __netdev_alloc_skb+0x1c/0x35 Jan 12 15:46:54 fs2 kernel: [] tg3_alloc_rx_skb+0xb2/0x141 [tg3] Jan 12 15:46:54 fs2 kernel: [] netif_receive_skb+0x257/0x271 Jan 12 15:46:54 fs2 kernel: [] tg3_poll+0x370/0x7fd [tg3] Jan 12 15:46:54 fs2 kernel: [] tg3_poll+0x25d/0x7fd [tg3] Jan 12 15:46:54 fs2 kernel: [] tg3_poll+0x25d/0x7fd [tg3] Jan 12 15:46:54 fs2 kernel: [] net_rx_action+0x64/0xf4 Jan 12 15:46:54 fs2 kernel: [] __do_softirq+0x6c/0xcf Jan 12 15:46:54 fs2 kernel: [] do_softirq+0x32/0x36 Jan 12 15:46:54 fs2 kernel: [] do_IRQ+0x5c/0x73 Jan 12 15:46:54 fs2 kernel: [] smp_apic_timer_interrupt+0x74/0x80 Jan 12 15:46:54 fs2 kernel: [] default_idle+0x0/0x3e Jan 12 15:46:54 fs2 kernel: [] common_interrupt+0x23/0x28 Jan 12 15:46:54 fs2 kernel: [] default_idle+0x0/0x3e Jan 12 15:46:54 fs2 kernel: [] default_idle+0x2c/0x3e Jan 12 15:46:54 fs2 kernel: [] cpu_idle+0x91/0xaa Jan 12 15:46:54 fs2 kernel: [] start_kernel+0x2b8/0x2c0 Jan 12 15:46:54 fs2 kernel: [] unknown_bootoption+0x0/0x196 Jan 12 15:46:54 fs2 kernel: === Jan 12 15:46:54 fs2 kernel: DMA per-cpu: Jan 12 15:46:54 fs2 kernel: CPU0: Hot: hi:0, btch: 1 usd: 0 Cold: hi:0, btch: 1 usd: 0 Jan 12 15:46:54 fs2 kernel: CPU1: Hot: hi:0, btch: 1 usd: 0 Cold: hi:0, btch: 1 usd: 0 Jan 12 15:46:56 fs2 kernel: Normal per-cpu: Jan 12 15:46:56 fs2 kernel: CPU0: Hot: hi: 186, btch: 31 usd: 30 Cold: hi: 62, btch: 15 usd: 61 Jan 12 15:46:56 fs2 kernel: CPU1: Hot: hi: 186, btch: 31 usd: 30 Cold: hi: 62, btch: 15 usd: 59 Jan 12 15:46:56 fs2 kernel: HighMem per-cpu: Jan 12 15:46:56 fs2 kernel: CPU0: Hot: hi: 186, btch: 31 usd: 135 Cold: hi: 62, btch: 15 usd: 7 Jan 12 15:46:56 fs2 kernel: CPU1: Hot: hi: 186, btch: 31 usd: 173 Cold: hi: 62, btch: 15 usd: 3 Jan 12 15:46:56 fs2 kernel: Active:15858 inactive:200197 dirty:16318 writeback:4335 unstable:0 Jan 12 15:46:56 fs2 kernel: free:671858 slab:17016 mapped:5807 pagetables:161 bounce:0 Jan 12 15:46:56 fs2 kernel: DMA free:3504kB min:68kB low:84kB high:100kB active:0kB inactive:3680kB present:16256kB pages_scanned:8 all_unreclaimable? no Jan 12 15:46:56 fs2 kernel: lowmem_reserve[]: 0 873 4048 4048 Jan 12 15:46:56 fs2 kernel: Normal free:1328kB min:3744kB low:4680kB high:5616kB active:11912kB inactive:783484kB present:894080kB pages_scanned:32 all_unreclaimable? no Jan 12 15:46:56 fs2 kernel: lowmem_reserve[]: 0 0 25400 25400 Jan 12 15:46:56 fs2 kernel: HighMem free:2682600kB min:512kB low:3916kB high:7324kB active:51520kB inactive:13624kB present:3251200kB pages_scanned:0 all_unreclaimable? no Jan 12 15:46:56 fs2 kernel: lowmem_reserve[]: 0 0 0 0 Jan 12 15:46:56 fs2 kernel: DMA: 1*4kB 1*8kB 0*16kB 1*32kB 0*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3500kB Jan 12 15:46:56 fs2 kernel: Normal: 0*4kB 1*8kB 0*16kB 1*32kB 0*64kB 0*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 1320kB Jan 12 15:46:56 fs2 kernel: HighMem: 2262*4kB 1422*8kB 862*16kB 524*32kB 395*64kB 326*128kB 270*256kB 232*512kB 169*1024kB 106*2048kB 485*4096kB = 2682600kB Jan 12 15:46:56 fs2 kernel: Swap cache: add 41, delete 34, find 1/2, race 0+0 Jan 12 15:46:56 fs2 kernel: Free swap = 2104344kB Jan 12 15:46:56 fs2 kernel: Total swap = 2104472kB Basic infos: 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3) 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) 00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3) 00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host
Problem with tg3 in 2.6.23.12
Hello all, we recently tried to stress several netblk configurations and got this kernel log (amongst others). If additional information is required feel free to ask. We can try patches as well the config is not in production yet. Jan 12 15:46:54 fs2 kernel: swapper: page allocation failure. order:0, mode:0x20 Jan 12 15:46:54 fs2 kernel: [c014c711] __alloc_pages+0x283/0x294 Jan 12 15:46:54 fs2 kernel: [c016079e] cache_alloc_refill+0x286/0x45f Jan 12 15:46:54 fs2 kernel: [c01604dd] kmem_cache_alloc+0x37/0x72 Jan 12 15:46:54 fs2 kernel: [c0279c36] __alloc_skb+0x29/0x104 Jan 12 15:46:54 fs2 kernel: [c027a6bd] __netdev_alloc_skb+0x1c/0x35 Jan 12 15:46:54 fs2 kernel: [f897b8e3] tg3_alloc_rx_skb+0xb2/0x141 [tg3] Jan 12 15:46:54 fs2 kernel: [c027dac9] netif_receive_skb+0x257/0x271 Jan 12 15:46:54 fs2 kernel: [f8981d2a] tg3_poll+0x370/0x7fd [tg3] Jan 12 15:46:54 fs2 kernel: [f8981c17] tg3_poll+0x25d/0x7fd [tg3] Jan 12 15:46:54 fs2 kernel: [f8981c17] tg3_poll+0x25d/0x7fd [tg3] Jan 12 15:46:54 fs2 kernel: [c027f9cc] net_rx_action+0x64/0xf4 Jan 12 15:46:54 fs2 kernel: [c0125d99] __do_softirq+0x6c/0xcf Jan 12 15:46:54 fs2 kernel: [c0125e2e] do_softirq+0x32/0x36 Jan 12 15:46:54 fs2 kernel: [c0106355] do_IRQ+0x5c/0x73 Jan 12 15:46:54 fs2 kernel: [c01149ab] smp_apic_timer_interrupt+0x74/0x80 Jan 12 15:46:54 fs2 kernel: [c0102c56] default_idle+0x0/0x3e Jan 12 15:46:54 fs2 kernel: [c010479f] common_interrupt+0x23/0x28 Jan 12 15:46:54 fs2 kernel: [c0102c56] default_idle+0x0/0x3e Jan 12 15:46:54 fs2 kernel: [c0102c82] default_idle+0x2c/0x3e Jan 12 15:46:54 fs2 kernel: [c0102389] cpu_idle+0x91/0xaa Jan 12 15:46:54 fs2 kernel: [c038d8c0] start_kernel+0x2b8/0x2c0 Jan 12 15:46:54 fs2 kernel: [c038d0e0] unknown_bootoption+0x0/0x196 Jan 12 15:46:54 fs2 kernel: === Jan 12 15:46:54 fs2 kernel: DMA per-cpu: Jan 12 15:46:54 fs2 kernel: CPU0: Hot: hi:0, btch: 1 usd: 0 Cold: hi:0, btch: 1 usd: 0 Jan 12 15:46:54 fs2 kernel: CPU1: Hot: hi:0, btch: 1 usd: 0 Cold: hi:0, btch: 1 usd: 0 Jan 12 15:46:56 fs2 kernel: Normal per-cpu: Jan 12 15:46:56 fs2 kernel: CPU0: Hot: hi: 186, btch: 31 usd: 30 Cold: hi: 62, btch: 15 usd: 61 Jan 12 15:46:56 fs2 kernel: CPU1: Hot: hi: 186, btch: 31 usd: 30 Cold: hi: 62, btch: 15 usd: 59 Jan 12 15:46:56 fs2 kernel: HighMem per-cpu: Jan 12 15:46:56 fs2 kernel: CPU0: Hot: hi: 186, btch: 31 usd: 135 Cold: hi: 62, btch: 15 usd: 7 Jan 12 15:46:56 fs2 kernel: CPU1: Hot: hi: 186, btch: 31 usd: 173 Cold: hi: 62, btch: 15 usd: 3 Jan 12 15:46:56 fs2 kernel: Active:15858 inactive:200197 dirty:16318 writeback:4335 unstable:0 Jan 12 15:46:56 fs2 kernel: free:671858 slab:17016 mapped:5807 pagetables:161 bounce:0 Jan 12 15:46:56 fs2 kernel: DMA free:3504kB min:68kB low:84kB high:100kB active:0kB inactive:3680kB present:16256kB pages_scanned:8 all_unreclaimable? no Jan 12 15:46:56 fs2 kernel: lowmem_reserve[]: 0 873 4048 4048 Jan 12 15:46:56 fs2 kernel: Normal free:1328kB min:3744kB low:4680kB high:5616kB active:11912kB inactive:783484kB present:894080kB pages_scanned:32 all_unreclaimable? no Jan 12 15:46:56 fs2 kernel: lowmem_reserve[]: 0 0 25400 25400 Jan 12 15:46:56 fs2 kernel: HighMem free:2682600kB min:512kB low:3916kB high:7324kB active:51520kB inactive:13624kB present:3251200kB pages_scanned:0 all_unreclaimable? no Jan 12 15:46:56 fs2 kernel: lowmem_reserve[]: 0 0 0 0 Jan 12 15:46:56 fs2 kernel: DMA: 1*4kB 1*8kB 0*16kB 1*32kB 0*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3500kB Jan 12 15:46:56 fs2 kernel: Normal: 0*4kB 1*8kB 0*16kB 1*32kB 0*64kB 0*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 1320kB Jan 12 15:46:56 fs2 kernel: HighMem: 2262*4kB 1422*8kB 862*16kB 524*32kB 395*64kB 326*128kB 270*256kB 232*512kB 169*1024kB 106*2048kB 485*4096kB = 2682600kB Jan 12 15:46:56 fs2 kernel: Swap cache: add 41, delete 34, find 1/2, race 0+0 Jan 12 15:46:56 fs2 kernel: Free swap = 2104344kB Jan 12 15:46:56 fs2 kernel: Total swap = 2104472kB Basic infos: 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3) 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) 00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3) 00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0e.0 PCI
How to walk through the tasklist ?
Hello all,
can anyone give me a short hint how walking through the tasklist in a device
driver can be achieved nowadays. In ancient pre-20 times you could simply:
read_lock(_lock);
p=current;
do {
if (p->pid==pid) {
read_unlock(_lock);
/* found */
}
p=p->next_task;
} while (p!=current);
read_unlock(_lock);
But since tasklist_lock is gone this is not safe any longer. So, what can I do?
--
Regards,
Stephan
-
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/
How to walk through the tasklist ?
Hello all,
can anyone give me a short hint how walking through the tasklist in a device
driver can be achieved nowadays. In ancient pre-20 times you could simply:
read_lock(tasklist_lock);
p=current;
do {
if (p-pid==pid) {
read_unlock(tasklist_lock);
/* found */
}
p=p-next_task;
} while (p!=current);
read_unlock(tasklist_lock);
But since tasklist_lock is gone this is not safe any longer. So, what can I do?
--
Regards,
Stephan
-
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/
