August 2014 - kernelnewbies@kernelnewbies.org

how do I port from 2.6.32 kernel to 3.11. kernel
by Omkar Houddin Aug. 7, 2014

Aug. 7, 2014

Hello Guys, Can you please suggest me how to port a pci driver which is now on 2.6.32 kernel to 3.11.4 kernel. Regards, OH

3 3

Re: Bad Patches and Issues with other devolopers
by Nick Krause Aug. 6, 2014

Aug. 6, 2014

On Tue, Aug 5, 2014 at 5:21 PM, Robert P. J. Day <rpjday(a)crashcourse.ca> wrote: > On Tue, 5 Aug 2014, Nick Krause wrote: > >> I want to help and improve the code plus get a code [sic] doing >> kernel development. > > *sigh* ... assuming you mean you want a *job* doing kernel > development, you may have already screwed yourself royally. > > it's obvious you want to get *some* kind of patches into the kernel, > just so you can say, "see? i patched the linux kernel!" what you > clearly don't understand is the unintended consequences of your > scattershot patching attempts. > > while prospective employers will certainly want to know what you've > contributed to the kernel, they will also simply google on your name > with respect to the kernel, and *that*, my boy, is where you are quite > simply f**ked. > > i googled on the words "nick krause linux kernel" (which is what any > minimally competent employer would do), and on the very first page of > results was this: > > http://www.themukt.com/2014/08/04/someone-trolling-linux-kernel-mailing-lis… > > what that page tells prospective employers is that you are in over > your head, you don't listen to advice, and you have very bad work > habits. > > regardless of whatever you do from now on, given your online > reputation that any employer will certainly find, you may have already > made yourself unemployable. > > rday > > -- > > ======================================================================== > Robert P. J. Day Ottawa, Ontario, CANADA > http://crashcourse.ca > > Twitter: http://twitter.com/rpjday > LinkedIn: http://ca.linkedin.com/in/rpjday > ======================================================================== > Is there any way to fix this or am I just unemployable. Cheers Nick

13 34

Re: Work (really slow directory access on ext4)
by Theodore Ts'o Aug. 6, 2014

Aug. 6, 2014

I don't subscribe to kernelnewbies, but I came across this thread in the mail archive while researching an unrelated issue. Valdis' observations are on the mark here. It's almost certain that you are getting overwhelmed with other disk traffic, because your directory isn't *that* big. That being said, there are certainly issues with really really big directories, and solving this is certainly not going to be a newbie project (if it was easy to solve, it would have been addressed a long time ago). See: http://en.it-usenet.org/thread/11916/10367/ for the background. It's a little bit dated, in that we do use a 64-bit hash on 64-bit systems, but the fundamental issues are still there. If you sort the readdir files by inode order, this can help significantly. Some userspace programs, such as mutt, do this. Unfortunately "ls" does not. (That might be a good newbie project, since it's a userspace-only project. However, I'm pretty sure the shellutils maintainers will also react negatively if they are sent patches which don't compile. :-) A proof of concept of how this can be a win can be found here: http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/contrib/spd_readdir.c LD_PRELOAD aren't guaranteed to work on all programs, so this is much more of a hack than something I'd recommend for extended production use. But it shows that if you have a readdir+stat workload, sorting by inode makes a huge difference. As far as getting traces to better understand problems, I strongly suggest that you try things like vmstat, iostat, and blktrace; system call traces like strace aren't going to get you very far. (See http://brooker.co.za/blog/2013/07/14/io-performance.html for a nice introduction to blktrace). Use the scientific method; collect baseline statistics using vmstat, iostat, sar, before you run your test workload, so you know how much I/O is going on before you start your test. If you can run your test on a quiscient system, that's a really good idea. Then collect statistics as your run your workload, and then only tweak one variable at a time, and record everything in a systematic way. Finally, if you have more problems of a technical nature with respect to the ext4, there is the ext3-users(a)redhat.com list, or the developer's list at linux-ext4(a)vger.kernel.org. It would be nice if you tried the ext3-users or the kernel-newbies or tried googling to see if anyone else has come across the problem and figured out the solution already, but if you can't figure things out any other way, do feel free to ask the linux-ext4 list. We won't bite. :-) Cheers, - Ted P.S. If you have a large number of directories which are much larger than you expect, and you don't want to do the "mkdir foo.new; mv foo/* foo.new ; rmdir foo; mv foo.new foo" trick on a large number of directories, you can also schedule downtime and while the file system is unmounted, use "e2fsck -fD". See the man page for more details. It won't solve all of your problems, and it might not solve any of your problem, but it will probably make the performance of large directories somewhat better.

3 2

Re: Bad Patches and Issues with other devolopers
by Nick Krause Aug. 6, 2014

Aug. 6, 2014

On Wed, Aug 6, 2014 at 2:05 PM, Nick Krause <xerofoify(a)gmail.com> wrote: > On Wed, Aug 6, 2014 at 1:24 PM, Robert P. J. Day <rpjday(a)crashcourse.ca> wrote: >> On Wed, 6 Aug 2014, Valdis.Kletnieks(a)vt.edu wrote: >> >>> On Wed, 06 Aug 2014 10:48:14 +0100, Anuz Pratap Singh Tomar said: >>> >>> > oh man you have gained prominence in vger? >>> > They have banned you from vger. >>> >>> Wow. I've been around for a dozen years or so, and can't remember >>> *that* ever happening before. That takes some *major* doing, and >>> could take literally years to straighten out. How to approach that? >> >> *sigh* ... the fact that nick has, *single-handedly*, pissed off and >> wasted the time of numerous subsystem maintainers to the point where >> he has been banned from LKML and has, in addition, *single-handedly* >> turned the kernel newbies mailing list into his personal self-help >> playground means that he needs to be shown the door. >> >> i don't want to sound unsympathetic, but it doesn't *matter* if this >> is nick's fault or not -- he is, quite simply, a disruptive influence >> and is, at the moment, turning this mailing list into chaos. >> >> people are asking, can he be salvaged? to which the proper answer >> is, who cares? there are a *lot* of kernel newbies out there who would >> desperately like to get to the point where *they* can start submitting >> patches, and most of *those* people are willing to read and listen and >> follow the advice of the veterans to the point where they become >> useful contributors. nick is not. >> >> it's massively ironic that countless people have told nick what he >> should be doing, to which his inveitable response is, "ok, but what >> should i be doing?" >> >> if you want to help nick, knock yourself out but take it offline. >> nick has already wasted far too much bandwidth that could have been >> invested in helping newbies that are willing to *listen*. >> >> rday >> >> -- >> >> ======================================================================== >> Robert P. J. Day Ottawa, Ontario, CANADA >> http://crashcourse.ca >> >> Twitter: http://twitter.com/rpjday >> LinkedIn: http://ca.linkedin.com/in/rpjday >> ======================================================================== >> > > Robert, > I am trying to listen now and this was my fault. > Regards Nick Also Robert I starting this the wrong way be treating this as a playground rather then for real work and that was another mistake I made. I do feel that if you guys give me a second case I will listen much better and stop wasting time. Regards Nick

1 0

Regarding bluez stack in linux kernel
by Vivek Panwar Aug. 6, 2014

Aug. 6, 2014

Hello, I want to study about the bluez stack which is used in the linux kernel. If anybody can provide me some books or pdf's regarding to the bluez. (I mean to say that how bluez stack is working in linux kernel and the code flow of this stack in linux or we can say that how it is communicating with linux kernel.) Thanks for the support Thanks, Vivek

2 1

Eudyptula Challenge status
by Raphael Philipe Aug. 6, 2014

Aug. 6, 2014

Hi Is someone taking the Eudyptula Challenge here? I was answering the tasks when suddenly it stopped returning my messages (with corrections or new tasks). Since Little Penguin tell us about any break, I was curious to ask. I've sent task 15 answer on 27th of July and got no reply since then. I've heard about a troll in the LKML trying to push non-sense patchs, so I decided to ask. https://lkml.org/lkml/2014/8/4/206 Has someone heard from Little Penguin recently? Thank you.

3 3

CPU throttling vs. clock scaling.
by StephanT Aug. 6, 2014

Aug. 6, 2014

Hi, Could someone, please explain the difference between CPU throttling and clock scaling. Thanks, Stephan

2 1

[PATCH] drivers: net: ethernet: intel: i40e: Fix missing uapi/linux/dcbnl.h include in i40e_fcoe.c
by Lucas Tanure Aug. 5, 2014

Aug. 5, 2014

Fix missing include in intel i40e driver. Without this include linux next tree won't compile. Signed-off-by: Lucas Tanure <tanure(a)linux.com> --- drivers/net/ethernet/intel/i40e/i40e_fcoe.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/intel/i40e/i40e_fcoe.c b/drivers/net/ethernet/intel/i40e/i40e_fcoe.c index 6938fc1..5d01db1 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_fcoe.c +++ b/drivers/net/ethernet/intel/i40e/i40e_fcoe.c @@ -33,6 +33,7 @@ #include <scsi/fc/fc_fcoe.h> #include <scsi/libfc.h> #include <scsi/libfcoe.h> +#include <uapi/linux/dcbnl.h> #include "i40e.h" #include "i40e_fcoe.h" -- 2.0.0

3 2

Re: Build Error in Linux-next, intel ethernet driver
by Lucas Tanure Aug. 5, 2014

Aug. 5, 2014

of course drivers/net/ethernet/intel/i40e/i40e_fcoe.c: In function ‘i40e_get_fcoe_tc_map’: drivers/net/ethernet/intel/i40e/i40e_fcoe.c:354:23: error: ‘IEEE_8021QAZ_APP_SEL_ETHERTYPE’ undeclared (first use in this function) if (app.selector == IEEE_8021QAZ_APP_SEL_ETHERTYPE && ^ drivers/net/ethernet/intel/i40e/i40e_fcoe.c:354:23: note: each undeclared identifier is reported only once for each function it appears in scripts/Makefile.build:257: recipe for target 'drivers/net/ethernet/intel/i40e/i40e_fcoe.o' failed make[5]: *** [drivers/net/ethernet/intel/i40e/i40e_fcoe.o] Error 1 scripts/Makefile.build:404: recipe for target 'drivers/net/ethernet/intel/i40e' failed make[4]: *** [drivers/net/ethernet/intel/i40e] Error 2 scripts/Makefile.build:404: recipe for target 'drivers/net/ethernet/intel' failed make[3]: *** [drivers/net/ethernet/intel] Error 2 make[3]: *** Waiting for unfinished jobs.... Thanks -- Lucas Tanure +55 (19) 988176559 On Tue, Aug 5, 2014 at 7:54 PM, Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> wrote: > On Tue, 2014-08-05 at 19:37 -0300, Lucas Tanure wrote: >> Thanks for reviewing my patch. My .config was bigger than 40k ( max >> attachment size for kernelnewbies list). > > First thing I noticed was that your config was missing CONFIG_I40E_DCB=y > option. So it appears that some of the recent FCoE code that was added > to the i40e driver needs to be wrapped with #ifdef CONFIG_I40E_DCB. > > Can you provide the error that you are receiving, without your patch > applied? That will help me narrow down what code needs to be wrapped.

1 0

Re: Build Error in Linux-next, intel ethernet driver
by Jeff Kirsher Aug. 5, 2014

Aug. 5, 2014

On Tue, 2014-08-05 at 19:37 -0300, Lucas Tanure wrote: > Thanks for reviewing my patch. My .config was bigger than 40k ( max > attachment size for kernelnewbies list). First thing I noticed was that your config was missing CONFIG_I40E_DCB=y option. So it appears that some of the recent FCoE code that was added to the i40e driver needs to be wrapped with #ifdef CONFIG_I40E_DCB. Can you provide the error that you are receiving, without your patch applied? That will help me narrow down what code needs to be wrapped.

1 0