Jim Cromie wrote:
Kent Borg wrote:

Jim Cromie posted a patch attempt for 2.6.15 (yeah!), and the patch
applied, but it doesn't compile for me:

 [...]
   LD      init/built-in.o
   LD      .tmp_vmlinux1
 arch/i386/kernel/built-in.o: In function `__ipipe_sync_stage':
 : undefined reference to `ret_from_intr'
 arch/i386/kernel/built-in.o: In function `__ipipe_sync_stage':
 : undefined reference to `ret_from_intr'
 make: *** [.tmp_vmlinux1] Error 1
 ~/linux-2.6.15$
For a .config I started with the stock Ubuntu 2.6.12-10-686 config
file and then took the defaults for all the oldconfig questions.

Suggestions?

You get to keep both pieces ? ;-)


FWIW, the kernel was still running on my soekris 4801 til just now. (I rebooted)
Most of that time it was without its NFS root fs;
my laptop was unconnected.  It was doing *no* work of any kind tho.
Not that this helps...


Im trying a kernel build on my sony laptop pentium M.
differnt config than yours, but fuller than the soekris.
Its running now, Im typing on it.
wifi card works too !

Ive attached my working config - might get you going.
pls report back what made your config not work, once you find it.

::::::::::::::
ipipe/Linux
::::::::::::::
Priority=100, Id=0x00000000
irq0-15: accepted
irq32: grabbed, virtual
::::::::::::::
ipipe/version
::::::::::::::
1.1-01




FWIW, I diffed the 14 patch against mine, was puzzled at the large textual diffs. Guessed that it was a file ordering diff in the tar, and then forgot to mention this
at send.  This seems kinda odd, since Im running linux.

Phillipe, are you running BSD  ?  </ducks>


Well, sometimes this idea surfaces in the back of my head when I'm waiting for large disk I/O to complete over 2.6. And when it finally does, this operation leaves me as breathless as my hard drive...

Are you creating patches from an fs other than ext3 ?
That could explain the ordering.  If not, Im stumped.
Maybe its an svn thing, they have a berkley-db-as-fs dont they ?


Yes they do, but this is unrelated to the apparently funky internal layout of my patches. It's just that I now have all Adeos ports over 2.6 in a single Linux tree (but the blackfin one which is uClinux-based), and each and every arch-specific patch is just extracted by an automated script from the original multi-arch patch. The way each individual per-arch patch is (re-)composed does not depend on the fs then.

hth,
jimc



Also, FWIW, Ive been reading LKML, and it appears that
Ingo Molnar's  Mutex patches have turned the corner with Linux.
Theyre not in, and Ive got no crystal ball, but I suspect they
will get into 17 or 16


The real meat we are waiting for is the priority inheritance mechanism so that the ownership property of mutexes is leveraged to do something sensible against the inversion priorities that plague the vanilla kernel, and this particular piece is going to be harder to push forward (kind of "asbestos underware everyone!"). This said, Ingo Molnar said that he would progressively distill the PREEMPT_RT infrastructure into the mainline kernel, and so far, he succeeded quite well doing so. Remarkable chess player ;o) However, I must admit that from the Adeos maintenance POV, those changes all over the map that took place since 2.6.11 or so are making the job quite more complex.

a good writeup for the regular folks (like me) on this list is here:
http://lwn.net/Articles/164380/


Nice piece, indeed.


------------------------------------------------------------------------

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


--

Philippe.

Reply via email to