[Xenomai] Xenomai-3 booting problems

[Xenomai] Xenomai-3 booting problems

[Leopold Palomo-Avellaneda]

Hi,


I have compiling a Cobalt kernel. I have followed the web "wikipress" [1];-) 
recommendations. However, my box (a normal desktop computer - Dell Optiplex 
7010 -) doesn't boot. It throws a message like:
....
timer doesn't work through interrup-remapped IO-apic

...

enabling noapic in the boot options I'm able to boot. But, I have not make any 
test by now. Some interesting messages:

$ dmesg | grep -i xenomai
[    0.000000] Linux version 3.16.0-xenomai-3.0.0 (root@soho) (gcc version 
4.9.1 (Debian 4.9.1-19) ) #1 SMP Wed Jan 21 16:29:36 UTC 2015
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-xenomai-3.0.0 
root=UUID=15cfac82-1127-421f-9aed-eaf48247ed4e ro quiet noapic
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-
xenomai-3.0.0 root=UUID=15cfac82-1127-421f-9aed-eaf48247ed4e ro quiet noapic
[    0.705071] [Xenomai] scheduling class idle registered.
[    0.705072] [Xenomai] scheduling class rt registered.
[    0.705090] [Xenomai] disabling automatic C1E state promotion on Intel 
processor
[    0.705104] [Xenomai] SMI-enabled chipset found, but SMI workaround 
disabled
          (see xenomai.smi parameter). You might encounter
[    0.705284] I-pipe: head domain Xenomai registered.
[    0.717986] [Xenomai] Cobalt v3.0-rc2 (Exact Zero) [DEBUG]
[    0.897726] usb usb1: Manufacturer: Linux 3.16.0-xenomai-3.0.0 xhci_hcd
[    0.898617] usb usb2: Manufacturer: Linux 3.16.0-xenomai-3.0.0 xhci_hcd
[    0.914114] usb usb3: Manufacturer: Linux 3.16.0-xenomai-3.0.0 ehci_hcd
[    0.930109] usb usb4: Manufacturer: Linux 3.16.0-xenomai-3.0.0 ehci_hcd
*** RTnet for Xenomai v3.0-rc2 ***


So, can avoid to pass the noapic parameter to the kernel to boot?

Thanks,

Leopold


[1] http://xenomai.org/2014/06/configuring-for-x86-based-dual-kernels/

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150122/9c0b0dbe/attachment.sig>

Re: [Xenomai] Xenomai-3 booting problems

[Gilles Chanteperdrix]

On Thu, Jan 22, 2015 at 08:47:24AM +0100, Leopold Palomo-Avellaneda wrote:
> Hi,
> 
> 
> I have compiling a Cobalt kernel. I have followed the web "wikipress" [1];-) 
> recommendations. However, my box (a normal desktop computer - Dell Optiplex 
> 7010 -) doesn't boot. It throws a message like:
> ....
> timer doesn't work through interrup-remapped IO-apic
> 
> ...
> 
> enabling noapic in the boot options I'm able to boot. But, I have not make any 
> test by now. Some interesting messages:
> 
> $ dmesg | grep -i xenomai
> [    0.000000] Linux version 3.16.0-xenomai-3.0.0 (root@soho) (gcc version 
> 4.9.1 (Debian 4.9.1-19) ) #1 SMP Wed Jan 21 16:29:36 UTC 2015
> [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-xenomai-3.0.0 
> root=UUID=15cfac82-1127-421f-9aed-eaf48247ed4e ro quiet noapic
> [    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-
> xenomai-3.0.0 root=UUID=15cfac82-1127-421f-9aed-eaf48247ed4e ro quiet noapic
> [    0.705071] [Xenomai] scheduling class idle registered.
> [    0.705072] [Xenomai] scheduling class rt registered.
> [    0.705090] [Xenomai] disabling automatic C1E state promotion on Intel 
> processor
> [    0.705104] [Xenomai] SMI-enabled chipset found, but SMI workaround 
> disabled
>           (see xenomai.smi parameter). You might encounter
> [    0.705284] I-pipe: head domain Xenomai registered.
> [    0.717986] [Xenomai] Cobalt v3.0-rc2 (Exact Zero) [DEBUG]
> [    0.897726] usb usb1: Manufacturer: Linux 3.16.0-xenomai-3.0.0 xhci_hcd
> [    0.898617] usb usb2: Manufacturer: Linux 3.16.0-xenomai-3.0.0 xhci_hcd
> [    0.914114] usb usb3: Manufacturer: Linux 3.16.0-xenomai-3.0.0 ehci_hcd
> [    0.930109] usb usb4: Manufacturer: Linux 3.16.0-xenomai-3.0.0 ehci_hcd
> *** RTnet for Xenomai v3.0-rc2 ***
> 
> 
> So, can avoid to pass the noapic parameter to the kernel to boot?

Please post the full boot logs, and the kernel configuration. Does the kernel
work with exactly the same .config but without Xenomai? Is
CONFIG_SMP enabled? Because if CONFIG_SMP is enabled, Xenomai will
not work without an APIC.

Also, please do not compile RTnet in the kernel, compile it as a module.

-- 
					    Gilles.

Re: [Xenomai] Xenomai-3 booting problems

[Jan Kiszka]

On 2015-01-22 08:47, Leopold Palomo-Avellaneda wrote:
> Hi,
> 
> 
> I have compiling a Cobalt kernel. I have followed the web "wikipress" [1];-) 
> recommendations. However, my box (a normal desktop computer - Dell Optiplex 
> 7010 -) doesn't boot. It throws a message like:
> ....
> timer doesn't work through interrup-remapped IO-apic

Sounds like interrupt remapping is enabled for your system. That's not
supported by Xenomai / I-pipe so far (on my to-do list, along with
x2APIC support). Disable this via "intel_iommu=off intremap=off" in the
kernel command line or by changing the kernel config to not include
IOMMU / interrupt remapping support.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Xenomai-3 booting problems

[Leopold Palomo-Avellaneda]

El Dijous, 22 de gener de 2015, a les 08:54:29, Gilles Chanteperdrix va 
escriure:
> On Thu, Jan 22, 2015 at 08:47:24AM +0100, Leopold Palomo-Avellaneda wrote:
> > Hi,
> > 
> > 
> > I have compiling a Cobalt kernel. I have followed the web "wikipress"
> > [1];-) recommendations. However, my box (a normal desktop computer - Dell
> > Optiplex 7010 -) doesn't boot. It throws a message like:
> > ....
> > timer doesn't work through interrup-remapped IO-apic
> > 
> > ...
> > 
> > enabling noapic in the boot options I'm able to boot. But, I have not make
> > any test by now. Some interesting messages:
> > 
> > $ dmesg | grep -i xenomai
> > [    0.000000] Linux version 3.16.0-xenomai-3.0.0 (root@soho) (gcc version
> > 4.9.1 (Debian 4.9.1-19) ) #1 SMP Wed Jan 21 16:29:36 UTC 2015
> > [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-xenomai-3.0.0
> > root=UUID=15cfac82-1127-421f-9aed-eaf48247ed4e ro quiet noapic
> > [    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-
> > xenomai-3.0.0 root=UUID=15cfac82-1127-421f-9aed-eaf48247ed4e ro quiet
> > noapic [    0.705071] [Xenomai] scheduling class idle registered.
> > [    0.705072] [Xenomai] scheduling class rt registered.
> > [    0.705090] [Xenomai] disabling automatic C1E state promotion on Intel
> > processor
> > [    0.705104] [Xenomai] SMI-enabled chipset found, but SMI workaround
> > disabled
> > 
> >           (see xenomai.smi parameter). You might encounter
> > 
> > [    0.705284] I-pipe: head domain Xenomai registered.
> > [    0.717986] [Xenomai] Cobalt v3.0-rc2 (Exact Zero) [DEBUG]
> > [    0.897726] usb usb1: Manufacturer: Linux 3.16.0-xenomai-3.0.0 xhci_hcd
> > [    0.898617] usb usb2: Manufacturer: Linux 3.16.0-xenomai-3.0.0 xhci_hcd
> > [    0.914114] usb usb3: Manufacturer: Linux 3.16.0-xenomai-3.0.0 ehci_hcd
> > [    0.930109] usb usb4: Manufacturer: Linux 3.16.0-xenomai-3.0.0 ehci_hcd
> > *** RTnet for Xenomai v3.0-rc2 ***
> > 
> > 
> > So, can avoid to pass the noapic parameter to the kernel to boot?
> 
> Please post the full boot logs, and the kernel configuration. 

Attached.


> Does the
> kernel work with exactly the same .config but without Xenomai? 

I don't know. It's a similar kernel configuration than debian ships with 
jessie.

> Is
> CONFIG_SMP enabled? Because if CONFIG_SMP is enabled, Xenomai will
> not work without an APIC.

Yes, CONFIG_SMP=y and CONFIG_X86_IO_APIC=y

> Also, please do not compile RTnet in the kernel, compile it as a module.

it's as module. I saw that you said that it couldn't be integrated because it 
doesn't boot.

Leopold

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kern.log
Type: text/x-log
Size: 74984 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150122/45c16506/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config-xenomai-3.0.0
Type: text/x-mpsub
Size: 157637 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150122/45c16506/attachment-0001.bin>

Re: [Xenomai] Xenomai-3 booting problems

[Leopold Palomo-Avellaneda]

El Dijous, 22 de gener de 2015, a les 09:03:42, Jan Kiszka va escriure:
> On 2015-01-22 08:47, Leopold Palomo-Avellaneda wrote:
> > Hi,
> > 
> > 
> > I have compiling a Cobalt kernel. I have followed the web "wikipress"
> > [1];-) recommendations. However, my box (a normal desktop computer - Dell
> > Optiplex 7010 -) doesn't boot. It throws a message like:
> > ....
> > timer doesn't work through interrup-remapped IO-apic
> 
> Sounds like interrupt remapping is enabled for your system. That's not
> supported by Xenomai / I-pipe so far (on my to-do list, along with
> x2APIC support). Disable this via "intel_iommu=off intremap=off" in the
> kernel command line or by changing the kernel config to not include
> IOMMU / interrupt remapping support.

I have this options:

$ grep IOMMU config-xenomai-3.0.0 
CONFIG_GART_IOMMU=y
CONFIG_CALGARY_IOMMU=y
CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y
CONFIG_IOMMU_HELPER=y
CONFIG_VFIO_IOMMU_TYPE1=m
CONFIG_IOMMU_API=y
CONFIG_IOMMU_SUPPORT=y
CONFIG_AMD_IOMMU=y
# CONFIG_AMD_IOMMU_STATS is not set
CONFIG_AMD_IOMMU_V2=y
CONFIG_INTEL_IOMMU=y
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
CONFIG_INTEL_IOMMU_FLOPPY_WA=y
# CONFIG_IOMMU_DEBUG is not set
# CONFIG_IOMMU_STRESS is not set


Leopold

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150122/3a615bf7/attachment.sig>

Re: [Xenomai] Xenomai-3 booting problems

[Gilles Chanteperdrix]

On Thu, Jan 22, 2015 at 09:34:11AM +0100, Leopold Palomo-Avellaneda wrote:
> El Dijous, 22 de gener de 2015, a les 08:54:29, Gilles Chanteperdrix va 
> escriure:
> > On Thu, Jan 22, 2015 at 08:47:24AM +0100, Leopold Palomo-Avellaneda wrote:
> > > Hi,
> > > 
> > > 
> > > I have compiling a Cobalt kernel. I have followed the web "wikipress"
> > > [1];-) recommendations. However, my box (a normal desktop computer - Dell
> > > Optiplex 7010 -) doesn't boot. It throws a message like:
> > > ....
> > > timer doesn't work through interrup-remapped IO-apic
> > > 
> > > ...
> > > 
> > > enabling noapic in the boot options I'm able to boot. But, I have not make
> > > any test by now. Some interesting messages:
> > > 
> > > $ dmesg | grep -i xenomai
> > > [    0.000000] Linux version 3.16.0-xenomai-3.0.0 (root@soho) (gcc version
> > > 4.9.1 (Debian 4.9.1-19) ) #1 SMP Wed Jan 21 16:29:36 UTC 2015
> > > [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-xenomai-3.0.0
> > > root=UUID=15cfac82-1127-421f-9aed-eaf48247ed4e ro quiet noapic
> > > [    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-
> > > xenomai-3.0.0 root=UUID=15cfac82-1127-421f-9aed-eaf48247ed4e ro quiet
> > > noapic [    0.705071] [Xenomai] scheduling class idle registered.
> > > [    0.705072] [Xenomai] scheduling class rt registered.
> > > [    0.705090] [Xenomai] disabling automatic C1E state promotion on Intel
> > > processor
> > > [    0.705104] [Xenomai] SMI-enabled chipset found, but SMI workaround
> > > disabled
> > > 
> > >           (see xenomai.smi parameter). You might encounter
> > > 
> > > [    0.705284] I-pipe: head domain Xenomai registered.
> > > [    0.717986] [Xenomai] Cobalt v3.0-rc2 (Exact Zero) [DEBUG]
> > > [    0.897726] usb usb1: Manufacturer: Linux 3.16.0-xenomai-3.0.0 xhci_hcd
> > > [    0.898617] usb usb2: Manufacturer: Linux 3.16.0-xenomai-3.0.0 xhci_hcd
> > > [    0.914114] usb usb3: Manufacturer: Linux 3.16.0-xenomai-3.0.0 ehci_hcd
> > > [    0.930109] usb usb4: Manufacturer: Linux 3.16.0-xenomai-3.0.0 ehci_hcd
> > > *** RTnet for Xenomai v3.0-rc2 ***
> > > 
> > > 
> > > So, can avoid to pass the noapic parameter to the kernel to boot?
> > 
> > Please post the full boot logs, and the kernel configuration. 
> 
> Attached.
> 
> 
> > Does the
> > kernel work with exactly the same .config but without Xenomai? 
> 
> I don't know. It's a similar kernel configuration than debian ships with 
> jessie.

Ok. If you have compiled Xenomai 2.6 git with Linux 3.16.0, why do
you not use the same configuration ?

What about the ARCH problem with make-kpkg, is it solved ?

-- 
					    Gilles.

Re: [Xenomai] Xenomai-3 booting problems

[Leopold Palomo-Avellaneda]

El Dijous, 22 de gener de 2015, a les 09:57:01, Gilles Chanteperdrix va 
escriure:
> On Thu, Jan 22, 2015 at 09:34:11AM +0100, Leopold Palomo-Avellaneda wrote:
> > El Dijous, 22 de gener de 2015, a les 08:54:29, Gilles Chanteperdrix va
> > 
> > escriure:
> > > On Thu, Jan 22, 2015 at 08:47:24AM +0100, Leopold Palomo-Avellaneda 
wrote:
> > > > Hi,
> > > > 
> > > > 
> > > > I have compiling a Cobalt kernel. I have followed the web "wikipress"
> > > > [1];-) recommendations. However, my box (a normal desktop computer -
> > > > Dell
> > > > Optiplex 7010 -) doesn't boot. It throws a message like:
> > > > ....
> > > > timer doesn't work through interrup-remapped IO-apic
> > > > 
> > > > ...
> > > > 
> > > > enabling noapic in the boot options I'm able to boot. But, I have not
> > > > make
> > > > any test by now. Some interesting messages:
> > > > 
> > > > $ dmesg | grep -i xenomai
> > > > [    0.000000] Linux version 3.16.0-xenomai-3.0.0 (root@soho) (gcc
> > > > version
> > > > 4.9.1 (Debian 4.9.1-19) ) #1 SMP Wed Jan 21 16:29:36 UTC 2015
> > > > [    0.000000] Command line:
> > > > BOOT_IMAGE=/boot/vmlinuz-3.16.0-xenomai-3.0.0
> > > > root=UUID=15cfac82-1127-421f-9aed-eaf48247ed4e ro quiet noapic
> > > > [    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-
> > > > xenomai-3.0.0 root=UUID=15cfac82-1127-421f-9aed-eaf48247ed4e ro quiet
> > > > noapic [    0.705071] [Xenomai] scheduling class idle registered.
> > > > [    0.705072] [Xenomai] scheduling class rt registered.
> > > > [    0.705090] [Xenomai] disabling automatic C1E state promotion on
> > > > Intel
> > > > processor
> > > > [    0.705104] [Xenomai] SMI-enabled chipset found, but SMI workaround
> > > > disabled
> > > > 
> > > >           (see xenomai.smi parameter). You might encounter
> > > > 
> > > > [    0.705284] I-pipe: head domain Xenomai registered.
> > > > [    0.717986] [Xenomai] Cobalt v3.0-rc2 (Exact Zero) [DEBUG]
> > > > [    0.897726] usb usb1: Manufacturer: Linux 3.16.0-xenomai-3.0.0
> > > > xhci_hcd
> > > > [    0.898617] usb usb2: Manufacturer: Linux 3.16.0-xenomai-3.0.0
> > > > xhci_hcd
> > > > [    0.914114] usb usb3: Manufacturer: Linux 3.16.0-xenomai-3.0.0
> > > > ehci_hcd
> > > > [    0.930109] usb usb4: Manufacturer: Linux 3.16.0-xenomai-3.0.0
> > > > ehci_hcd
> > > > *** RTnet for Xenomai v3.0-rc2 ***
> > > > 
> > > > 
> > > > So, can avoid to pass the noapic parameter to the kernel to boot?
> > > 
> > > Please post the full boot logs, and the kernel configuration.
> > 
> > Attached.
> > 
> > > Does the
> > > kernel work with exactly the same .config but without Xenomai?
> > 
> > I don't know. It's a similar kernel configuration than debian ships with
> > jessie.
> 
> Ok. If you have compiled Xenomai 2.6 git with Linux 3.16.0, why do
> you not use the same configuration ?

I used the same file. I attached the 2.6.4 config. However, there's some small 
differences. For instance, IPIPE_LEGACY is disabled in xenomai-3, not in 2.
 
> What about the ARCH problem with make-kpkg, is it solved ?

As I said yesterday [1], there's a question of the ARCH var, used in the 
prepare-kernel script.

Any idea to solve this?

Leopold

-- 

[1] http://www.xenomai.org/pipermail/xenomai/2015-January/032958.html
-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config-xenomai-2.6.4
Type: text/x-mpsub
Size: 157499 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150122/ffc3c88c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150122/ffc3c88c/attachment.sig>

Re: [Xenomai] Xenomai-3 booting problems

[Gilles Chanteperdrix]

On Thu, Jan 22, 2015 at 10:52:31AM +0100, Leopold Palomo-Avellaneda wrote:
> El Dijous, 22 de gener de 2015, a les 09:57:01, Gilles Chanteperdrix va 
> escriure:
> > On Thu, Jan 22, 2015 at 09:34:11AM +0100, Leopold Palomo-Avellaneda wrote:
> > > El Dijous, 22 de gener de 2015, a les 08:54:29, Gilles Chanteperdrix va
> > > 
> > > escriure:
> > > > On Thu, Jan 22, 2015 at 08:47:24AM +0100, Leopold Palomo-Avellaneda 
> wrote:
> > > > > Hi,
> > > > > 
> > > > > 
> > > > > I have compiling a Cobalt kernel. I have followed the web "wikipress"
> > > > > [1];-) recommendations. However, my box (a normal desktop computer -
> > > > > Dell
> > > > > Optiplex 7010 -) doesn't boot. It throws a message like:
> > > > > ....
> > > > > timer doesn't work through interrup-remapped IO-apic
> > > > > 
> > > > > ...
> > > > > 
> > > > > enabling noapic in the boot options I'm able to boot. But, I have not
> > > > > make
> > > > > any test by now. Some interesting messages:
> > > > > 
> > > > > $ dmesg | grep -i xenomai
> > > > > [    0.000000] Linux version 3.16.0-xenomai-3.0.0 (root@soho) (gcc
> > > > > version
> > > > > 4.9.1 (Debian 4.9.1-19) ) #1 SMP Wed Jan 21 16:29:36 UTC 2015
> > > > > [    0.000000] Command line:
> > > > > BOOT_IMAGE=/boot/vmlinuz-3.16.0-xenomai-3.0.0
> > > > > root=UUID=15cfac82-1127-421f-9aed-eaf48247ed4e ro quiet noapic
> > > > > [    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-
> > > > > xenomai-3.0.0 root=UUID=15cfac82-1127-421f-9aed-eaf48247ed4e ro quiet
> > > > > noapic [    0.705071] [Xenomai] scheduling class idle registered.
> > > > > [    0.705072] [Xenomai] scheduling class rt registered.
> > > > > [    0.705090] [Xenomai] disabling automatic C1E state promotion on
> > > > > Intel
> > > > > processor
> > > > > [    0.705104] [Xenomai] SMI-enabled chipset found, but SMI workaround
> > > > > disabled
> > > > > 
> > > > >           (see xenomai.smi parameter). You might encounter
> > > > > 
> > > > > [    0.705284] I-pipe: head domain Xenomai registered.
> > > > > [    0.717986] [Xenomai] Cobalt v3.0-rc2 (Exact Zero) [DEBUG]
> > > > > [    0.897726] usb usb1: Manufacturer: Linux 3.16.0-xenomai-3.0.0
> > > > > xhci_hcd
> > > > > [    0.898617] usb usb2: Manufacturer: Linux 3.16.0-xenomai-3.0.0
> > > > > xhci_hcd
> > > > > [    0.914114] usb usb3: Manufacturer: Linux 3.16.0-xenomai-3.0.0
> > > > > ehci_hcd
> > > > > [    0.930109] usb usb4: Manufacturer: Linux 3.16.0-xenomai-3.0.0
> > > > > ehci_hcd
> > > > > *** RTnet for Xenomai v3.0-rc2 ***
> > > > > 
> > > > > 
> > > > > So, can avoid to pass the noapic parameter to the kernel to boot?
> > > > 
> > > > Please post the full boot logs, and the kernel configuration.
> > > 
> > > Attached.
> > > 
> > > > Does the
> > > > kernel work with exactly the same .config but without Xenomai?
> > > 
> > > I don't know. It's a similar kernel configuration than debian ships with
> > > jessie.
> > 
> > Ok. If you have compiled Xenomai 2.6 git with Linux 3.16.0, why do
> > you not use the same configuration ?
> 
> I used the same file. I attached the 2.6.4 config. However, there's some small 
> differences. For instance, IPIPE_LEGACY is disabled in xenomai-3, not in 2.
>  
> > What about the ARCH problem with make-kpkg, is it solved ?
> 
> As I said yesterday [1], there's a question of the ARCH var, used in the 
> prepare-kernel script.

No, yesterday you said that the prepare-kernel script probably was
not the problem because you can compile the prepared kernel
manually. Or did I misunderstand?

> 
> Any idea to solve this?

As I already said, you have to execute what make-kpkg does, by hand,
step by step, to understand which step goes wrong.

-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150122/487368b1/attachment.sig>

Re: [Xenomai] Xenomai-3 booting problems

[Leopold Palomo-Avellaneda]

El Dijous, 22 de gener de 2015, a les 10:56:35, Gilles Chanteperdrix va 
escriure:
> > > What about the ARCH problem with make-kpkg, is it solved ?
> > 
> > As I said yesterday [1], there's a question of the ARCH var, used in the
> > prepare-kernel script.
> 
> No, yesterday you said that the prepare-kernel script probably was
> not the problem 

I said a lot of things yesterday :-D and yes, I thought that probably it 
wasn't.

> because you can compile the prepared kernel
> manually. Or did I misunderstand?

Yes, it's true. I can compile the kernel manually but I can create the debian 
package if I modify the result obtained by the prepare-kernel script.

> > Any idea to solve this?
> 
> As I already said, you have to execute what make-kpkg does, by hand,
> step by step, to understand which step goes wrong.

:-D 

It's no easy, at least by my, check why make-kpkg does. But, I think that 
there's a collision with that var (ARCH). I think that debian use that var for 
some internal proposes and it's different (in the x86 platform x86 vs x86_64), 
or has some troubles.

Really I don't know if it's a mix of prepare-kernel problem, make-kpkg problem 
or user problem.

If you see clearly that it's make-kpkg problem, I concentrate my efforts on 
that. 

Leopold




-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150122/350591d3/attachment.sig>

Re: [Xenomai] Xenomai-3 booting problems

[Gilles Chanteperdrix]

On Thu, Jan 22, 2015 at 11:17:41AM +0100, Leopold Palomo-Avellaneda wrote:
> El Dijous, 22 de gener de 2015, a les 10:56:35, Gilles Chanteperdrix va 
> escriure:
> > > > What about the ARCH problem with make-kpkg, is it solved ?
> > > 
> > > As I said yesterday [1], there's a question of the ARCH var, used in the
> > > prepare-kernel script.
> > 
> > No, yesterday you said that the prepare-kernel script probably was
> > not the problem 
> 
> I said a lot of things yesterday :-D and yes, I thought that probably it 
> wasn't.
> 
> > because you can compile the prepared kernel
> > manually. Or did I misunderstand?
> 
> Yes, it's true. I can compile the kernel manually but I can create the debian 
> package if I modify the result obtained by the prepare-kernel script.
> 
> > > Any idea to solve this?
> > 
> > As I already said, you have to execute what make-kpkg does, by hand,
> > step by step, to understand which step goes wrong.
> 
> :-D 
> 
> It's no easy, at least by my, check why make-kpkg does. But, I think that 
> there's a collision with that var (ARCH). I think that debian use that var for 
> some internal proposes and it's different (in the x86 platform x86 vs x86_64), 
> or has some troubles.
> 
> Really I don't know if it's a mix of prepare-kernel problem, make-kpkg problem 
> or user problem.

As you said, if you can compile the prepared kernel manually, it is
not a prepare-kernel problem.

> 
> If you see clearly that it's make-kpkg problem, I concentrate my efforts on 
> that. 

Well, the fact that the compilation error happens when trying to
compile a Xenomai file would seem to indicate that prepare-kernel.sh
has put the wrong link into init/Kconfig.

You pass --arch=x86 to prepare-kernel.sh, right, not --arch=x86_64 ?


-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150122/0f2d63d7/attachment.sig>

Re: [Xenomai] Xenomai-3 booting problems

[Leopold Palomo-Avellaneda]

El Dijous, 22 de gener de 2015, a les 11:24:55, Gilles Chanteperdrix va 
escriure:
> On Thu, Jan 22, 2015 at 11:17:41AM +0100, Leopold Palomo-Avellaneda wrote:
> > El Dijous, 22 de gener de 2015, a les 10:56:35, Gilles Chanteperdrix va
> > 
> > escriure:
> > > > > What about the ARCH problem with make-kpkg, is it solved ?
> > > > 
> > > > As I said yesterday [1], there's a question of the ARCH var, used in
> > > > the
> > > > prepare-kernel script.
> > > 
> > > No, yesterday you said that the prepare-kernel script probably was
> > > not the problem
> > 
> > I said a lot of things yesterday :-D and yes, I thought that probably it
> > wasn't.
> > 
> > > because you can compile the prepared kernel
> > > manually. Or did I misunderstand?
> > 
> > Yes, it's true. I can compile the kernel manually but I can create the
> > debian package if I modify the result obtained by the prepare-kernel
> > script.> 
> > > > Any idea to solve this?
> > > 
> > > As I already said, you have to execute what make-kpkg does, by hand,
> > > step by step, to understand which step goes wrong.
> > :
> > :-D
> > 
> > It's no easy, at least by my, check why make-kpkg does. But, I think that
> > there's a collision with that var (ARCH). I think that debian use that var
> > for some internal proposes and it's different (in the x86 platform x86 vs
> > x86_64), or has some troubles.
> > 
> > Really I don't know if it's a mix of prepare-kernel problem, make-kpkg
> > problem or user problem.
> 
> As you said, if you can compile the prepared kernel manually, it is
> not a prepare-kernel problem.
> 
> > If you see clearly that it's make-kpkg problem, I concentrate my efforts
> > on
> > that.
> 
> Well, the fact that the compilation error happens when trying to
> compile a Xenomai file would seem to indicate that prepare-kernel.sh
> has put the wrong link into init/Kconfig.
> 
> You pass --arch=x86 to prepare-kernel.sh, right, not --arch=x86_64 ?

yes, I have tried both, but I put --arch=x86 or the default option as I said 
it in my email from yesterday ( :-P)

Seriously, now I have compiled manually the kernel (make bzImage modules) and 
no error, but after the compilation on interested directory have appeared in 
arch dir: 
ls -l arch/x86_64/boot/bzImage 
lrwxrwxrwx 1 root root 22 gen 22 10:32 arch/x86_64/boot/bzImage -> 
../../x86/boot/bzImage

Maybe it's something related to debian.

Leopold
-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150122/b6ee5ece/attachment.sig>

Re: [Xenomai] Xenomai-3 booting problems

[Gilles Chanteperdrix]

On Thu, Jan 22, 2015 at 11:40:57AM +0100, Leopold Palomo-Avellaneda wrote:
> El Dijous, 22 de gener de 2015, a les 11:24:55, Gilles Chanteperdrix va 
> escriure:
> > On Thu, Jan 22, 2015 at 11:17:41AM +0100, Leopold Palomo-Avellaneda wrote:
> > > El Dijous, 22 de gener de 2015, a les 10:56:35, Gilles Chanteperdrix va
> > > 
> > > escriure:
> > > > > > What about the ARCH problem with make-kpkg, is it solved ?
> > > > > 
> > > > > As I said yesterday [1], there's a question of the ARCH var, used in
> > > > > the
> > > > > prepare-kernel script.
> > > > 
> > > > No, yesterday you said that the prepare-kernel script probably was
> > > > not the problem
> > > 
> > > I said a lot of things yesterday :-D and yes, I thought that probably it
> > > wasn't.
> > > 
> > > > because you can compile the prepared kernel
> > > > manually. Or did I misunderstand?
> > > 
> > > Yes, it's true. I can compile the kernel manually but I can create the
> > > debian package if I modify the result obtained by the prepare-kernel
> > > script.> 
> > > > > Any idea to solve this?
> > > > 
> > > > As I already said, you have to execute what make-kpkg does, by hand,
> > > > step by step, to understand which step goes wrong.
> > > :
> > > :-D
> > > 
> > > It's no easy, at least by my, check why make-kpkg does. But, I think that
> > > there's a collision with that var (ARCH). I think that debian use that var
> > > for some internal proposes and it's different (in the x86 platform x86 vs
> > > x86_64), or has some troubles.
> > > 
> > > Really I don't know if it's a mix of prepare-kernel problem, make-kpkg
> > > problem or user problem.
> > 
> > As you said, if you can compile the prepared kernel manually, it is
> > not a prepare-kernel problem.
> > 
> > > If you see clearly that it's make-kpkg problem, I concentrate my efforts
> > > on
> > > that.
> > 
> > Well, the fact that the compilation error happens when trying to
> > compile a Xenomai file would seem to indicate that prepare-kernel.sh
> > has put the wrong link into init/Kconfig.
> > 
> > You pass --arch=x86 to prepare-kernel.sh, right, not --arch=x86_64 ?
> 
> yes, I have tried both, but I put --arch=x86 or the default option as I said 
> it in my email from yesterday ( :-P)

Well, maybe the default option does not work, so please try
specifying --arch=x86. The error you have is not in the compiled
files, but in the Kconfig files. So, the fact that you can compile
does not really prove that prepare-kernel.sh did not fail.

Now, prepare-kernel.sh adds the scripts/Kconfig.frag file to
init/Kconfig. Kconfig.frag contains:

source "arch/@LINUX_ARCH@/xenomai/Kconfig"

With @LINUX_ARCH@ being substituted by prepare-kernel.sh. Could you
check init/Kconfig to see by what @LINUX_ARCH@ has been substituted
in your case?

If it is x86_64, then it is clearly wrong. It should be x86.

-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150122/c8a05a43/attachment.sig>

[Xenomai] Xenomai-3 creating debian packages (was: Re: Xenomai-3 booting problems)

[Leopold Palomo-Avellaneda]

I have renamed the subject according with the theme.

El Dijous, 22 de gener de 2015, a les 11:48:13, Gilles Chanteperdrix va 
escriure:
> > > 
> > > Well, the fact that the compilation error happens when trying to
> > > compile a Xenomai file would seem to indicate that prepare-kernel.sh
> > > has put the wrong link into init/Kconfig.
> > > 
> > > You pass --arch=x86 to prepare-kernel.sh, right, not --arch=x86_64 ?
> > 
> > yes, I have tried both, but I put --arch=x86 or the default option as I
> > said it in my email from yesterday ( :-P)
> 
> Well, maybe the default option does not work, so please try
> specifying --arch=x86. The error you have is not in the compiled
> files, but in the Kconfig files. So, the fact that you can compile
> does not really prove that prepare-kernel.sh did not fail.

Ok, from a clean sources I have run from the linux tree sources:

$ ../xenomai-3.git/scripts/prepare-kernel.sh --linux=. --
ipipe=../xenomai-3.git/kernel/cobalt/arch/x86/patches/ipipe-core-3.16-
x86-1.patch --arch=x86 
 
> Now, prepare-kernel.sh adds the scripts/Kconfig.frag file to
> init/Kconfig. Kconfig.frag contains:

I don't understand that sentence. Yes, the  Kconfig.frag now, contains this:

source "arch/$ARCH/xenomai/Kconfig"

I have changed it in xenomai sources, before run the prepare-kernel el script 
to your propose:

> source "arch/@LINUX_ARCH@/xenomai/Kconfig"
> 
> With @LINUX_ARCH@ being substituted by prepare-kernel.sh. Could you
> check init/Kconfig to see by what @LINUX_ARCH@ has been substituted
> in your case?


but, after run the prepare-kernel script, the var still has, in linux tree

source "arch/@LINUX_ARCH@/xenomai/Kconfig"

> If it is x86_64, then it is clearly wrong. It should be x86.

Was it what did you want I tested?

Leopold
-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150122/2aee0c23/attachment.sig>

Re: [Xenomai] Xenomai-3 creating debian packages (was: Re: Xenomai-3 booting problems)

[Gilles Chanteperdrix]

On Thu, Jan 22, 2015 at 12:17:15PM +0100, Leopold Palomo-Avellaneda wrote:
> I have renamed the subject according with the theme.
> 
> El Dijous, 22 de gener de 2015, a les 11:48:13, Gilles Chanteperdrix va 
> escriure:
> > > > 
> > > > Well, the fact that the compilation error happens when trying to
> > > > compile a Xenomai file would seem to indicate that prepare-kernel.sh
> > > > has put the wrong link into init/Kconfig.
> > > > 
> > > > You pass --arch=x86 to prepare-kernel.sh, right, not --arch=x86_64 ?
> > > 
> > > yes, I have tried both, but I put --arch=x86 or the default option as I
> > > said it in my email from yesterday ( :-P)
> > 
> > Well, maybe the default option does not work, so please try
> > specifying --arch=x86. The error you have is not in the compiled
> > files, but in the Kconfig files. So, the fact that you can compile
> > does not really prove that prepare-kernel.sh did not fail.
> 
> Ok, from a clean sources I have run from the linux tree sources:
> 
> $ ../xenomai-3.git/scripts/prepare-kernel.sh --linux=. --
> ipipe=../xenomai-3.git/kernel/cobalt/arch/x86/patches/ipipe-core-3.16-
> x86-1.patch --arch=x86 
>  
> > Now, prepare-kernel.sh adds the scripts/Kconfig.frag file to
> > init/Kconfig. Kconfig.frag contains:
> 
> I don't understand that sentence. Yes, the  Kconfig.frag now, contains this:
> 
> source "arch/$ARCH/xenomai/Kconfig"

Ah OK. Could you try to revert that commit ?

http://git.xenomai.org/xenomai-3.git/commit/scripts/Kconfig.frag?h=next&id=26cc64313e2e695ac227e5a02992c5fe72df2e5f


-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150122/4f17a4cf/attachment.sig>

Re: [Xenomai] Xenomai-3 creating debian packages (was: Re: Xenomai-3 booting problems)

[Leopold Palomo-Avellaneda]

El Dijous, 22 de gener de 2015, a les 12:31:05, Gilles Chanteperdrix va 
escriure:
> On Thu, Jan 22, 2015 at 12:17:15PM +0100, Leopold Palomo-Avellaneda wrote:
> > I have renamed the subject according with the theme.
> > 
> > El Dijous, 22 de gener de 2015, a les 11:48:13, Gilles Chanteperdrix va
> > 
> > escriure:
> > > > > Well, the fact that the compilation error happens when trying to
> > > > > compile a Xenomai file would seem to indicate that prepare-kernel.sh
> > > > > has put the wrong link into init/Kconfig.
> > > > > 
> > > > > You pass --arch=x86 to prepare-kernel.sh, right, not --arch=x86_64 ?
> > > > 
> > > > yes, I have tried both, but I put --arch=x86 or the default option as
> > > > I
> > > > said it in my email from yesterday ( :-P)
> > > 
> > > Well, maybe the default option does not work, so please try
> > > specifying --arch=x86. The error you have is not in the compiled
> > > files, but in the Kconfig files. So, the fact that you can compile
> > > does not really prove that prepare-kernel.sh did not fail.
> > 
> > Ok, from a clean sources I have run from the linux tree sources:
> > 
> > $ ../xenomai-3.git/scripts/prepare-kernel.sh --linux=. --
> > ipipe=../xenomai-3.git/kernel/cobalt/arch/x86/patches/ipipe-core-3.16-
> > x86-1.patch --arch=x86
> > 
> > > Now, prepare-kernel.sh adds the scripts/Kconfig.frag file to
> > 
> > > init/Kconfig. Kconfig.frag contains:
> > I don't understand that sentence. Yes, the  Kconfig.frag now, contains
> > this:
> > 
> > source "arch/$ARCH/xenomai/Kconfig"
> 
> Ah OK. Could you try to revert that commit ?
> 
> http://git.xenomai.org/xenomai-3.git/commit/scripts/Kconfig.frag?h=next&id=2
> 6cc64313e2e695ac227e5a02992c5fe72df2e5f

Gilles, I did it. I explained it before. As I just run the script, I don't run 
any autoconf, so, I then have this part as @LINUX_ARCH@ so it doesn't work.

prepare-kernel script doesn't touch (substitute) that.

Leopold

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150122/5f14f1d1/attachment.sig>

Re: [Xenomai] Xenomai-3 creating debian packages (was: Re: Xenomai-3 booting problems)

[Gilles Chanteperdrix]

On Thu, Jan 22, 2015 at 12:31:05PM +0100, Gilles Chanteperdrix wrote:
> On Thu, Jan 22, 2015 at 12:17:15PM +0100, Leopold Palomo-Avellaneda wrote:
> > I have renamed the subject according with the theme.
> > 
> > El Dijous, 22 de gener de 2015, a les 11:48:13, Gilles Chanteperdrix va 
> > escriure:
> > > > > 
> > > > > Well, the fact that the compilation error happens when trying to
> > > > > compile a Xenomai file would seem to indicate that prepare-kernel.sh
> > > > > has put the wrong link into init/Kconfig.
> > > > > 
> > > > > You pass --arch=x86 to prepare-kernel.sh, right, not --arch=x86_64 ?
> > > > 
> > > > yes, I have tried both, but I put --arch=x86 or the default option as I
> > > > said it in my email from yesterday ( :-P)
> > > 
> > > Well, maybe the default option does not work, so please try
> > > specifying --arch=x86. The error you have is not in the compiled
> > > files, but in the Kconfig files. So, the fact that you can compile
> > > does not really prove that prepare-kernel.sh did not fail.
> > 
> > Ok, from a clean sources I have run from the linux tree sources:
> > 
> > $ ../xenomai-3.git/scripts/prepare-kernel.sh --linux=. --
> > ipipe=../xenomai-3.git/kernel/cobalt/arch/x86/patches/ipipe-core-3.16-
> > x86-1.patch --arch=x86 
> >  
> > > Now, prepare-kernel.sh adds the scripts/Kconfig.frag file to
> > > init/Kconfig. Kconfig.frag contains:
> > 
> > I don't understand that sentence. Yes, the  Kconfig.frag now, contains this:
> > 
> > source "arch/$ARCH/xenomai/Kconfig"
> 
> Ah OK. Could you try to revert that commit ?
> 
> http://git.xenomai.org/xenomai-3.git/commit/scripts/Kconfig.frag?h=next&id=26cc64313e2e695ac227e5a02992c5fe72df2e5f

You need to revert the whole commit, not just the change in
Kconfig.frag. The easy way to do this is to go in Xenomai git tree
and type:

git revert 26cc64313e2e695ac227e5a02992c5fe72df2e5f

Of course, you need to re-run prepare-kernel.sh after that.

-- 
					    Gilles.

Re: [Xenomai] Xenomai-3 creating debian packages (was: Re: Xenomai-3 booting problems)

[Gilles Chanteperdrix]

On Thu, Jan 22, 2015 at 12:39:10PM +0100, Leopold Palomo-Avellaneda wrote:
> El Dijous, 22 de gener de 2015, a les 12:31:05, Gilles Chanteperdrix va 
> escriure:
> > On Thu, Jan 22, 2015 at 12:17:15PM +0100, Leopold Palomo-Avellaneda wrote:
> > > I have renamed the subject according with the theme.
> > > 
> > > El Dijous, 22 de gener de 2015, a les 11:48:13, Gilles Chanteperdrix va
> > > 
> > > escriure:
> > > > > > Well, the fact that the compilation error happens when trying to
> > > > > > compile a Xenomai file would seem to indicate that prepare-kernel.sh
> > > > > > has put the wrong link into init/Kconfig.
> > > > > > 
> > > > > > You pass --arch=x86 to prepare-kernel.sh, right, not --arch=x86_64 ?
> > > > > 
> > > > > yes, I have tried both, but I put --arch=x86 or the default option as
> > > > > I
> > > > > said it in my email from yesterday ( :-P)
> > > > 
> > > > Well, maybe the default option does not work, so please try
> > > > specifying --arch=x86. The error you have is not in the compiled
> > > > files, but in the Kconfig files. So, the fact that you can compile
> > > > does not really prove that prepare-kernel.sh did not fail.
> > > 
> > > Ok, from a clean sources I have run from the linux tree sources:
> > > 
> > > $ ../xenomai-3.git/scripts/prepare-kernel.sh --linux=. --
> > > ipipe=../xenomai-3.git/kernel/cobalt/arch/x86/patches/ipipe-core-3.16-
> > > x86-1.patch --arch=x86
> > > 
> > > > Now, prepare-kernel.sh adds the scripts/Kconfig.frag file to
> > > 
> > > > init/Kconfig. Kconfig.frag contains:
> > > I don't understand that sentence. Yes, the  Kconfig.frag now, contains
> > > this:
> > > 
> > > source "arch/$ARCH/xenomai/Kconfig"
> > 
> > Ah OK. Could you try to revert that commit ?
> > 
> > http://git.xenomai.org/xenomai-3.git/commit/scripts/Kconfig.frag?h=next&id=2
> > 6cc64313e2e695ac227e5a02992c5fe72df2e5f
> 
> Gilles, I did it. I explained it before. As I just run the script, I don't run 
> any autoconf, so, I then have this part as @LINUX_ARCH@ so it doesn't work.
> 
> prepare-kernel script doesn't touch (substitute) that.

prepare-kernel.sh before that commit substitutes @LINUX_ARCH@. You
just need to revert the whole commit.


-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150122/c66d63bb/attachment.sig>

Re: [Xenomai] Xenomai-3 creating debian packages

[Jan Kiszka]

On 2015-01-22 12:31, Gilles Chanteperdrix wrote:
> On Thu, Jan 22, 2015 at 12:17:15PM +0100, Leopold Palomo-Avellaneda wrote:
>> I have renamed the subject according with the theme.
>>
>> El Dijous, 22 de gener de 2015, a les 11:48:13, Gilles Chanteperdrix va 
>> escriure:
>>>>>
>>>>> Well, the fact that the compilation error happens when trying to
>>>>> compile a Xenomai file would seem to indicate that prepare-kernel.sh
>>>>> has put the wrong link into init/Kconfig.
>>>>>
>>>>> You pass --arch=x86 to prepare-kernel.sh, right, not --arch=x86_64 ?
>>>>
>>>> yes, I have tried both, but I put --arch=x86 or the default option as I
>>>> said it in my email from yesterday ( :-P)
>>>
>>> Well, maybe the default option does not work, so please try
>>> specifying --arch=x86. The error you have is not in the compiled
>>> files, but in the Kconfig files. So, the fact that you can compile
>>> does not really prove that prepare-kernel.sh did not fail.
>>
>> Ok, from a clean sources I have run from the linux tree sources:
>>
>> $ ../xenomai-3.git/scripts/prepare-kernel.sh --linux=. --
>> ipipe=../xenomai-3.git/kernel/cobalt/arch/x86/patches/ipipe-core-3.16-
>> x86-1.patch --arch=x86 
>>  
>>> Now, prepare-kernel.sh adds the scripts/Kconfig.frag file to
>>> init/Kconfig. Kconfig.frag contains:
>>
>> I don't understand that sentence. Yes, the  Kconfig.frag now, contains this:
>>
>> source "arch/$ARCH/xenomai/Kconfig"
> 
> Ah OK. Could you try to revert that commit ?
> 
> http://git.xenomai.org/xenomai-3.git/commit/scripts/Kconfig.frag?h=next&id=26cc64313e2e695ac227e5a02992c5fe72df2e5f

Better directly replace $ARCH with $SRCARCH. That should fix my patch
(which was tested only on x86-64 build systems that do not set ARCH).

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Xenomai-3 creating debian packages (was: Re: Xenomai-3 booting problems)

[Leopold Palomo-Avellaneda]

El Dijous, 22 de gener de 2015, a les 12:40:38, Gilles Chanteperdrix va 
escriure:
> On Thu, Jan 22, 2015 at 12:39:10PM +0100, Leopold Palomo-Avellaneda wrote:
> > El Dijous, 22 de gener de 2015, a les 12:31:05, Gilles Chanteperdrix va
> > 
> > escriure:
> > > On Thu, Jan 22, 2015 at 12:17:15PM +0100, Leopold Palomo-Avellaneda 
wrote:
> > > > I have renamed the subject according with the theme.
> > > > 
> > > > El Dijous, 22 de gener de 2015, a les 11:48:13, Gilles Chanteperdrix
> > > > va
> > > > 
> > > > escriure:
> > > > > > > Well, the fact that the compilation error happens when trying to
> > > > > > > compile a Xenomai file would seem to indicate that
> > > > > > > prepare-kernel.sh
> > > > > > > has put the wrong link into init/Kconfig.
> > > > > > > 
> > > > > > > You pass --arch=x86 to prepare-kernel.sh, right, not
> > > > > > > --arch=x86_64 ?
> > > > > > 
> > > > > > yes, I have tried both, but I put --arch=x86 or the default option
> > > > > > as
> > > > > > I
> > > > > > said it in my email from yesterday ( :-P)
> > > > > 
> > > > > Well, maybe the default option does not work, so please try
> > > > > specifying --arch=x86. The error you have is not in the compiled
> > > > > files, but in the Kconfig files. So, the fact that you can compile
> > > > > does not really prove that prepare-kernel.sh did not fail.
> > > > 
> > > > Ok, from a clean sources I have run from the linux tree sources:
> > > > 
> > > > $ ../xenomai-3.git/scripts/prepare-kernel.sh --linux=. --
> > > > ipipe=../xenomai-3.git/kernel/cobalt/arch/x86/patches/ipipe-core-3.16-
> > > > x86-1.patch --arch=x86
> > > > 
> > > > > Now, prepare-kernel.sh adds the scripts/Kconfig.frag file to
> > > > 
> > > > > init/Kconfig. Kconfig.frag contains:
> > > > I don't understand that sentence. Yes, the  Kconfig.frag now, contains
> > > > this:
> > > > 
> > > > source "arch/$ARCH/xenomai/Kconfig"
> > > 
> > > Ah OK. Could you try to revert that commit ?
> > > 
> > > http://git.xenomai.org/xenomai-3.git/commit/scripts/Kconfig.frag?h=next&
> > > id=2 6cc64313e2e695ac227e5a02992c5fe72df2e5f
> > 
> > Gilles, I did it. I explained it before. As I just run the script, I don't
> > run any autoconf, so, I then have this part as @LINUX_ARCH@ so it doesn't
> > work.
> > 
> > prepare-kernel script doesn't touch (substitute) that.
> 
> prepare-kernel.sh before that commit substitutes @LINUX_ARCH@. You
> just need to revert the whole commit.

Ok, the whole commit touch also the prepare-kernel script. I have tested and 
now, I got in linux-tree/init/Kconfig:

if XENOMAI
source "arch/x86/xenomai/Kconfig"
endif

so, I'm sorry Jan, but I think that at least in debian platforms it wasn't a 
good change.

Now, the noapic issue, do you have some idea?

Regards,

Leopold




-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150122/b81c50a3/attachment.sig>

Re: [Xenomai] Xenomai-3 creating debian packages

[Jan Kiszka]

On 2015-01-22 12:59, Leopold Palomo-Avellaneda wrote:
> El Dijous, 22 de gener de 2015, a les 12:40:38, Gilles Chanteperdrix va 
> escriure:
>> On Thu, Jan 22, 2015 at 12:39:10PM +0100, Leopold Palomo-Avellaneda wrote:
>>> El Dijous, 22 de gener de 2015, a les 12:31:05, Gilles Chanteperdrix va
>>>
>>> escriure:
>>>> On Thu, Jan 22, 2015 at 12:17:15PM +0100, Leopold Palomo-Avellaneda 
> wrote:
>>>>> I have renamed the subject according with the theme.
>>>>>
>>>>> El Dijous, 22 de gener de 2015, a les 11:48:13, Gilles Chanteperdrix
>>>>> va
>>>>>
>>>>> escriure:
>>>>>>>> Well, the fact that the compilation error happens when trying to
>>>>>>>> compile a Xenomai file would seem to indicate that
>>>>>>>> prepare-kernel.sh
>>>>>>>> has put the wrong link into init/Kconfig.
>>>>>>>>
>>>>>>>> You pass --arch=x86 to prepare-kernel.sh, right, not
>>>>>>>> --arch=x86_64 ?
>>>>>>>
>>>>>>> yes, I have tried both, but I put --arch=x86 or the default option
>>>>>>> as
>>>>>>> I
>>>>>>> said it in my email from yesterday ( :-P)
>>>>>>
>>>>>> Well, maybe the default option does not work, so please try
>>>>>> specifying --arch=x86. The error you have is not in the compiled
>>>>>> files, but in the Kconfig files. So, the fact that you can compile
>>>>>> does not really prove that prepare-kernel.sh did not fail.
>>>>>
>>>>> Ok, from a clean sources I have run from the linux tree sources:
>>>>>
>>>>> $ ../xenomai-3.git/scripts/prepare-kernel.sh --linux=. --
>>>>> ipipe=../xenomai-3.git/kernel/cobalt/arch/x86/patches/ipipe-core-3.16-
>>>>> x86-1.patch --arch=x86
>>>>>
>>>>>> Now, prepare-kernel.sh adds the scripts/Kconfig.frag file to
>>>>>
>>>>>> init/Kconfig. Kconfig.frag contains:
>>>>> I don't understand that sentence. Yes, the  Kconfig.frag now, contains
>>>>> this:
>>>>>
>>>>> source "arch/$ARCH/xenomai/Kconfig"
>>>>
>>>> Ah OK. Could you try to revert that commit ?
>>>>
>>>> http://git.xenomai.org/xenomai-3.git/commit/scripts/Kconfig.frag?h=next&
>>>> id=2 6cc64313e2e695ac227e5a02992c5fe72df2e5f
>>>
>>> Gilles, I did it. I explained it before. As I just run the script, I don't
>>> run any autoconf, so, I then have this part as @LINUX_ARCH@ so it doesn't
>>> work.
>>>
>>> prepare-kernel script doesn't touch (substitute) that.
>>
>> prepare-kernel.sh before that commit substitutes @LINUX_ARCH@. You
>> just need to revert the whole commit.
> 
> Ok, the whole commit touch also the prepare-kernel script. I have tested and 
> now, I got in linux-tree/init/Kconfig:
> 
> if XENOMAI
> source "arch/x86/xenomai/Kconfig"
> endif
> 
> so, I'm sorry Jan, but I think that at least in debian platforms it wasn't a 
> good change.

See
http://git.xenomai.org/xenomai-jki.git/commit/?h=for-forge&id=5d104b1de84c8f4cbfb9d6b79cfaa633ef550e1c
for the fix. The bug was the improper variable use in the Kconfig
fragment. You only had to revert the whole commit as you were falling
back to the obsolete prepare-time patching then, which involved the script.


> 
> Now, the noapic issue, do you have some idea?

I provided some answers already.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Xenomai-3 creating debian packages

[Gilles Chanteperdrix]

On Thu, Jan 22, 2015 at 01:51:46PM +0100, Jan Kiszka wrote:
> On 2015-01-22 12:59, Leopold Palomo-Avellaneda wrote:
> > El Dijous, 22 de gener de 2015, a les 12:40:38, Gilles Chanteperdrix va 
> > escriure:
> >> On Thu, Jan 22, 2015 at 12:39:10PM +0100, Leopold Palomo-Avellaneda wrote:
> >>> El Dijous, 22 de gener de 2015, a les 12:31:05, Gilles Chanteperdrix va
> >>>
> >>> escriure:
> >>>> On Thu, Jan 22, 2015 at 12:17:15PM +0100, Leopold Palomo-Avellaneda 
> > wrote:
> >>>>> I have renamed the subject according with the theme.
> >>>>>
> >>>>> El Dijous, 22 de gener de 2015, a les 11:48:13, Gilles Chanteperdrix
> >>>>> va
> >>>>>
> >>>>> escriure:
> >>>>>>>> Well, the fact that the compilation error happens when trying to
> >>>>>>>> compile a Xenomai file would seem to indicate that
> >>>>>>>> prepare-kernel.sh
> >>>>>>>> has put the wrong link into init/Kconfig.
> >>>>>>>>
> >>>>>>>> You pass --arch=x86 to prepare-kernel.sh, right, not
> >>>>>>>> --arch=x86_64 ?
> >>>>>>>
> >>>>>>> yes, I have tried both, but I put --arch=x86 or the default option
> >>>>>>> as
> >>>>>>> I
> >>>>>>> said it in my email from yesterday ( :-P)
> >>>>>>
> >>>>>> Well, maybe the default option does not work, so please try
> >>>>>> specifying --arch=x86. The error you have is not in the compiled
> >>>>>> files, but in the Kconfig files. So, the fact that you can compile
> >>>>>> does not really prove that prepare-kernel.sh did not fail.
> >>>>>
> >>>>> Ok, from a clean sources I have run from the linux tree sources:
> >>>>>
> >>>>> $ ../xenomai-3.git/scripts/prepare-kernel.sh --linux=. --
> >>>>> ipipe=../xenomai-3.git/kernel/cobalt/arch/x86/patches/ipipe-core-3.16-
> >>>>> x86-1.patch --arch=x86
> >>>>>
> >>>>>> Now, prepare-kernel.sh adds the scripts/Kconfig.frag file to
> >>>>>
> >>>>>> init/Kconfig. Kconfig.frag contains:
> >>>>> I don't understand that sentence. Yes, the  Kconfig.frag now, contains
> >>>>> this:
> >>>>>
> >>>>> source "arch/$ARCH/xenomai/Kconfig"
> >>>>
> >>>> Ah OK. Could you try to revert that commit ?
> >>>>
> >>>> http://git.xenomai.org/xenomai-3.git/commit/scripts/Kconfig.frag?h=next&
> >>>> id=2 6cc64313e2e695ac227e5a02992c5fe72df2e5f
> >>>
> >>> Gilles, I did it. I explained it before. As I just run the script, I don't
> >>> run any autoconf, so, I then have this part as @LINUX_ARCH@ so it doesn't
> >>> work.
> >>>
> >>> prepare-kernel script doesn't touch (substitute) that.
> >>
> >> prepare-kernel.sh before that commit substitutes @LINUX_ARCH@. You
> >> just need to revert the whole commit.
> > 
> > Ok, the whole commit touch also the prepare-kernel script. I have tested and 
> > now, I got in linux-tree/init/Kconfig:
> > 
> > if XENOMAI
> > source "arch/x86/xenomai/Kconfig"
> > endif
> > 
> > so, I'm sorry Jan, but I think that at least in debian platforms it wasn't a 
> > good change.
> 
> See
> http://git.xenomai.org/xenomai-jki.git/commit/?h=for-forge&id=5d104b1de84c8f4cbfb9d6b79cfaa633ef550e1c
> for the fix. The bug was the improper variable use in the Kconfig
> fragment. You only had to revert the whole commit as you were falling
> back to the obsolete prepare-time patching then, which involved the script.

I do not see what is so obsolete about it. As long as patches are
provided separately for each architecture, the prepare-kernel script
has to know the architecture anyway.

-- 
					    Gilles.

Re: [Xenomai] Xenomai-3 creating debian packages

[Jan Kiszka]

On 2015-01-22 14:44, Gilles Chanteperdrix wrote:
> On Thu, Jan 22, 2015 at 01:51:46PM +0100, Jan Kiszka wrote:
>> On 2015-01-22 12:59, Leopold Palomo-Avellaneda wrote:
>>> El Dijous, 22 de gener de 2015, a les 12:40:38, Gilles Chanteperdrix va 
>>> escriure:
>>>> On Thu, Jan 22, 2015 at 12:39:10PM +0100, Leopold Palomo-Avellaneda wrote:
>>>>> El Dijous, 22 de gener de 2015, a les 12:31:05, Gilles Chanteperdrix va
>>>>>
>>>>> escriure:
>>>>>> On Thu, Jan 22, 2015 at 12:17:15PM +0100, Leopold Palomo-Avellaneda 
>>> wrote:
>>>>>>> I have renamed the subject according with the theme.
>>>>>>>
>>>>>>> El Dijous, 22 de gener de 2015, a les 11:48:13, Gilles Chanteperdrix
>>>>>>> va
>>>>>>>
>>>>>>> escriure:
>>>>>>>>>> Well, the fact that the compilation error happens when trying to
>>>>>>>>>> compile a Xenomai file would seem to indicate that
>>>>>>>>>> prepare-kernel.sh
>>>>>>>>>> has put the wrong link into init/Kconfig.
>>>>>>>>>>
>>>>>>>>>> You pass --arch=x86 to prepare-kernel.sh, right, not
>>>>>>>>>> --arch=x86_64 ?
>>>>>>>>>
>>>>>>>>> yes, I have tried both, but I put --arch=x86 or the default option
>>>>>>>>> as
>>>>>>>>> I
>>>>>>>>> said it in my email from yesterday ( :-P)
>>>>>>>>
>>>>>>>> Well, maybe the default option does not work, so please try
>>>>>>>> specifying --arch=x86. The error you have is not in the compiled
>>>>>>>> files, but in the Kconfig files. So, the fact that you can compile
>>>>>>>> does not really prove that prepare-kernel.sh did not fail.
>>>>>>>
>>>>>>> Ok, from a clean sources I have run from the linux tree sources:
>>>>>>>
>>>>>>> $ ../xenomai-3.git/scripts/prepare-kernel.sh --linux=. --
>>>>>>> ipipe=../xenomai-3.git/kernel/cobalt/arch/x86/patches/ipipe-core-3.16-
>>>>>>> x86-1.patch --arch=x86
>>>>>>>
>>>>>>>> Now, prepare-kernel.sh adds the scripts/Kconfig.frag file to
>>>>>>>
>>>>>>>> init/Kconfig. Kconfig.frag contains:
>>>>>>> I don't understand that sentence. Yes, the  Kconfig.frag now, contains
>>>>>>> this:
>>>>>>>
>>>>>>> source "arch/$ARCH/xenomai/Kconfig"
>>>>>>
>>>>>> Ah OK. Could you try to revert that commit ?
>>>>>>
>>>>>> http://git.xenomai.org/xenomai-3.git/commit/scripts/Kconfig.frag?h=next&
>>>>>> id=2 6cc64313e2e695ac227e5a02992c5fe72df2e5f
>>>>>
>>>>> Gilles, I did it. I explained it before. As I just run the script, I don't
>>>>> run any autoconf, so, I then have this part as @LINUX_ARCH@ so it doesn't
>>>>> work.
>>>>>
>>>>> prepare-kernel script doesn't touch (substitute) that.
>>>>
>>>> prepare-kernel.sh before that commit substitutes @LINUX_ARCH@. You
>>>> just need to revert the whole commit.
>>>
>>> Ok, the whole commit touch also the prepare-kernel script. I have tested and 
>>> now, I got in linux-tree/init/Kconfig:
>>>
>>> if XENOMAI
>>> source "arch/x86/xenomai/Kconfig"
>>> endif
>>>
>>> so, I'm sorry Jan, but I think that at least in debian platforms it wasn't a 
>>> good change.
>>
>> See
>> http://git.xenomai.org/xenomai-jki.git/commit/?h=for-forge&id=5d104b1de84c8f4cbfb9d6b79cfaa633ef550e1c
>> for the fix. The bug was the improper variable use in the Kconfig
>> fragment. You only had to revert the whole commit as you were falling
>> back to the obsolete prepare-time patching then, which involved the script.
> 
> I do not see what is so obsolete about it. As long as patches are
> provided separately for each architecture, the prepare-kernel script
> has to know the architecture anyway.

The reason is given in the original patch: it allows merging all patches
and preparation into a single source tree. There is no technical need to
patch the arch in anymore.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Xenomai-3 creating debian packages

[Leopold Palomo-Avellaneda]

El Dijous, 22 de gener de 2015, a les 13:51:46, Jan Kiszka va escriure:
> On 2015-01-22 12:59, Leopold Palomo-Avellaneda wrote:
> > El Dijous, 22 de gener de 2015, a les 12:40:38, Gilles Chanteperdrix va
> > 
> > escriure:
> >> On Thu, Jan 22, 2015 at 12:39:10PM +0100, Leopold Palomo-Avellaneda 
wrote:
> >>> El Dijous, 22 de gener de 2015, a les 12:31:05, Gilles Chanteperdrix va
> >>> 
> >>> escriure:
> >>>> On Thu, Jan 22, 2015 at 12:17:15PM +0100, Leopold Palomo-Avellaneda
> > 
> > wrote:
> >>>>> I have renamed the subject according with the theme.
> >>>>> 
> >>>>> El Dijous, 22 de gener de 2015, a les 11:48:13, Gilles Chanteperdrix
> >>>>> va
> >>>>> 
> >>>>> escriure:
> >>>>>>>> Well, the fact that the compilation error happens when trying to
> >>>>>>>> compile a Xenomai file would seem to indicate that
> >>>>>>>> prepare-kernel.sh
> >>>>>>>> has put the wrong link into init/Kconfig.
> >>>>>>>> 
> >>>>>>>> You pass --arch=x86 to prepare-kernel.sh, right, not
> >>>>>>>> --arch=x86_64 ?
> >>>>>>> 
> >>>>>>> yes, I have tried both, but I put --arch=x86 or the default option
> >>>>>>> as
> >>>>>>> I
> >>>>>>> said it in my email from yesterday ( :-P)
> >>>>>> 
> >>>>>> Well, maybe the default option does not work, so please try
> >>>>>> specifying --arch=x86. The error you have is not in the compiled
> >>>>>> files, but in the Kconfig files. So, the fact that you can compile
> >>>>>> does not really prove that prepare-kernel.sh did not fail.
> >>>>> 
> >>>>> Ok, from a clean sources I have run from the linux tree sources:
> >>>>> 
> >>>>> $ ../xenomai-3.git/scripts/prepare-kernel.sh --linux=. --
> >>>>> ipipe=../xenomai-3.git/kernel/cobalt/arch/x86/patches/ipipe-core-3.16-
> >>>>> x86-1.patch --arch=x86
> >>>>> 
> >>>>>> Now, prepare-kernel.sh adds the scripts/Kconfig.frag file to
> >>>>> 
> >>>>>> init/Kconfig. Kconfig.frag contains:
> >>>>> I don't understand that sentence. Yes, the  Kconfig.frag now, contains
> >>>>> this:
> >>>>> 
> >>>>> source "arch/$ARCH/xenomai/Kconfig"
> >>>> 
> >>>> Ah OK. Could you try to revert that commit ?
> >>>> 
> >>>> http://git.xenomai.org/xenomai-3.git/commit/scripts/Kconfig.frag?h=next
> >>>> &
> >>>> id=2 6cc64313e2e695ac227e5a02992c5fe72df2e5f
> >>> 
> >>> Gilles, I did it. I explained it before. As I just run the script, I
> >>> don't
> >>> run any autoconf, so, I then have this part as @LINUX_ARCH@ so it
> >>> doesn't
> >>> work.
> >>> 
> >>> prepare-kernel script doesn't touch (substitute) that.
> >> 
> >> prepare-kernel.sh before that commit substitutes @LINUX_ARCH@. You
> >> just need to revert the whole commit.
> > 
> > Ok, the whole commit touch also the prepare-kernel script. I have tested
> > and now, I got in linux-tree/init/Kconfig:
> > 
> > if XENOMAI
> > source "arch/x86/xenomai/Kconfig"
> > endif
> > 
> > so, I'm sorry Jan, but I think that at least in debian platforms it wasn't
> > a good change.
> 
> See
> http://git.xenomai.org/xenomai-jki.git/commit/?h=for-forge&id=5d104b1de84c8f
> 4cbfb9d6b79cfaa633ef550e1c for the fix. The bug was the improper variable
> use in the Kconfig
> fragment. You only had to revert the whole commit as you were falling
> back to the obsolete prepare-time patching then, which involved the script.

Ok, reverted and it works. Please, could you update it?

> > Now, the noapic issue, do you have some idea?
> 
> I provided some answers already.
> 

Yes,

> Sounds like interrupt remapping is enabled for your system. That's not
> supported by Xenomai / I-pipe so far (on my to-do list, along with
> x2APIC support). Disable this via "intel_iommu=off intremap=off" in the
> kernel command line or by changing the kernel config to not include
> IOMMU / interrupt remapping support.

I disable all IOMMU support, or just the intel IOMMU using DMA Remapping 
Devices and the Support for Interrupt Remapping?


Regards,


Leopold



-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150122/c08685fe/attachment.sig>

Re: [Xenomai] Xenomai-3 creating debian packages

[Jan Kiszka]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2015-01-22 14:53, Leopold Palomo-Avellaneda wrote:
> El Dijous, 22 de gener de 2015, a les 13:51:46, Jan Kiszka va
> escriure:
>> On 2015-01-22 12:59, Leopold Palomo-Avellaneda wrote:
>>> El Dijous, 22 de gener de 2015, a les 12:40:38, Gilles
>>> Chanteperdrix va
>>> 
>>> escriure:
>>>> On Thu, Jan 22, 2015 at 12:39:10PM +0100, Leopold
>>>> Palomo-Avellaneda
> wrote:
>>>>> El Dijous, 22 de gener de 2015, a les 12:31:05, Gilles
>>>>> Chanteperdrix va
>>>>> 
>>>>> escriure:
>>>>>> On Thu, Jan 22, 2015 at 12:17:15PM +0100, Leopold
>>>>>> Palomo-Avellaneda
>>> 
>>> wrote:
>>>>>>> I have renamed the subject according with the theme.
>>>>>>> 
>>>>>>> El Dijous, 22 de gener de 2015, a les 11:48:13, Gilles
>>>>>>> Chanteperdrix va
>>>>>>> 
>>>>>>> escriure:
>>>>>>>>>> Well, the fact that the compilation error happens
>>>>>>>>>> when trying to compile a Xenomai file would seem
>>>>>>>>>> to indicate that prepare-kernel.sh has put the
>>>>>>>>>> wrong link into init/Kconfig.
>>>>>>>>>> 
>>>>>>>>>> You pass --arch=x86 to prepare-kernel.sh, right,
>>>>>>>>>> not --arch=x86_64 ?
>>>>>>>>> 
>>>>>>>>> yes, I have tried both, but I put --arch=x86 or the
>>>>>>>>> default option as I said it in my email from
>>>>>>>>> yesterday ( :-P)
>>>>>>>> 
>>>>>>>> Well, maybe the default option does not work, so
>>>>>>>> please try specifying --arch=x86. The error you have
>>>>>>>> is not in the compiled files, but in the Kconfig
>>>>>>>> files. So, the fact that you can compile does not
>>>>>>>> really prove that prepare-kernel.sh did not fail.
>>>>>>> 
>>>>>>> Ok, from a clean sources I have run from the linux tree
>>>>>>> sources:
>>>>>>> 
>>>>>>> $ ../xenomai-3.git/scripts/prepare-kernel.sh --linux=.
>>>>>>> -- 
>>>>>>> ipipe=../xenomai-3.git/kernel/cobalt/arch/x86/patches/ipipe-core-3.16-
>>>>>>>
>>>>>>> 
x86-1.patch --arch=x86
>>>>>>> 
>>>>>>>> Now, prepare-kernel.sh adds the scripts/Kconfig.frag
>>>>>>>> file to
>>>>>>> 
>>>>>>>> init/Kconfig. Kconfig.frag contains:
>>>>>>> I don't understand that sentence. Yes, the
>>>>>>> Kconfig.frag now, contains this:
>>>>>>> 
>>>>>>> source "arch/$ARCH/xenomai/Kconfig"
>>>>>> 
>>>>>> Ah OK. Could you try to revert that commit ?
>>>>>> 
>>>>>> http://git.xenomai.org/xenomai-3.git/commit/scripts/Kconfig.frag?h=next
>>>>>>
>>>>>> 
&
>>>>>> id=2 6cc64313e2e695ac227e5a02992c5fe72df2e5f
>>>>> 
>>>>> Gilles, I did it. I explained it before. As I just run the
>>>>> script, I don't run any autoconf, so, I then have this part
>>>>> as @LINUX_ARCH@ so it doesn't work.
>>>>> 
>>>>> prepare-kernel script doesn't touch (substitute) that.
>>>> 
>>>> prepare-kernel.sh before that commit substitutes
>>>> @LINUX_ARCH@. You just need to revert the whole commit.
>>> 
>>> Ok, the whole commit touch also the prepare-kernel script. I
>>> have tested and now, I got in linux-tree/init/Kconfig:
>>> 
>>> if XENOMAI source "arch/x86/xenomai/Kconfig" endif
>>> 
>>> so, I'm sorry Jan, but I think that at least in debian
>>> platforms it wasn't a good change.
>> 
>> See 
>> http://git.xenomai.org/xenomai-jki.git/commit/?h=for-forge&id=5d104b1de84c8f
>>
>> 
4cbfb9d6b79cfaa633ef550e1c for the fix. The bug was the improper variable
>> use in the Kconfig fragment. You only had to revert the whole
>> commit as you were falling back to the obsolete prepare-time
>> patching then, which involved the script.
> 
> Ok, reverted and it works. Please, could you update it?
> 
>>> Now, the noapic issue, do you have some idea?
>> 
>> I provided some answers already.
>> 
> 
> Yes,
> 
>> Sounds like interrupt remapping is enabled for your system.
>> That's not supported by Xenomai / I-pipe so far (on my to-do
>> list, along with x2APIC support). Disable this via
>> "intel_iommu=off intremap=off" in the kernel command line or by
>> changing the kernel config to not include IOMMU / interrupt
>> remapping support.
> 
> I disable all IOMMU support, or just the intel IOMMU using DMA
> Remapping Devices and the Support for Interrupt Remapping?

To be save, disable IOMMU completely unless you need it (for KVM
etc.). It doesn't buy you much otherwise. The critical feature for
your issue is most likely interrupts remapping that should be turned
off via parameter or config switch (CONFIG_IRQ_REMAP).

Jan

- -- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlTBAdUACgkQitSsb3rl5xSVMgCgpNRa5ayXTlgLN1wXkS/tyOEV
nQYAoLmr6pjagO8qPs1siXmMY7exyIqv
=MerP
-----END PGP SIGNATURE-----

Re: [Xenomai] Xenomai-3 creating debian packages

[Gilles Chanteperdrix]

On Thu, Jan 22, 2015 at 02:50:59PM +0100, Jan Kiszka wrote:
> On 2015-01-22 14:44, Gilles Chanteperdrix wrote:
> > On Thu, Jan 22, 2015 at 01:51:46PM +0100, Jan Kiszka wrote:
> >> On 2015-01-22 12:59, Leopold Palomo-Avellaneda wrote:
> >>> El Dijous, 22 de gener de 2015, a les 12:40:38, Gilles Chanteperdrix va 
> >>> escriure:
> >>>> On Thu, Jan 22, 2015 at 12:39:10PM +0100, Leopold Palomo-Avellaneda wrote:
> >>>>> El Dijous, 22 de gener de 2015, a les 12:31:05, Gilles Chanteperdrix va
> >>>>>
> >>>>> escriure:
> >>>>>> On Thu, Jan 22, 2015 at 12:17:15PM +0100, Leopold Palomo-Avellaneda 
> >>> wrote:
> >>>>>>> I have renamed the subject according with the theme.
> >>>>>>>
> >>>>>>> El Dijous, 22 de gener de 2015, a les 11:48:13, Gilles Chanteperdrix
> >>>>>>> va
> >>>>>>>
> >>>>>>> escriure:
> >>>>>>>>>> Well, the fact that the compilation error happens when trying to
> >>>>>>>>>> compile a Xenomai file would seem to indicate that
> >>>>>>>>>> prepare-kernel.sh
> >>>>>>>>>> has put the wrong link into init/Kconfig.
> >>>>>>>>>>
> >>>>>>>>>> You pass --arch=x86 to prepare-kernel.sh, right, not
> >>>>>>>>>> --arch=x86_64 ?
> >>>>>>>>>
> >>>>>>>>> yes, I have tried both, but I put --arch=x86 or the default option
> >>>>>>>>> as
> >>>>>>>>> I
> >>>>>>>>> said it in my email from yesterday ( :-P)
> >>>>>>>>
> >>>>>>>> Well, maybe the default option does not work, so please try
> >>>>>>>> specifying --arch=x86. The error you have is not in the compiled
> >>>>>>>> files, but in the Kconfig files. So, the fact that you can compile
> >>>>>>>> does not really prove that prepare-kernel.sh did not fail.
> >>>>>>>
> >>>>>>> Ok, from a clean sources I have run from the linux tree sources:
> >>>>>>>
> >>>>>>> $ ../xenomai-3.git/scripts/prepare-kernel.sh --linux=. --
> >>>>>>> ipipe=../xenomai-3.git/kernel/cobalt/arch/x86/patches/ipipe-core-3.16-
> >>>>>>> x86-1.patch --arch=x86
> >>>>>>>
> >>>>>>>> Now, prepare-kernel.sh adds the scripts/Kconfig.frag file to
> >>>>>>>
> >>>>>>>> init/Kconfig. Kconfig.frag contains:
> >>>>>>> I don't understand that sentence. Yes, the  Kconfig.frag now, contains
> >>>>>>> this:
> >>>>>>>
> >>>>>>> source "arch/$ARCH/xenomai/Kconfig"
> >>>>>>
> >>>>>> Ah OK. Could you try to revert that commit ?
> >>>>>>
> >>>>>> http://git.xenomai.org/xenomai-3.git/commit/scripts/Kconfig.frag?h=next&
> >>>>>> id=2 6cc64313e2e695ac227e5a02992c5fe72df2e5f
> >>>>>
> >>>>> Gilles, I did it. I explained it before. As I just run the script, I don't
> >>>>> run any autoconf, so, I then have this part as @LINUX_ARCH@ so it doesn't
> >>>>> work.
> >>>>>
> >>>>> prepare-kernel script doesn't touch (substitute) that.
> >>>>
> >>>> prepare-kernel.sh before that commit substitutes @LINUX_ARCH@. You
> >>>> just need to revert the whole commit.
> >>>
> >>> Ok, the whole commit touch also the prepare-kernel script. I have tested and 
> >>> now, I got in linux-tree/init/Kconfig:
> >>>
> >>> if XENOMAI
> >>> source "arch/x86/xenomai/Kconfig"
> >>> endif
> >>>
> >>> so, I'm sorry Jan, but I think that at least in debian platforms it wasn't a 
> >>> good change.
> >>
> >> See
> >> http://git.xenomai.org/xenomai-jki.git/commit/?h=for-forge&id=5d104b1de84c8f4cbfb9d6b79cfaa633ef550e1c
> >> for the fix. The bug was the improper variable use in the Kconfig
> >> fragment. You only had to revert the whole commit as you were falling
> >> back to the obsolete prepare-time patching then, which involved the script.
> > 
> > I do not see what is so obsolete about it. As long as patches are
> > provided separately for each architecture, the prepare-kernel script
> > has to know the architecture anyway.
> 
> The reason is given in the original patch: it allows merging all patches
> and preparation into a single source tree. There is no technical need to
> patch the arch in anymore.

Providing separate patches for architectures has a huge advantage:
if you need to release patch because one bug was fixed for one
architecture, you only need to release the patch for this
architecture. Besides, most Xenomai users (as opposed to developers)
use one architecture at a time.

-- 
					    Gilles.

Re: [Xenomai] Xenomai-3 creating debian packages

[Gilles Chanteperdrix]

On Thu, Jan 22, 2015 at 02:50:59PM +0100, Jan Kiszka wrote:
> On 2015-01-22 14:44, Gilles Chanteperdrix wrote:
> > On Thu, Jan 22, 2015 at 01:51:46PM +0100, Jan Kiszka wrote:
> >> On 2015-01-22 12:59, Leopold Palomo-Avellaneda wrote:
> >>> El Dijous, 22 de gener de 2015, a les 12:40:38, Gilles Chanteperdrix va 
> >>> escriure:
> >>>> On Thu, Jan 22, 2015 at 12:39:10PM +0100, Leopold Palomo-Avellaneda wrote:
> >>>>> El Dijous, 22 de gener de 2015, a les 12:31:05, Gilles Chanteperdrix va
> >>>>>
> >>>>> escriure:
> >>>>>> On Thu, Jan 22, 2015 at 12:17:15PM +0100, Leopold Palomo-Avellaneda 
> >>> wrote:
> >>>>>>> I have renamed the subject according with the theme.
> >>>>>>>
> >>>>>>> El Dijous, 22 de gener de 2015, a les 11:48:13, Gilles Chanteperdrix
> >>>>>>> va
> >>>>>>>
> >>>>>>> escriure:
> >>>>>>>>>> Well, the fact that the compilation error happens when trying to
> >>>>>>>>>> compile a Xenomai file would seem to indicate that
> >>>>>>>>>> prepare-kernel.sh
> >>>>>>>>>> has put the wrong link into init/Kconfig.
> >>>>>>>>>>
> >>>>>>>>>> You pass --arch=x86 to prepare-kernel.sh, right, not
> >>>>>>>>>> --arch=x86_64 ?
> >>>>>>>>>
> >>>>>>>>> yes, I have tried both, but I put --arch=x86 or the default option
> >>>>>>>>> as
> >>>>>>>>> I
> >>>>>>>>> said it in my email from yesterday ( :-P)
> >>>>>>>>
> >>>>>>>> Well, maybe the default option does not work, so please try
> >>>>>>>> specifying --arch=x86. The error you have is not in the compiled
> >>>>>>>> files, but in the Kconfig files. So, the fact that you can compile
> >>>>>>>> does not really prove that prepare-kernel.sh did not fail.
> >>>>>>>
> >>>>>>> Ok, from a clean sources I have run from the linux tree sources:
> >>>>>>>
> >>>>>>> $ ../xenomai-3.git/scripts/prepare-kernel.sh --linux=. --
> >>>>>>> ipipe=../xenomai-3.git/kernel/cobalt/arch/x86/patches/ipipe-core-3.16-
> >>>>>>> x86-1.patch --arch=x86
> >>>>>>>
> >>>>>>>> Now, prepare-kernel.sh adds the scripts/Kconfig.frag file to
> >>>>>>>
> >>>>>>>> init/Kconfig. Kconfig.frag contains:
> >>>>>>> I don't understand that sentence. Yes, the  Kconfig.frag now, contains
> >>>>>>> this:
> >>>>>>>
> >>>>>>> source "arch/$ARCH/xenomai/Kconfig"
> >>>>>>
> >>>>>> Ah OK. Could you try to revert that commit ?
> >>>>>>
> >>>>>> http://git.xenomai.org/xenomai-3.git/commit/scripts/Kconfig.frag?h=next&
> >>>>>> id=2 6cc64313e2e695ac227e5a02992c5fe72df2e5f
> >>>>>
> >>>>> Gilles, I did it. I explained it before. As I just run the script, I don't
> >>>>> run any autoconf, so, I then have this part as @LINUX_ARCH@ so it doesn't
> >>>>> work.
> >>>>>
> >>>>> prepare-kernel script doesn't touch (substitute) that.
> >>>>
> >>>> prepare-kernel.sh before that commit substitutes @LINUX_ARCH@. You
> >>>> just need to revert the whole commit.
> >>>
> >>> Ok, the whole commit touch also the prepare-kernel script. I have tested and 
> >>> now, I got in linux-tree/init/Kconfig:
> >>>
> >>> if XENOMAI
> >>> source "arch/x86/xenomai/Kconfig"
> >>> endif
> >>>
> >>> so, I'm sorry Jan, but I think that at least in debian platforms it wasn't a 
> >>> good change.
> >>
> >> See
> >> http://git.xenomai.org/xenomai-jki.git/commit/?h=for-forge&id=5d104b1de84c8f4cbfb9d6b79cfaa633ef550e1c
> >> for the fix. The bug was the improper variable use in the Kconfig
> >> fragment. You only had to revert the whole commit as you were falling
> >> back to the obsolete prepare-time patching then, which involved the script.
> > 
> > I do not see what is so obsolete about it. As long as patches are
> > provided separately for each architecture, the prepare-kernel script
> > has to know the architecture anyway.
> 
> The reason is given in the original patch: it allows merging all patches
> and preparation into a single source tree. There is no technical need to
> patch the arch in anymore.

Just to finish on the subject of the I-pipe maintenance, what some
find good, others find bad. For my part of instance, I find the git
based "new" maintenance to be a major PITA for the job of
maintaining the I-pipe for ARM. Newer does not always mean better.

-- 
					    Gilles.

Re: [Xenomai] Xenomai-3 creating debian packages

[Jan Kiszka]

On 2015-01-22 14:58, Gilles Chanteperdrix wrote:
> On Thu, Jan 22, 2015 at 02:50:59PM +0100, Jan Kiszka wrote:
>> On 2015-01-22 14:44, Gilles Chanteperdrix wrote:
>>> On Thu, Jan 22, 2015 at 01:51:46PM +0100, Jan Kiszka wrote:
>>>> On 2015-01-22 12:59, Leopold Palomo-Avellaneda wrote:
>>>>> El Dijous, 22 de gener de 2015, a les 12:40:38, Gilles Chanteperdrix va 
>>>>> escriure:
>>>>>> On Thu, Jan 22, 2015 at 12:39:10PM +0100, Leopold Palomo-Avellaneda wrote:
>>>>>>> El Dijous, 22 de gener de 2015, a les 12:31:05, Gilles Chanteperdrix va
>>>>>>>
>>>>>>> escriure:
>>>>>>>> On Thu, Jan 22, 2015 at 12:17:15PM +0100, Leopold Palomo-Avellaneda 
>>>>> wrote:
>>>>>>>>> I have renamed the subject according with the theme.
>>>>>>>>>
>>>>>>>>> El Dijous, 22 de gener de 2015, a les 11:48:13, Gilles Chanteperdrix
>>>>>>>>> va
>>>>>>>>>
>>>>>>>>> escriure:
>>>>>>>>>>>> Well, the fact that the compilation error happens when trying to
>>>>>>>>>>>> compile a Xenomai file would seem to indicate that
>>>>>>>>>>>> prepare-kernel.sh
>>>>>>>>>>>> has put the wrong link into init/Kconfig.
>>>>>>>>>>>>
>>>>>>>>>>>> You pass --arch=x86 to prepare-kernel.sh, right, not
>>>>>>>>>>>> --arch=x86_64 ?
>>>>>>>>>>>
>>>>>>>>>>> yes, I have tried both, but I put --arch=x86 or the default option
>>>>>>>>>>> as
>>>>>>>>>>> I
>>>>>>>>>>> said it in my email from yesterday ( :-P)
>>>>>>>>>>
>>>>>>>>>> Well, maybe the default option does not work, so please try
>>>>>>>>>> specifying --arch=x86. The error you have is not in the compiled
>>>>>>>>>> files, but in the Kconfig files. So, the fact that you can compile
>>>>>>>>>> does not really prove that prepare-kernel.sh did not fail.
>>>>>>>>>
>>>>>>>>> Ok, from a clean sources I have run from the linux tree sources:
>>>>>>>>>
>>>>>>>>> $ ../xenomai-3.git/scripts/prepare-kernel.sh --linux=. --
>>>>>>>>> ipipe=../xenomai-3.git/kernel/cobalt/arch/x86/patches/ipipe-core-3.16-
>>>>>>>>> x86-1.patch --arch=x86
>>>>>>>>>
>>>>>>>>>> Now, prepare-kernel.sh adds the scripts/Kconfig.frag file to
>>>>>>>>>
>>>>>>>>>> init/Kconfig. Kconfig.frag contains:
>>>>>>>>> I don't understand that sentence. Yes, the  Kconfig.frag now, contains
>>>>>>>>> this:
>>>>>>>>>
>>>>>>>>> source "arch/$ARCH/xenomai/Kconfig"
>>>>>>>>
>>>>>>>> Ah OK. Could you try to revert that commit ?
>>>>>>>>
>>>>>>>> http://git.xenomai.org/xenomai-3.git/commit/scripts/Kconfig.frag?h=next&
>>>>>>>> id=2 6cc64313e2e695ac227e5a02992c5fe72df2e5f
>>>>>>>
>>>>>>> Gilles, I did it. I explained it before. As I just run the script, I don't
>>>>>>> run any autoconf, so, I then have this part as @LINUX_ARCH@ so it doesn't
>>>>>>> work.
>>>>>>>
>>>>>>> prepare-kernel script doesn't touch (substitute) that.
>>>>>>
>>>>>> prepare-kernel.sh before that commit substitutes @LINUX_ARCH@. You
>>>>>> just need to revert the whole commit.
>>>>>
>>>>> Ok, the whole commit touch also the prepare-kernel script. I have tested and 
>>>>> now, I got in linux-tree/init/Kconfig:
>>>>>
>>>>> if XENOMAI
>>>>> source "arch/x86/xenomai/Kconfig"
>>>>> endif
>>>>>
>>>>> so, I'm sorry Jan, but I think that at least in debian platforms it wasn't a 
>>>>> good change.
>>>>
>>>> See
>>>> http://git.xenomai.org/xenomai-jki.git/commit/?h=for-forge&id=5d104b1de84c8f4cbfb9d6b79cfaa633ef550e1c
>>>> for the fix. The bug was the improper variable use in the Kconfig
>>>> fragment. You only had to revert the whole commit as you were falling
>>>> back to the obsolete prepare-time patching then, which involved the script.
>>>
>>> I do not see what is so obsolete about it. As long as patches are
>>> provided separately for each architecture, the prepare-kernel script
>>> has to know the architecture anyway.
>>
>> The reason is given in the original patch: it allows merging all patches
>> and preparation into a single source tree. There is no technical need to
>> patch the arch in anymore.
> 
> Providing separate patches for architectures has a huge advantage:
> if you need to release patch because one bug was fixed for one
> architecture, you only need to release the patch for this
> architecture. Besides, most Xenomai users (as opposed to developers)
> use one architecture at a time.

Misunderstanding: This is about integrating the separate patches and
Xenomai fragments over a single source tree for local build purposes,
not about obsoleting per-arch I-pipe patches. It's a small added feature
to the Xenomai kernel preparation process, no change of the maintenance
approach.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Xenomai-3 creating debian packages

[Gilles Chanteperdrix]

On Thu, Jan 22, 2015 at 03:22:09PM +0100, Jan Kiszka wrote:
> On 2015-01-22 14:58, Gilles Chanteperdrix wrote:
> > On Thu, Jan 22, 2015 at 02:50:59PM +0100, Jan Kiszka wrote:
> >> On 2015-01-22 14:44, Gilles Chanteperdrix wrote:
> >>> On Thu, Jan 22, 2015 at 01:51:46PM +0100, Jan Kiszka wrote:
> >>>> On 2015-01-22 12:59, Leopold Palomo-Avellaneda wrote:
> >>>>> El Dijous, 22 de gener de 2015, a les 12:40:38, Gilles Chanteperdrix va 
> >>>>> escriure:
> >>>>>> On Thu, Jan 22, 2015 at 12:39:10PM +0100, Leopold Palomo-Avellaneda wrote:
> >>>>>>> El Dijous, 22 de gener de 2015, a les 12:31:05, Gilles Chanteperdrix va
> >>>>>>>
> >>>>>>> escriure:
> >>>>>>>> On Thu, Jan 22, 2015 at 12:17:15PM +0100, Leopold Palomo-Avellaneda 
> >>>>> wrote:
> >>>>>>>>> I have renamed the subject according with the theme.
> >>>>>>>>>
> >>>>>>>>> El Dijous, 22 de gener de 2015, a les 11:48:13, Gilles Chanteperdrix
> >>>>>>>>> va
> >>>>>>>>>
> >>>>>>>>> escriure:
> >>>>>>>>>>>> Well, the fact that the compilation error happens when trying to
> >>>>>>>>>>>> compile a Xenomai file would seem to indicate that
> >>>>>>>>>>>> prepare-kernel.sh
> >>>>>>>>>>>> has put the wrong link into init/Kconfig.
> >>>>>>>>>>>>
> >>>>>>>>>>>> You pass --arch=x86 to prepare-kernel.sh, right, not
> >>>>>>>>>>>> --arch=x86_64 ?
> >>>>>>>>>>>
> >>>>>>>>>>> yes, I have tried both, but I put --arch=x86 or the default option
> >>>>>>>>>>> as
> >>>>>>>>>>> I
> >>>>>>>>>>> said it in my email from yesterday ( :-P)
> >>>>>>>>>>
> >>>>>>>>>> Well, maybe the default option does not work, so please try
> >>>>>>>>>> specifying --arch=x86. The error you have is not in the compiled
> >>>>>>>>>> files, but in the Kconfig files. So, the fact that you can compile
> >>>>>>>>>> does not really prove that prepare-kernel.sh did not fail.
> >>>>>>>>>
> >>>>>>>>> Ok, from a clean sources I have run from the linux tree sources:
> >>>>>>>>>
> >>>>>>>>> $ ../xenomai-3.git/scripts/prepare-kernel.sh --linux=. --
> >>>>>>>>> ipipe=../xenomai-3.git/kernel/cobalt/arch/x86/patches/ipipe-core-3.16-
> >>>>>>>>> x86-1.patch --arch=x86
> >>>>>>>>>
> >>>>>>>>>> Now, prepare-kernel.sh adds the scripts/Kconfig.frag file to
> >>>>>>>>>
> >>>>>>>>>> init/Kconfig. Kconfig.frag contains:
> >>>>>>>>> I don't understand that sentence. Yes, the  Kconfig.frag now, contains
> >>>>>>>>> this:
> >>>>>>>>>
> >>>>>>>>> source "arch/$ARCH/xenomai/Kconfig"
> >>>>>>>>
> >>>>>>>> Ah OK. Could you try to revert that commit ?
> >>>>>>>>
> >>>>>>>> http://git.xenomai.org/xenomai-3.git/commit/scripts/Kconfig.frag?h=next&
> >>>>>>>> id=2 6cc64313e2e695ac227e5a02992c5fe72df2e5f
> >>>>>>>
> >>>>>>> Gilles, I did it. I explained it before. As I just run the script, I don't
> >>>>>>> run any autoconf, so, I then have this part as @LINUX_ARCH@ so it doesn't
> >>>>>>> work.
> >>>>>>>
> >>>>>>> prepare-kernel script doesn't touch (substitute) that.
> >>>>>>
> >>>>>> prepare-kernel.sh before that commit substitutes @LINUX_ARCH@. You
> >>>>>> just need to revert the whole commit.
> >>>>>
> >>>>> Ok, the whole commit touch also the prepare-kernel script. I have tested and 
> >>>>> now, I got in linux-tree/init/Kconfig:
> >>>>>
> >>>>> if XENOMAI
> >>>>> source "arch/x86/xenomai/Kconfig"
> >>>>> endif
> >>>>>
> >>>>> so, I'm sorry Jan, but I think that at least in debian platforms it wasn't a 
> >>>>> good change.
> >>>>
> >>>> See
> >>>> http://git.xenomai.org/xenomai-jki.git/commit/?h=for-forge&id=5d104b1de84c8f4cbfb9d6b79cfaa633ef550e1c
> >>>> for the fix. The bug was the improper variable use in the Kconfig
> >>>> fragment. You only had to revert the whole commit as you were falling
> >>>> back to the obsolete prepare-time patching then, which involved the script.
> >>>
> >>> I do not see what is so obsolete about it. As long as patches are
> >>> provided separately for each architecture, the prepare-kernel script
> >>> has to know the architecture anyway.
> >>
> >> The reason is given in the original patch: it allows merging all patches
> >> and preparation into a single source tree. There is no technical need to
> >> patch the arch in anymore.
> > 
> > Providing separate patches for architectures has a huge advantage:
> > if you need to release patch because one bug was fixed for one
> > architecture, you only need to release the patch for this
> > architecture. Besides, most Xenomai users (as opposed to developers)
> > use one architecture at a time.
> 
> Misunderstanding: This is about integrating the separate patches and
> Xenomai fragments over a single source tree for local build purposes,
> not about obsoleting per-arch I-pipe patches. It's a small added feature
> to the Xenomai kernel preparation process, no change of the maintenance
> approach.

Then again, I think calling the method we used until now "obsolete"
is a poor choice of word. Since it is the method that Xenomai use
and will continue to use, there is nothing obsolete about it.

-- 
					    Gilles.

Re: [Xenomai] Xenomai-3 booting problems

[Lennart Sorensen]

On Thu, Jan 22, 2015 at 09:34:11AM +0100, Leopold Palomo-Avellaneda wrote:
> El Dijous, 22 de gener de 2015, a les 08:54:29, Gilles Chanteperdrix va 
> escriure:
> > On Thu, Jan 22, 2015 at 08:47:24AM +0100, Leopold Palomo-Avellaneda wrote:
> > > Hi,
> > > 
> > > 
> > > I have compiling a Cobalt kernel. I have followed the web "wikipress"
> > > [1];-) recommendations. However, my box (a normal desktop computer - Dell
> > > Optiplex 7010 -) doesn't boot. It throws a message like:
> > > ....
> > > timer doesn't work through interrup-remapped IO-apic
> > > 
> > > ...
> > > 
> > > enabling noapic in the boot options I'm able to boot. But, I have not make
> > > any test by now. Some interesting messages:
> > > 
> > > $ dmesg | grep -i xenomai
> > > [    0.000000] Linux version 3.16.0-xenomai-3.0.0 (root@soho) (gcc version
> > > 4.9.1 (Debian 4.9.1-19) ) #1 SMP Wed Jan 21 16:29:36 UTC 2015
> > > [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-xenomai-3.0.0
> > > root=UUID=15cfac82-1127-421f-9aed-eaf48247ed4e ro quiet noapic
> > > [    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-
> > > xenomai-3.0.0 root=UUID=15cfac82-1127-421f-9aed-eaf48247ed4e ro quiet
> > > noapic [    0.705071] [Xenomai] scheduling class idle registered.
> > > [    0.705072] [Xenomai] scheduling class rt registered.
> > > [    0.705090] [Xenomai] disabling automatic C1E state promotion on Intel
> > > processor
> > > [    0.705104] [Xenomai] SMI-enabled chipset found, but SMI workaround
> > > disabled
> > > 
> > >           (see xenomai.smi parameter). You might encounter
> > > 
> > > [    0.705284] I-pipe: head domain Xenomai registered.
> > > [    0.717986] [Xenomai] Cobalt v3.0-rc2 (Exact Zero) [DEBUG]
> > > [    0.897726] usb usb1: Manufacturer: Linux 3.16.0-xenomai-3.0.0 xhci_hcd
> > > [    0.898617] usb usb2: Manufacturer: Linux 3.16.0-xenomai-3.0.0 xhci_hcd
> > > [    0.914114] usb usb3: Manufacturer: Linux 3.16.0-xenomai-3.0.0 ehci_hcd
> > > [    0.930109] usb usb4: Manufacturer: Linux 3.16.0-xenomai-3.0.0 ehci_hcd
> > > *** RTnet for Xenomai v3.0-rc2 ***
> > > 
> > > 
> > > So, can avoid to pass the noapic parameter to the kernel to boot?
> > 
> > Please post the full boot logs, and the kernel configuration. 
> 
> Attached.
> 
> 
> > Does the
> > kernel work with exactly the same .config but without Xenomai? 
> 
> I don't know. It's a similar kernel configuration than debian ships with 
> jessie.
> 
> > Is
> > CONFIG_SMP enabled? Because if CONFIG_SMP is enabled, Xenomai will
> > not work without an APIC.
> 
> Yes, CONFIG_SMP=y and CONFIG_X86_IO_APIC=y

But your kernel commandline included 'quiet noapic' in the above, which
would turn of apic use even if the config could use it.

-- 
Len Sorensen

Re: [Xenomai] Xenomai-3 creating debian packages

[Lennart Sorensen]

On Thu, Jan 22, 2015 at 01:51:46PM +0100, Jan Kiszka wrote:
> See
> http://git.xenomai.org/xenomai-jki.git/commit/?h=for-forge&id=5d104b1de84c8f4cbfb9d6b79cfaa633ef550e1c
> for the fix. The bug was the improper variable use in the Kconfig
> fragment. You only had to revert the whole commit as you were falling
> back to the obsolete prepare-time patching then, which involved the script.

What a handy change.  That should make multiple architectures in one
source tree finally possible without merge conflicts in that file.

-- 
Len Sorensen

Re: [Xenomai] Xenomai-3 creating debian packages

[Gilles Chanteperdrix]

On Thu, Jan 22, 2015 at 09:49:30AM -0500, Lennart Sorensen wrote:
> On Thu, Jan 22, 2015 at 01:51:46PM +0100, Jan Kiszka wrote:
> > See
> > http://git.xenomai.org/xenomai-jki.git/commit/?h=for-forge&id=5d104b1de84c8f4cbfb9d6b79cfaa633ef550e1c
> > for the fix. The bug was the improper variable use in the Kconfig
> > fragment. You only had to revert the whole commit as you were falling
> > back to the obsolete prepare-time patching then, which involved the script.
> 
> What a handy change.  That should make multiple architectures in one
> source tree finally possible without merge conflicts in that file.

Unfortunately not, if you want to work with the I-pipe git, you can
not run prepare-kernel.sh in that directory anyway, otherwise you
could end-up commiting the Xenomai fragments with the I-pipe kernel.

-- 
					    Gilles.

Re: [Xenomai] Xenomai-3 creating debian packages

[Jan Kiszka]

On 2015-01-22 15:56, Gilles Chanteperdrix wrote:
> On Thu, Jan 22, 2015 at 09:49:30AM -0500, Lennart Sorensen wrote:
>> On Thu, Jan 22, 2015 at 01:51:46PM +0100, Jan Kiszka wrote:
>>> See
>>> http://git.xenomai.org/xenomai-jki.git/commit/?h=for-forge&id=5d104b1de84c8f4cbfb9d6b79cfaa633ef550e1c
>>> for the fix. The bug was the improper variable use in the Kconfig
>>> fragment. You only had to revert the whole commit as you were falling
>>> back to the obsolete prepare-time patching then, which involved the script.
>>
>> What a handy change.  That should make multiple architectures in one
>> source tree finally possible without merge conflicts in that file.
> 
> Unfortunately not, if you want to work with the I-pipe git, you can
> not run prepare-kernel.sh in that directory anyway, otherwise you
> could end-up commiting the Xenomai fragments with the I-pipe kernel.

You can, we are doing this for ages. You only need to clean up your repo
from the additional changes Xenomai introduced (a hand full) before
moving HEAD (unless those files aren't affected by the move). Find my
script below. Works with x86 and ARM so far, but only with one arch
when using 2.6.

The risk of committing preparation fragments is not higher than
committing anything else accidentally that you may have added to test or
debug a local version. When producing images, you don't have that
problem and can automatize the cleaning.

Jan

---

rm -rf kernel/xenomai drivers/xenomai arch/x86/include/asm/xenomai arch/x86/xenomai include/xenomai include/asm-generic/xenomai arch/x86/include/ipipe 2>/dev/null
rm -rf drivers/xenomai arch/arm/include/asm/xenomai arch/arm/xenomai arch/arm/include/ipipe 2>/dev/null
rm -rf include/trace/events/xn_*.h include/trace/events/cobalt-*.h 2>/dev/null
git checkout -- arch/x86/Makefile arch/arm/Makefile drivers/Makefile init/Kconfig kernel/Makefile

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Xenomai-3 creating debian packages

[Gilles Chanteperdrix]

On Thu, Jan 22, 2015 at 04:02:36PM +0100, Jan Kiszka wrote:
> On 2015-01-22 15:56, Gilles Chanteperdrix wrote:
> > On Thu, Jan 22, 2015 at 09:49:30AM -0500, Lennart Sorensen wrote:
> >> On Thu, Jan 22, 2015 at 01:51:46PM +0100, Jan Kiszka wrote:
> >>> See
> >>> http://git.xenomai.org/xenomai-jki.git/commit/?h=for-forge&id=5d104b1de84c8f4cbfb9d6b79cfaa633ef550e1c
> >>> for the fix. The bug was the improper variable use in the Kconfig
> >>> fragment. You only had to revert the whole commit as you were falling
> >>> back to the obsolete prepare-time patching then, which involved the script.
> >>
> >> What a handy change.  That should make multiple architectures in one
> >> source tree finally possible without merge conflicts in that file.
> > 
> > Unfortunately not, if you want to work with the I-pipe git, you can
> > not run prepare-kernel.sh in that directory anyway, otherwise you
> > could end-up commiting the Xenomai fragments with the I-pipe kernel.
> 
> You can, we are doing this for ages. You only need to clean up your repo
> from the additional changes Xenomai introduced (a hand full) before
> moving HEAD (unless those files aren't affected by the move).

Sorry, but I prefer my obsolete method, I do not have anything to
run before using git commands. For me, the source directory
should remain untouched, I do not want any noise when I run git
status.

-- 
					    Gilles.

Re: [Xenomai] Xenomai-3 booting problems

[Jan Kiszka]

On 2015-01-22 15:42, Lennart Sorensen wrote:
> On Thu, Jan 22, 2015 at 09:34:11AM +0100, Leopold Palomo-Avellaneda wrote:
>> El Dijous, 22 de gener de 2015, a les 08:54:29, Gilles Chanteperdrix va 
>> escriure:
>>> On Thu, Jan 22, 2015 at 08:47:24AM +0100, Leopold Palomo-Avellaneda wrote:
>>>> Hi,
>>>>
>>>>
>>>> I have compiling a Cobalt kernel. I have followed the web "wikipress"
>>>> [1];-) recommendations. However, my box (a normal desktop computer - Dell
>>>> Optiplex 7010 -) doesn't boot. It throws a message like:
>>>> ....
>>>> timer doesn't work through interrup-remapped IO-apic
>>>>
>>>> ...
>>>>
>>>> enabling noapic in the boot options I'm able to boot. But, I have not make
>>>> any test by now. Some interesting messages:
>>>>
>>>> $ dmesg | grep -i xenomai
>>>> [    0.000000] Linux version 3.16.0-xenomai-3.0.0 (root@soho) (gcc version
>>>> 4.9.1 (Debian 4.9.1-19) ) #1 SMP Wed Jan 21 16:29:36 UTC 2015
>>>> [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-xenomai-3.0.0
>>>> root=UUID=15cfac82-1127-421f-9aed-eaf48247ed4e ro quiet noapic
>>>> [    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-
>>>> xenomai-3.0.0 root=UUID=15cfac82-1127-421f-9aed-eaf48247ed4e ro quiet
>>>> noapic [    0.705071] [Xenomai] scheduling class idle registered.
>>>> [    0.705072] [Xenomai] scheduling class rt registered.
>>>> [    0.705090] [Xenomai] disabling automatic C1E state promotion on Intel
>>>> processor
>>>> [    0.705104] [Xenomai] SMI-enabled chipset found, but SMI workaround
>>>> disabled
>>>>
>>>>           (see xenomai.smi parameter). You might encounter
>>>>
>>>> [    0.705284] I-pipe: head domain Xenomai registered.
>>>> [    0.717986] [Xenomai] Cobalt v3.0-rc2 (Exact Zero) [DEBUG]
>>>> [    0.897726] usb usb1: Manufacturer: Linux 3.16.0-xenomai-3.0.0 xhci_hcd
>>>> [    0.898617] usb usb2: Manufacturer: Linux 3.16.0-xenomai-3.0.0 xhci_hcd
>>>> [    0.914114] usb usb3: Manufacturer: Linux 3.16.0-xenomai-3.0.0 ehci_hcd
>>>> [    0.930109] usb usb4: Manufacturer: Linux 3.16.0-xenomai-3.0.0 ehci_hcd
>>>> *** RTnet for Xenomai v3.0-rc2 ***
>>>>
>>>>
>>>> So, can avoid to pass the noapic parameter to the kernel to boot?
>>>
>>> Please post the full boot logs, and the kernel configuration. 
>>
>> Attached.
>>
>>
>>> Does the
>>> kernel work with exactly the same .config but without Xenomai? 
>>
>> I don't know. It's a similar kernel configuration than debian ships with 
>> jessie.
>>
>>> Is
>>> CONFIG_SMP enabled? Because if CONFIG_SMP is enabled, Xenomai will
>>> not work without an APIC.
>>
>> Yes, CONFIG_SMP=y and CONFIG_X86_IO_APIC=y
> 
> But your kernel commandline included 'quiet noapic' in the above, which
> would turn of apic use even if the config could use it.

To make it clearer: NEVER use noapic on a modern x86 system. It neither
makes sense anymore nor will it work on many of them. It just routes the
system into rarely tested paths, both in the kernel and possibly also
the hardware and firmware.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Xenomai-3 creating debian packages

[Jan Kiszka]

On 2015-01-22 16:06, Gilles Chanteperdrix wrote:
> On Thu, Jan 22, 2015 at 04:02:36PM +0100, Jan Kiszka wrote:
>> On 2015-01-22 15:56, Gilles Chanteperdrix wrote:
>>> On Thu, Jan 22, 2015 at 09:49:30AM -0500, Lennart Sorensen wrote:
>>>> On Thu, Jan 22, 2015 at 01:51:46PM +0100, Jan Kiszka wrote:
>>>>> See
>>>>> http://git.xenomai.org/xenomai-jki.git/commit/?h=for-forge&id=5d104b1de84c8f4cbfb9d6b79cfaa633ef550e1c
>>>>> for the fix. The bug was the improper variable use in the Kconfig
>>>>> fragment. You only had to revert the whole commit as you were falling
>>>>> back to the obsolete prepare-time patching then, which involved the script.
>>>>
>>>> What a handy change.  That should make multiple architectures in one
>>>> source tree finally possible without merge conflicts in that file.
>>>
>>> Unfortunately not, if you want to work with the I-pipe git, you can
>>> not run prepare-kernel.sh in that directory anyway, otherwise you
>>> could end-up commiting the Xenomai fragments with the I-pipe kernel.
>>
>> You can, we are doing this for ages. You only need to clean up your repo
>> from the additional changes Xenomai introduced (a hand full) before
>> moving HEAD (unless those files aren't affected by the move).
> 
> Sorry, but I prefer my obsolete method, I do not have anything to
> run before using git commands. For me, the source directory
> should remain untouched, I do not want any noise when I run git
> status.

That's perfectly fine. We all have different working styles, and each
has its pros and cons.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Xenomai-3 booting problems

[Gilles Chanteperdrix]

On Thu, Jan 22, 2015 at 04:08:42PM +0100, Jan Kiszka wrote:
> On 2015-01-22 15:42, Lennart Sorensen wrote:
> > On Thu, Jan 22, 2015 at 09:34:11AM +0100, Leopold Palomo-Avellaneda wrote:
> >> El Dijous, 22 de gener de 2015, a les 08:54:29, Gilles Chanteperdrix va 
> >> escriure:
> >>> On Thu, Jan 22, 2015 at 08:47:24AM +0100, Leopold Palomo-Avellaneda wrote:
> >>>> Hi,
> >>>>
> >>>>
> >>>> I have compiling a Cobalt kernel. I have followed the web "wikipress"
> >>>> [1];-) recommendations. However, my box (a normal desktop computer - Dell
> >>>> Optiplex 7010 -) doesn't boot. It throws a message like:
> >>>> ....
> >>>> timer doesn't work through interrup-remapped IO-apic
> >>>>
> >>>> ...
> >>>>
> >>>> enabling noapic in the boot options I'm able to boot. But, I have not make
> >>>> any test by now. Some interesting messages:
> >>>>
> >>>> $ dmesg | grep -i xenomai
> >>>> [    0.000000] Linux version 3.16.0-xenomai-3.0.0 (root@soho) (gcc version
> >>>> 4.9.1 (Debian 4.9.1-19) ) #1 SMP Wed Jan 21 16:29:36 UTC 2015
> >>>> [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-xenomai-3.0.0
> >>>> root=UUID=15cfac82-1127-421f-9aed-eaf48247ed4e ro quiet noapic
> >>>> [    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-
> >>>> xenomai-3.0.0 root=UUID=15cfac82-1127-421f-9aed-eaf48247ed4e ro quiet
> >>>> noapic [    0.705071] [Xenomai] scheduling class idle registered.
> >>>> [    0.705072] [Xenomai] scheduling class rt registered.
> >>>> [    0.705090] [Xenomai] disabling automatic C1E state promotion on Intel
> >>>> processor
> >>>> [    0.705104] [Xenomai] SMI-enabled chipset found, but SMI workaround
> >>>> disabled
> >>>>
> >>>>           (see xenomai.smi parameter). You might encounter
> >>>>
> >>>> [    0.705284] I-pipe: head domain Xenomai registered.
> >>>> [    0.717986] [Xenomai] Cobalt v3.0-rc2 (Exact Zero) [DEBUG]
> >>>> [    0.897726] usb usb1: Manufacturer: Linux 3.16.0-xenomai-3.0.0 xhci_hcd
> >>>> [    0.898617] usb usb2: Manufacturer: Linux 3.16.0-xenomai-3.0.0 xhci_hcd
> >>>> [    0.914114] usb usb3: Manufacturer: Linux 3.16.0-xenomai-3.0.0 ehci_hcd
> >>>> [    0.930109] usb usb4: Manufacturer: Linux 3.16.0-xenomai-3.0.0 ehci_hcd
> >>>> *** RTnet for Xenomai v3.0-rc2 ***
> >>>>
> >>>>
> >>>> So, can avoid to pass the noapic parameter to the kernel to boot?
> >>>
> >>> Please post the full boot logs, and the kernel configuration. 
> >>
> >> Attached.
> >>
> >>
> >>> Does the
> >>> kernel work with exactly the same .config but without Xenomai? 
> >>
> >> I don't know. It's a similar kernel configuration than debian ships with 
> >> jessie.
> >>
> >>> Is
> >>> CONFIG_SMP enabled? Because if CONFIG_SMP is enabled, Xenomai will
> >>> not work without an APIC.
> >>
> >> Yes, CONFIG_SMP=y and CONFIG_X86_IO_APIC=y
> > 
> > But your kernel commandline included 'quiet noapic' in the above, which
> > would turn of apic use even if the config could use it.
> 
> To make it clearer: NEVER use noapic on a modern x86 system. It neither
> makes sense anymore nor will it work on many of them. It just routes the
> system into rarely tested paths, both in the kernel and possibly also
> the hardware and firmware.

It is worse than that, Xenomai without APIC does not work on SMP
systems. The only case where it could run would be if the system has
enough HPET timers, but I have never run Xenomai on a system where
this is true, except qemu-kvm where you can have as many hpet timers
as you want.

-- 
					    Gilles.

Re: [Xenomai] Xenomai-3 creating debian packages

[Lennart Sorensen]

On Thu, Jan 22, 2015 at 03:56:24PM +0100, Gilles Chanteperdrix wrote:
> Unfortunately not, if you want to work with the I-pipe git, you can
> not run prepare-kernel.sh in that directory anyway, otherwise you
> could end-up commiting the Xenomai fragments with the I-pipe kernel.

I meant as far as patches going from the ipipe and xenomai git trees
into my kernel tree for the end product.

As far as developing xenomai and ipipe, it very well might not be
solving anything.  I don't do that, so I wouldn't know.

-- 
Len Sorensen

Re: [Xenomai] Xenomai-3 creating debian packages

[Gilles Chanteperdrix]

On Thu, Jan 22, 2015 at 12:21:43PM -0500, Lennart Sorensen wrote:
> On Thu, Jan 22, 2015 at 03:56:24PM +0100, Gilles Chanteperdrix wrote:
> > Unfortunately not, if you want to work with the I-pipe git, you can
> > not run prepare-kernel.sh in that directory anyway, otherwise you
> > could end-up commiting the Xenomai fragments with the I-pipe kernel.
> 
> I meant as far as patches going from the ipipe and xenomai git trees
> into my kernel tree for the end product.
> 
> As far as developing xenomai and ipipe, it very well might not be
> solving anything.  I don't do that, so I wouldn't know.

Then I can tell you, using one I-pipe tree and one Xenomai tree for
multiple architectures has been possible for years, this is how I
develop on Xenomai.

-- 
					    Gilles.

Re: [Xenomai] Xenomai-3 creating debian packages

[Lennart Sorensen]

On Thu, Jan 22, 2015 at 08:16:40PM +0100, Gilles Chanteperdrix wrote:
> Then I can tell you, using one I-pipe tree and one Xenomai tree for
> multiple architectures has been possible for years, this is how I
> develop on Xenomai.

Well the patches for arm and patches for powerpc had a merge conflict
when applying the patch in init/Kconfig where both want to add 1 line
for source "arch/<current arch>/xenomai/Kconfig"

Everything else applies great (using the patches generated from the
xenomai tree with one patch for arm, one for powerpc and one for common).

-- 
Len Sorensen

Re: [Xenomai] Xenomai-3 creating debian packages

[Gilles Chanteperdrix]

On Thu, Jan 22, 2015 at 02:27:57PM -0500, Lennart Sorensen wrote:
> On Thu, Jan 22, 2015 at 08:16:40PM +0100, Gilles Chanteperdrix wrote:
> > Then I can tell you, using one I-pipe tree and one Xenomai tree for
> > multiple architectures has been possible for years, this is how I
> > develop on Xenomai.
> 
> Well the patches for arm and patches for powerpc had a merge conflict
> when applying the patch in init/Kconfig where both want to add 1 line
> for source "arch/<current arch>/xenomai/Kconfig"
> 
> Everything else applies great (using the patches generated from the
> xenomai tree with one patch for arm, one for powerpc and one for common).

When working with the I-pipe git, there is just one tree with all
the architecture changes in it. So, no need to apply patches. The
trick is to not run prepare-kernel on that tree, but on another tree
obtained with "lndir".

As for --split option of scripts/ipipe/genpatches.sh to generate a
separate the "noarch" patch, it is kind of obsolete now, since it
was made to help porting the I-pipe from one kernel to the next,
when we reapplied the I-pipe patch on top of the kernel to do that.
Since today we have adopted a "merge" workflow (which by the way
makes things much harder for an I-pipe maintainer), we no longer
need that option.

-- 
					    Gilles.

Re: [Xenomai] Xenomai-3 creating debian packages

[Lennart Sorensen]

On Thu, Jan 22, 2015 at 08:33:59PM +0100, Gilles Chanteperdrix wrote:
> When working with the I-pipe git, there is just one tree with all
> the architecture changes in it. So, no need to apply patches. The
> trick is to not run prepare-kernel on that tree, but on another tree
> obtained with "lndir".

Yeah I am pretty sure my ipipe patch is just a git diff against the
baseline linux tag.  Xenomai still seems to be easier to use with the
prepare script.

> As for --split option of scripts/ipipe/genpatches.sh to generate a
> separate the "noarch" patch, it is kind of obsolete now, since it
> was made to help porting the I-pipe from one kernel to the next,
> when we reapplied the I-pipe patch on top of the kernel to do that.
> Since today we have adopted a "merge" workflow (which by the way
> makes things much harder for an I-pipe maintainer), we no longer
> need that option.

That makes sense.

-- 
Len Sorensen