Re: [Xenomai-core] heres a go at an adeos-ipipe-2.6.15-i386-1.1-01.patch
Philippe Gerum wrote: Jim Cromie wrote: Philippe Gerum wrote: You may want to try this one: http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.15-i386-1.1-03.patch although Im not surprised, I feel like telling someone, [EMAIL PROTECTED] ~]$ uname -a Linux harpo.jimc.earth 2.6.15-ipipe-103-sony #1 Sat Jan 7 13:54:09 MST 2006 i686 i686 i386 GNU/Linux [EMAIL PROTECTED] ~]$ is NFS root for .. soekris:~# uname -a Linux soekris 2.6.15-ipipe-103-sk #3 Sat Jan 7 13:42:06 MST 2006 i586 GNU/Linux soekris:~# soekris:~# df Filesystem 1K-blocks Used Available Use% Mounted on 192.168.42.1:/nfshost/soekris 20158372 14249292 4885080 75% / tmpfs63268 0 63268 0% /dev/shm /dev/hda1 484602268767190813 59% /mnt/flash 192.168.42.1:/boot20158400 14249312 4885088 75% /boot 192.168.42.1:/lib/modules 20158400 14249312 4885088 75% /lib/modules 192.168.42.1:/media/cdrecorder 20158400 14249312 4885088 75% /mnt/cd 192.168.42.1:/home20158400 14249312 4885088 75% /home 192.168.42.1:/mnt/dilbert 15638816 11716256 3128128 79% /mnt/dilbert 192.168.42.1:/usr/xenomai 20158400 14249312 4885088 75% /usr/xenomai 192.168.42.1:/home/jimc/dilbert/pirt 15638816 11716256 3128128 79% /mnt/pirt woohoo! I just diffed my-1.01 and real-1.03, it looks like I missed a bunch of these: - spin_unlock_irqrestore(ioapic_lock, flags); + spin_unlock_irqrestore_hw(ioapic_lock, flags); did I get lucky ? or is it cuz Im not SMP ? The additional hw locking is to make 100% sure that built-in Adeos domains pushed above Linux could call the related routines i.e. any routine manipulating the io_apic spinlock. This said, I've been a bit silly ironing the IO-APIC enabling code, since you can't get any conflict until the IO-APIC is well, enabled, and interrupts could flow and thus feed the high priority domain. even during the kernel init phase. Since the I-pipe is enabled quite early during this process, I've decided to play extra safe here. or cuz my sony has no APIC (as distinct from ACPI) ? do any PCs have an APIC, or is that something for servers / hi-end or embedded ? It has become the norm for desktops, Intel CPU(s) of hi-end boxen have one especially SMP since it works with the IO-APIC for routing interrupts among other things. Still not the norm for embedded AFAIK, this will possibly evolve the same way over time too. BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 1ff4 (usable) BIOS-e820: 1ff4 - 1ff5 (ACPI data) BIOS-e820: 1ff5 - 2000 (ACPI NVS) 511MB LOWMEM available. On node 0 totalpages: 130880 DMA zone: 4096 pages, LIFO batch:0 DMA32 zone: 0 pages, LIFO batch:0 Normal zone: 126784 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:0 DMI present. ACPI: RSDP (v000 SONY ) @ 0x000f53f0 ACPI: RSDT (v001 SONY F1 0x20040323 MSFT 0x0097) @ 0x1ff4 ACPI: FADT (v002 SONY F1 0x20040323 MSFT 0x0097) @ 0x1ff40200 ACPI: OEMB (v001 SONY F1 0x20040323 MSFT 0x0097) @ 0x1ff50040 ACPI: DSDT (v001 SONY F1 0x20040323 MSFT 0x010d) @ 0x ACPI: PM-Timer IO Port: 0x408 Allocating PCI resources starting at 3000 (gap: 2000:e000) Built 1 zonelists Kernel command line: ro root=LABEL=/ Initializing CPU#0 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 1694.791 MHz processor. Using pmtmr for high-res timesource I-pipe 1.1-03: pipeline enabled. BTW, what happened to 1.01 and 1.02 ? There were three critical changes to merge for starting 1.1; one at a time, -03 has ended the series. tia jimc -- Philippe.
Re: [Xenomai-core] heres a go at an adeos-ipipe-2.6.15-i386-1.1-01.patch
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=0x 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 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 ? 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 a good writeup for the regular folks (like me) on this list is here: http://lwn.net/Articles/164380/ config.gz Description: GNU Zip compressed data ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] heres a go at an adeos-ipipe-2.6.15-i386-1.1-01.patch
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=0x 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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] heres a go at an adeos-ipipe-2.6.15-i386-1.1-01.patch
Kent Borg wrote: On Sat, Jan 07, 2006 at 12:52:23AM -0700, Jim Cromie wrote: You get to keep both pieces ? ;-) Cool! Ive attached my working config - might get you going. pls report back what made your config not work, once you find it. I'm looking at it now. In the meantime, if anyone is interested in looking at my config (stock Ubuntu with defaults taken on all new oldconfig questions), I am attaching it here. You may want to try this one: http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.15-i386-1.1-03.patch -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] heres a go at an adeos-ipipe-2.6.15-i386-1.1-01.patch
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=0x 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 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 ? 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 a good writeup for the regular folks (like me) on this list is here: http://lwn.net/Articles/164380/ config.gz Description: GNU Zip compressed data
Re: [Xenomai-core] heres a go at an adeos-ipipe-2.6.15-i386-1.1-01.patch
On Sat, Jan 07, 2006 at 12:52:23AM -0700, Jim Cromie wrote: You get to keep both pieces ? ;-) Cool! Ive attached my working config - might get you going. pls report back what made your config not work, once you find it. I'm looking at it now. In the meantime, if anyone is interested in looking at my config (stock Ubuntu with defaults taken on all new oldconfig questions), I am attaching it here. Thanks, -kb # # Automatically generated make config: don't edit # Linux kernel version: 2.6.15 # Fri Jan 6 15:57:32 2006 # CONFIG_X86_32=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # CONFIG_CLEAN_COMPILE is not set CONFIG_BROKEN=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_SYSCTL=y CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set CONFIG_INITRAMFS_SOURCE= # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_EMBEDDED=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y # # Block layer # CONFIG_LBD=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set CONFIG_M686=y # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_PPRO_FENCE=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_HPET_TIMER=y # CONFIG_SMP is not set CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set CONFIG_IPIPE=y # CONFIG_IPIPE_STATS is not set CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=m CONFIG_X86_MCE_P4THERMAL=y CONFIG_TOSHIBA=m CONFIG_I8K=m CONFIG_X86_REBOOTFIXUPS=y CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set # CONFIG_REGPARM is not set CONFIG_SECCOMP=y # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_1000 is not set CONFIG_HZ=250 CONFIG_PHYSICAL_START=0x10 # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_PM_LEGACY=y # CONFIG_PM_DEBUG is not set CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_STD_PARTITION= # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_SLEEP_PROC_SLEEP=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_HOTKEY=m CONFIG_ACPI_FAN=m CONFIG_ACPI_PROCESSOR=m
Re: [Xenomai-core] heres a go at an adeos-ipipe-2.6.15-i386-1.1-01.patch
Jim Cromie wrote: Philippe Gerum wrote: You may want to try this one: http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.15-i386-1.1-03.patch although Im not surprised, I feel like telling someone, [EMAIL PROTECTED] ~]$ uname -a Linux harpo.jimc.earth 2.6.15-ipipe-103-sony #1 Sat Jan 7 13:54:09 MST 2006 i686 i686 i386 GNU/Linux [EMAIL PROTECTED] ~]$ is NFS root for .. soekris:~# uname -a Linux soekris 2.6.15-ipipe-103-sk #3 Sat Jan 7 13:42:06 MST 2006 i586 GNU/Linux soekris:~# soekris:~# df Filesystem 1K-blocks Used Available Use% Mounted on 192.168.42.1:/nfshost/soekris 20158372 14249292 4885080 75% / tmpfs63268 0 63268 0% /dev/shm /dev/hda1 484602268767190813 59% /mnt/flash 192.168.42.1:/boot20158400 14249312 4885088 75% /boot 192.168.42.1:/lib/modules 20158400 14249312 4885088 75% /lib/modules 192.168.42.1:/media/cdrecorder 20158400 14249312 4885088 75% /mnt/cd 192.168.42.1:/home20158400 14249312 4885088 75% /home 192.168.42.1:/mnt/dilbert 15638816 11716256 3128128 79% /mnt/dilbert 192.168.42.1:/usr/xenomai 20158400 14249312 4885088 75% /usr/xenomai 192.168.42.1:/home/jimc/dilbert/pirt 15638816 11716256 3128128 79% /mnt/pirt woohoo! I just diffed my-1.01 and real-1.03, it looks like I missed a bunch of these: - spin_unlock_irqrestore(ioapic_lock, flags); + spin_unlock_irqrestore_hw(ioapic_lock, flags); did I get lucky ? or is it cuz Im not SMP ? The additional hw locking is to make 100% sure that built-in Adeos domains pushed above Linux could call the related routines even during the kernel init phase. Since the I-pipe is enabled quite early during this process, I've decided to play extra safe here. or cuz my sony has no APIC (as distinct from ACPI) ? do any PCs have an APIC, or is that something for servers / hi-end or embedded ? It has become the norm for desktops, Intel CPU(s) of hi-end boxen have one especially SMP since it works with the IO-APIC for routing interrupts among other things. Still not the norm for embedded AFAIK, this will possibly evolve the same way over time too. BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 1ff4 (usable) BIOS-e820: 1ff4 - 1ff5 (ACPI data) BIOS-e820: 1ff5 - 2000 (ACPI NVS) 511MB LOWMEM available. On node 0 totalpages: 130880 DMA zone: 4096 pages, LIFO batch:0 DMA32 zone: 0 pages, LIFO batch:0 Normal zone: 126784 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:0 DMI present. ACPI: RSDP (v000 SONY ) @ 0x000f53f0 ACPI: RSDT (v001 SONY F1 0x20040323 MSFT 0x0097) @ 0x1ff4 ACPI: FADT (v002 SONY F1 0x20040323 MSFT 0x0097) @ 0x1ff40200 ACPI: OEMB (v001 SONY F1 0x20040323 MSFT 0x0097) @ 0x1ff50040 ACPI: DSDT (v001 SONY F1 0x20040323 MSFT 0x010d) @ 0x ACPI: PM-Timer IO Port: 0x408 Allocating PCI resources starting at 3000 (gap: 2000:e000) Built 1 zonelists Kernel command line: ro root=LABEL=/ Initializing CPU#0 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 1694.791 MHz processor. Using pmtmr for high-res timesource I-pipe 1.1-03: pipeline enabled. BTW, what happened to 1.01 and 1.02 ? There were three critical changes to merge for starting 1.1; one at a time, -03 has ended the series. tia jimc -- Philippe.
Re: [Xenomai-core] heres a go at an adeos-ipipe-2.6.15-i386-1.1-01.patch
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? Thanks, -kb ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] heres a go at an adeos-ipipe-2.6.15-i386-1.1-01.patch
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? Thanks, -kb
Re: [Xenomai-core] heres a go at an adeos-ipipe-2.6.15-i386-1.1-01.patch
Hi Jim, Jim Cromie wrote: hi Phillipe, everyone, happy 06 ! Bugfree 06? Nah, just kidding... Out of curiosity, I applied adeos-ipipe-2.6.14-i386-1.1-01.patch on top of 15. the rejects were small, and simple enough looking, that even a lazy sod like myself might manually fix them, so I did. whats more, it built clean and booted ! I havent done anything more demanding than ls, df, etc, but hey, low hanging fruit tastes just as good / even better ;-) So heres hoping that you've not started this particular thankless task, Nope, and since I don't routinely check Adeos against intermediate kernel versions, it's useful to know about the result people get doing so. Thanks. and Ive saved your cycles for something more dependent on your particular talents. Well, the list of my talents is shortening it seems, since I managed to issue a nifty set of terminally broken patches for ppc, arm and blackfin in less than four hours yesterday... Ok, before resorting to brain surgery, I guess than I'm going to try coffee first. Who knows... enjoy. jimc Cheers, -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] heres a go at an adeos-ipipe-2.6.15-i386-1.1-01.patch
Hi Jim, Jim Cromie wrote: hi Phillipe, everyone, happy 06 ! Bugfree 06? Nah, just kidding... Out of curiosity, I applied adeos-ipipe-2.6.14-i386-1.1-01.patch on top of 15. the rejects were small, and simple enough looking, that even a lazy sod like myself might manually fix them, so I did. whats more, it built clean and booted ! I havent done anything more demanding than ls, df, etc, but hey, low hanging fruit tastes just as good / even better ;-) So heres hoping that you've not started this particular thankless task, Nope, and since I don't routinely check Adeos against intermediate kernel versions, it's useful to know about the result people get doing so. Thanks. and Ive saved your cycles for something more dependent on your particular talents. Well, the list of my talents is shortening it seems, since I managed to issue a nifty set of terminally broken patches for ppc, arm and blackfin in less than four hours yesterday... Ok, before resorting to brain surgery, I guess than I'm going to try coffee first. Who knows... enjoy. jimc Cheers, -- Philippe.
