Menu
▾
▴
astlinux-devel — The AstLinux development environment, compilation, etc
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
(41) |
Apr
(35) |
May
(18) |
Jun
(5) |
Jul
(4) |
Aug
(37) |
Sep
(9) |
Oct
(20) |
Nov
(50) |
Dec
(217) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(212) |
Feb
(76) |
Mar
(113) |
Apr
(88) |
May
(130) |
Jun
(54) |
Jul
(208) |
Aug
(223) |
Sep
(112) |
Oct
(63) |
Nov
(131) |
Dec
(103) |
| 2010 |
Jan
(247) |
Feb
(130) |
Mar
(43) |
Apr
(92) |
May
(40) |
Jun
(43) |
Jul
(43) |
Aug
(80) |
Sep
(44) |
Oct
(74) |
Nov
(21) |
Dec
(46) |
| 2011 |
Jan
(36) |
Feb
(11) |
Mar
(21) |
Apr
(33) |
May
(4) |
Jun
(12) |
Jul
(5) |
Aug
(20) |
Sep
|
Oct
(64) |
Nov
(26) |
Dec
(71) |
| 2012 |
Jan
(13) |
Feb
(24) |
Mar
(11) |
Apr
(2) |
May
(10) |
Jun
(5) |
Jul
(13) |
Aug
(7) |
Sep
(26) |
Oct
(22) |
Nov
(17) |
Dec
(16) |
| 2013 |
Jan
(6) |
Feb
(6) |
Mar
(6) |
Apr
(8) |
May
(20) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(18) |
Oct
(3) |
Nov
(14) |
Dec
(33) |
| 2014 |
Jan
(26) |
Feb
(6) |
Mar
(69) |
Apr
(10) |
May
|
Jun
(8) |
Jul
(18) |
Aug
(22) |
Sep
(19) |
Oct
(17) |
Nov
|
Dec
(4) |
| 2015 |
Jan
(14) |
Feb
(18) |
Mar
|
Apr
|
May
(26) |
Jun
(8) |
Jul
(9) |
Aug
(10) |
Sep
(15) |
Oct
(2) |
Nov
(30) |
Dec
(33) |
| 2016 |
Jan
(1) |
Feb
(24) |
Mar
(19) |
Apr
(1) |
May
|
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(20) |
Oct
(5) |
Nov
(14) |
Dec
(4) |
| 2017 |
Jan
(15) |
Feb
(35) |
Mar
(10) |
Apr
(9) |
May
(14) |
Jun
(33) |
Jul
(1) |
Aug
(27) |
Sep
(7) |
Oct
|
Nov
(10) |
Dec
(15) |
| 2018 |
Jan
(29) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(11) |
Jun
|
Jul
(1) |
Aug
(8) |
Sep
(11) |
Oct
(22) |
Nov
(9) |
Dec
(13) |
| 2019 |
Jan
(1) |
Feb
(7) |
Mar
(3) |
Apr
(21) |
May
(34) |
Jun
(36) |
Jul
(18) |
Aug
(17) |
Sep
(19) |
Oct
(8) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(8) |
Apr
(29) |
May
(50) |
Jun
(8) |
Jul
(2) |
Aug
(10) |
Sep
(1) |
Oct
(7) |
Nov
(9) |
Dec
(19) |
| 2021 |
Jan
(2) |
Feb
(9) |
Mar
(6) |
Apr
(21) |
May
(13) |
Jun
(11) |
Jul
(2) |
Aug
(1) |
Sep
(3) |
Oct
(26) |
Nov
(2) |
Dec
(16) |
| 2022 |
Jan
(8) |
Feb
(7) |
Mar
(1) |
Apr
(13) |
May
(1) |
Jun
(4) |
Jul
(4) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2023 |
Jan
(2) |
Feb
(3) |
Mar
(16) |
Apr
|
May
(2) |
Jun
(1) |
Jul
(4) |
Aug
(13) |
Sep
(8) |
Oct
(6) |
Nov
(4) |
Dec
|
| 2024 |
Jan
(3) |
Feb
(3) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(5) |
Aug
|
Sep
(1) |
Oct
|
Nov
(5) |
Dec
|
| 2025 |
Jan
(4) |
Feb
(2) |
Mar
|
Apr
(11) |
May
(1) |
Jun
(9) |
Jul
(18) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: David K. <da...@ke...> - 2017-06-09 19:29:36
|
Just a heads up... This prerelease includes this bug... https://issues.asterisk.org/jira/browse/ASTERISK-27026 Work-around is to touch /etc/asterisk/ari.conf (ie, make sure that this file exists, even if empty) David On Fri, Jun 9, 2017 at 9:36 AM, Lonnie Abelbeck <li...@lo...> wrote: > Announcing Pre-Release Version: astlinux-1.0-8389 > > Significant update with Linux 3.16 kernel, will eventually become the new > AstLinux 1.3 series. > > The AstLinux Team is regularly upgrading packages containing security and > bug fixes as well as adding new features of our own. > > -- DHCPv6 with Prefix Delegation > http://doc.astlinux-project.org/userdoc:tt-dhcpv6-prefix-delegation > Note: If you previously enabled DHCPv6 in the Network tab -> Connection > Type, see IPv6 Autoconfig: "Assign GUA Prefix" reference. > > -- IPv6 ULA / NPTv6 Configuration > http://doc.astlinux-project.org/userdoc:tt_ipv6_ula_nptv6_config > > -- Traffic Shaper how uses fq_codel (Fair Queueing CoDel) for both 'htb' > and 'hfsc' types. Give 'hfsc' a try. > > -- The default serial baud rate is now 115200 instead of the previous > 19200. Upgrading RUNNIX will default to 115200. > > These pre-release images are for those who would like to take advantage of > the AstLinux development before the next official release, as well as > providing testing for the project. > > The "AstLinux Pre-Release ChangeLog" and "Repository URL" entries can be > found under the "Development" tab of the AstLinux Project web site ... > > AstLinux Project -> Development > http://www.astlinux-project.org/dev.html > > While these images are considered 'stable', the lack of testing will not > make these images suitable for critical production systems. > > If you should come across an issue, please report back here. > > AstLinux Team > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > |
|
From: Lonnie A. <li...@lo...> - 2017-06-09 13:37:04
|
Announcing Pre-Release Version: astlinux-1.0-8389 Significant update with Linux 3.16 kernel, will eventually become the new AstLinux 1.3 series. The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own. -- DHCPv6 with Prefix Delegation http://doc.astlinux-project.org/userdoc:tt-dhcpv6-prefix-delegation Note: If you previously enabled DHCPv6 in the Network tab -> Connection Type, see IPv6 Autoconfig: "Assign GUA Prefix" reference. -- IPv6 ULA / NPTv6 Configuration http://doc.astlinux-project.org/userdoc:tt_ipv6_ula_nptv6_config -- Traffic Shaper how uses fq_codel (Fair Queueing CoDel) for both 'htb' and 'hfsc' types. Give 'hfsc' a try. -- The default serial baud rate is now 115200 instead of the previous 19200. Upgrading RUNNIX will default to 115200. These pre-release images are for those who would like to take advantage of the AstLinux development before the next official release, as well as providing testing for the project. The "AstLinux Pre-Release ChangeLog" and "Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ... AstLinux Project -> Development http://www.astlinux-project.org/dev.html While these images are considered 'stable', the lack of testing will not make these images suitable for critical production systems. If you should come across an issue, please report back here. AstLinux Team |
|
From: Lonnie A. <li...@lo...> - 2017-06-02 21:43:13
|
Hi Luigi, Good you got it working without 'rhino' enabled. I made a change to rhino.mk in the build system, Revision: 8368 https://sourceforge.net/p/astlinux/code/8368 If you have a chance, "svn up" and "make rhino" and see if the fix solves your problem. Lonnie On Jun 2, 2017, at 2:58 PM, Luigi Porto <ope...@gm...> wrote: > > > 2017-06-02 18:06 GMT+02:00 Lonnie Abelbeck <li...@lo...>: > Hi Luigi, > > It is the "rhino" package that is failing for you, but interestingly it works for me: > -- > Making firmware object file for GpakDsp.fw > LD [M] /home/dev/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/rxt1/rxt1.o > Building modules, stage 2. > MODPOST 3 modules > -- > > Quick fix is you can disable "rhino" in your .config, ex. "# BR2_PACKAGE_RHINO is not set" > > Possibly we need to set LD in the makefile ... > > I'll look into this. Thanks for the report ! > > Lonnie > > > Hello Lonnie, thank you for the reply. > > Recap: > > 1. I've also tried with a VM Debian, same problem. > 2. RHINO commented in .config . > 3. Rebuild, all done! > 4. wget cisco-usecallmanager-13.15.0.patch in package/asterisk/ > 5. renaming cisco-usecallmanager-13.15.0.patch in asterisk-13-cisco-usecallmanager-13.15.0.patch > 6. In asterisk.mk version changed from 13.15.1 to 13.15.0 > > 1st little trouble: asterisk-13-cisco-usecallmanager-13.15.0.patch and asterisk-13-extension-changed-verbosity-chan_sip.patch collide in build process, at the moment i renamed asterisk-13-extension-changed-verbosity-chan_sip.patch.NOPATCH, all done. |
|
From: Luigi P. <ope...@gm...> - 2017-06-02 19:58:28
|
2017-06-02 18:06 GMT+02:00 Lonnie Abelbeck <li...@lo...>: > Hi Luigi, > > It is the "rhino" package that is failing for you, but interestingly it > works for me: > -- > Making firmware object file for GpakDsp.fw > LD [M] /home/dev/astlinux/1.0/output/build/rhino-linux-0.99.7/ > drivers/rhino/rxt1/rxt1.o > Building modules, stage 2. > MODPOST 3 modules > -- > > Quick fix is you can disable "rhino" in your .config, ex. "# > BR2_PACKAGE_RHINO is not set" > > Possibly we need to set LD in the makefile ... > > I'll look into this. Thanks for the report ! > > Lonnie > > Hello Lonnie, thank you for the reply. Recap: 1. I've also tried with a VM Debian, same problem. 2. RHINO commented in .config . 3. Rebuild, all done! 4. wget cisco-usecallmanager-13.15.0.patch in package/asterisk/ 5. renaming cisco-usecallmanager-13.15.0.patch in asterisk-13-cisco-usecallmanager-13.15.0.patch 6. In asterisk.mk version changed from 13.15.1 to 13.15.0 1st little trouble: asterisk-13-cisco-usecallmanager-13.15.0.patch and asterisk-13-extension-changed-verbosity-chan_sip.patch collide in build process, at the moment i renamed asterisk-13-extension-changed-verbosity-chan_sip.patch.NOPATCH, all done. -- #musk from calabria.ninux.org - CS @openmusk |
|
From: Lonnie A. <li...@lo...> - 2017-06-02 16:06:28
|
Hi Luigi, It is the "rhino" package that is failing for you, but interestingly it works for me: -- Making firmware object file for GpakDsp.fw LD [M] /home/dev/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/rxt1/rxt1.o Building modules, stage 2. MODPOST 3 modules -- Quick fix is you can disable "rhino" in your .config, ex. "# BR2_PACKAGE_RHINO is not set" Possibly we need to set LD in the makefile ... I'll look into this. Thanks for the report ! Lonnie On Jun 2, 2017, at 10:39 AM, Luigi Porto <ope...@gm...> wrote: > Hello, > I have an error when trying to compile Astlinux, both geni586 and genx86_64. > > System: VM fresh install in VMWare Workstations CentOS latest updated minimal, packages listed in https://doc.astlinux-project.org/devdoc:packages regularly installed > > https://astlinux.svn.sourceforge.net/svnroot/astlinux/branches/1.0/crosstool-ng-src/README performed correctly > > Output ./scripts/build : > > /usr/bin/install -m 644 -D /home/musk/astlinux/1.0/output/build/r8168-8.044.02/src/r8168.ko /home/musk/astlinux/1.0/output/target/lib/modules/3.16.43-astlinu x/kernel/drivers/net/ethernet/realtek/r8168.ko > /home/musk/astlinux/1.0/output/host/usr/sbin/depmod -ae -F /home/musk/astlinux/1.0/output/build/linux-custom/System.map -b /home/musk/astlinux/1.0/output/tar get -r 3.16.43-astlinux > bzcat /home/musk/astlinux/1.0/dl/rhino-linux-0.99.7.tbz2 | tar -C /home/musk/astlinux/1.0/output/build -xf - > touch /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/.source > toolchain/patch-kernel.sh /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7 package/rhino/ rhino-\*.patch > cp -a /home/musk/astlinux/1.0/output/build/dahdi-linux-2.8.0.1/drivers/dahdi/Module.symvers /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/r hino/Module.symvers > touch /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/.patched > /usr/bin/make -j1 -C /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7 \ > HOSTCC=gcc CC=/home/musk/astlinux/1.0/output/host/usr/bin/x86_64-unknown-linux-gnu-gcc ARCH=x86_64 \ > KVER=3.16.43-astlinux PWD=/home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7 \ > KSRC=/home/musk/astlinux/1.0/output/build/linux-custom LEGACY_MODULES="r4fxo" \ > MODULES="r1t1 rxt1 rcbfx" KMOD=/home/musk/astlinux/1.0/output/target/lib/modules/3.16.43-astlinux \ > KINCLUDES=/home/musk/astlinux/1.0/output/host/usr/x86_64-unknown-linux-gnu/sysroot/include \ > KINSTDIR=/lib/modules/3.16.43-astlinux/kernel \ > INSTALL_PREFIX=/home/musk/astlinux/1.0/output/target \ > DAHDI_DIR=/home/musk/astlinux/1.0/output/build/dahdi-linux-2.8.0.1 \ > all > make[1]: Entering directory `/home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7' > Makefile:92: [ () ()] /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7 > Probing /home/musk/astlinux/1.0/output/build/dahdi-linux-2.8.0.1 for DAHDI version > Found version.h at /home/musk/astlinux/1.0/output/build/dahdi-linux-2.8.0.1/include/dahdi/version.h > Compiling against DAHDI version 133120 - 2.8.0.1 > /usr/bin/make -C /home/musk/astlinux/1.0/output/build/linux-custom ARCH=x86_64 SUBDIRS=/home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino RHINO_INCLUDE=/home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/include DAHDI_INCLUDE=/home/musk/astlinux/1.0/output/build/dahdi-linux-2.8.0.1/include DAHDI_SRC=/home/musk/astlinux/1.0/output/build/dahdi-linux-2.8.0.1/drivers/dahdi DAHDI_VER=133120 KBUILD_EXTRA_SYMBOLS=/home/musk/astlinux/1.0/output/build/d ahdi-linux-2.8.0.1/drivers/dahdi/Module.symvers modules > make[2]: Entering directory `/home/musk/astlinux/1.0/output/build/linux-custom' > CC [M] /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/r1t1_base.o > CC [M] /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.o > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c: In function 'gpakConfigurePorts': > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c:593:1: warning: the frame size of 2000 bytes is larger than 1024 bytes [ -Wframe-larger-than=] > } > ^ > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c: In function 'gpakConfigureChannel': > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c:747:1: warning: the frame size of 2000 bytes is larger than 1024 bytes [ -Wframe-larger-than=] > } > ^ > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c: In function 'gpakTearDownChannel': > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c:792:1: warning: the frame size of 2000 bytes is larger than 1024 bytes [ -Wframe-larger-than=] > } > ^ > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c: In function 'gpakAlgControl': > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c:841:1: warning: the frame size of 2000 bytes is larger than 1024 bytes [ -Wframe-larger-than=] > } > ^ > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c: In function 'gpakPingDsp': > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c:1007:1: warning: the frame size of 2000 bytes is larger than 1024 bytes [-Wframe-larger-than=] > } > ^ > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c: In function 'gpakSerialTxFixedValue': > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c:1059:1: warning: the frame size of 2000 bytes is larger than 1024 bytes [-Wframe-larger-than=] > } > ^ > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c: In function 'gpakControlTdmLoopBack': > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c:1103:1: warning: the frame size of 2000 bytes is larger than 1024 bytes [-Wframe-larger-than=] > } > ^ > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c: In function 'gpakResetCpuUsageStats': > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c:1184:1: warning: the frame size of 2000 bytes is larger than 1024 bytes [-Wframe-larger-than=] > } > ^ > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c: In function 'gpakResetFramingStats': > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c:1284:1: warning: the frame size of 2000 bytes is larger than 1024 bytes [-Wframe-larger-than=] > } > ^ > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c: In function 'gpakReadDSPMemoryMap': > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c:1450:1: warning: the frame size of 2000 bytes is larger than 1024 bytes [-Wframe-larger-than=] > } > ^ > CC [M] /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakCust.o > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakCust.c: In function 'gpakReadFile_5510': > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakCust.c:308:15: warning: cast from pointer to integer of different size [-Wpoin ter-to-int-cast] > file_size = (unsigned int) &_binary_GpakDsp_fw_size; > ^ > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakCust.c:311:7: warning: cast from pointer to integer of different size [-Wpoint er-to-int-cast] > (unsigned int) &_binary_GpakDsp_fw_size, > ^ > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakCust.c:312:7: warning: cast from pointer to integer of different size [-Wpoint er-to-int-cast] > (unsigned int) &_binary_GpakDsp_fw_size); > ^ > Making firmware object file for GpakDsp.fw > objcopy: architettura -O sconosciuta > make[4]: *** [/home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakDsp.o] Errore 1 > make[3]: *** [/home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1] Errore 2 > make[2]: *** [_module_/home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino] Errore 2 > make[2]: Leaving directory `/home/musk/astlinux/1.0/output/build/linux-custom' > make[1]: *** [modules] Errore 2 > make[1]: Leaving directory `/home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7' > make: *** [/home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/.built] Errore 2 > > real 71m32.829s > user 54m47.766s > sys 20m0.550s > build: Incomplete build, no AstLinux Release for you. > [musk@localhost 1.0]$ > > > The only change I did was add cisco-usecallmanager-13.15.0.patch && changing in asterisk.mk the version in 13.15.0.. i don't think it's related.. > > > -- > #musk from calabria.ninux.org - CS > > @openmusk > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Luigi P. <ope...@gm...> - 2017-06-02 15:39:10
|
Hello, I have an error when trying to compile Astlinux, both geni586 and genx86_64. System: VM fresh install in VMWare Workstations CentOS latest updated minimal, packages listed in https://doc.astlinux-project.org/devdoc:packages regularly installed https://astlinux.svn.sourceforge.net/svnroot/astlinux/branches/1.0/crosstool-ng-src/README performed correctly Output ./scripts/build : /usr/bin/install -m 644 -D > /home/musk/astlinux/1.0/output/build/r8168-8.044.02/src/r8168.ko > /home/musk/astlinux/1.0/output/target/lib/modules/3.16.43-astlinu > x/kernel/drivers/net/ethernet/realtek/r8168.ko > /home/musk/astlinux/1.0/output/host/usr/sbin/depmod -ae -F > /home/musk/astlinux/1.0/output/build/linux-custom/System.map -b > /home/musk/astlinux/1.0/output/tar > get -r 3.16.43-astlinux > bzcat /home/musk/astlinux/1.0/dl/rhino-linux-0.99.7.tbz2 | tar -C > /home/musk/astlinux/1.0/output/build -xf - > touch /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/.source > toolchain/patch-kernel.sh > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7 package/rhino/ > rhino-\*.patch > cp -a > /home/musk/astlinux/1.0/output/build/dahdi-linux-2.8.0.1/drivers/dahdi/Module.symvers > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/r > hino/Module.symvers > touch /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/.patched > /usr/bin/make -j1 -C > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7 \ > HOSTCC=gcc > CC=/home/musk/astlinux/1.0/output/host/usr/bin/x86_64-unknown-linux-gnu-gcc > ARCH=x86_64 \ > KVER=3.16.43-astlinux > PWD=/home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7 \ > KSRC=/home/musk/astlinux/1.0/output/build/linux-custom > LEGACY_MODULES="r4fxo" \ > MODULES="r1t1 rxt1 rcbfx" > KMOD=/home/musk/astlinux/1.0/output/target/lib/modules/3.16.43-astlinux \ > > KINCLUDES=/home/musk/astlinux/1.0/output/host/usr/x86_64-unknown-linux-gnu/sysroot/include > \ > KINSTDIR=/lib/modules/3.16.43-astlinux/kernel \ > INSTALL_PREFIX=/home/musk/astlinux/1.0/output/target \ > DAHDI_DIR=/home/musk/astlinux/1.0/output/build/dahdi-linux-2.8.0.1 > \ > all > make[1]: Entering directory > `/home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7' > Makefile:92: [ () ()] > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7 > Probing /home/musk/astlinux/1.0/output/build/dahdi-linux-2.8.0.1 for DAHDI > version > Found version.h at > /home/musk/astlinux/1.0/output/build/dahdi-linux-2.8.0.1/include/dahdi/version.h > Compiling against DAHDI version 133120 - 2.8.0.1 > /usr/bin/make -C /home/musk/astlinux/1.0/output/build/linux-custom > ARCH=x86_64 > SUBDIRS=/home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino > RHINO_INCLUDE=/home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/include > DAHDI_INCLUDE=/home/musk/astlinux/1.0/output/build/dahdi-linux-2.8.0.1/include > DAHDI_SRC=/home/musk/astlinux/1.0/output/build/dahdi-linux-2.8.0.1/drivers/dahdi > DAHDI_VER=133120 > KBUILD_EXTRA_SYMBOLS=/home/musk/astlinux/1.0/output/build/d > ahdi-linux-2.8.0.1/drivers/dahdi/Module.symvers modules > make[2]: Entering directory > `/home/musk/astlinux/1.0/output/build/linux-custom' > CC [M] > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/r1t1_base.o > CC [M] > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.o > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c: > In function 'gpakConfigurePorts': > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c:593:1: > warning: the frame size of 2000 bytes is larger than 1024 bytes > [ > -Wframe-larger-than=] > } > ^ > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c: > In function 'gpakConfigureChannel': > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c:747:1: > warning: the frame size of 2000 bytes is larger than 1024 bytes > [ > -Wframe-larger-than=] > } > ^ > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c: > In function 'gpakTearDownChannel': > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c:792:1: > warning: the frame size of 2000 bytes is larger than 1024 bytes > [ > -Wframe-larger-than=] > } > ^ > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c: > In function 'gpakAlgControl': > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c:841:1: > warning: the frame size of 2000 bytes is larger than 1024 bytes > [ > -Wframe-larger-than=] > } > ^ > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c: > In function 'gpakPingDsp': > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c:1007:1: > warning: the frame size of 2000 bytes is larger than 1024 > bytes > [-Wframe-larger-than=] > } > ^ > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c: > In function 'gpakSerialTxFixedValue': > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c:1059:1: > warning: the frame size of 2000 bytes is larger than 1024 > bytes > [-Wframe-larger-than=] > } > ^ > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c: > In function 'gpakControlTdmLoopBack': > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c:1103:1: > warning: the frame size of 2000 bytes is larger than 1024 > bytes > [-Wframe-larger-than=] > } > ^ > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c: > In function 'gpakResetCpuUsageStats': > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c:1184:1: > warning: the frame size of 2000 bytes is larger than 1024 > bytes > [-Wframe-larger-than=] > } > ^ > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c: > In function 'gpakResetFramingStats': > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c:1284:1: > warning: the frame size of 2000 bytes is larger than 1024 > bytes > [-Wframe-larger-than=] > } > ^ > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c: > In function 'gpakReadDSPMemoryMap': > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakApi.c:1450:1: > warning: the frame size of 2000 bytes is larger than 1024 > bytes > [-Wframe-larger-than=] > } > ^ > CC [M] > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakCust.o > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakCust.c: > In function 'gpakReadFile_5510': > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakCust.c:308:15: > warning: cast from pointer to integer of different size > [-Wpoin > ter-to-int-cast] > file_size = (unsigned int) &_binary_GpakDsp_fw_size; > ^ > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakCust.c:311:7: > warning: cast from pointer to integer of different size > [-Wpoint > er-to-int-cast] > (unsigned int) &_binary_GpakDsp_fw_size, > ^ > /home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakCust.c:312:7: > warning: cast from pointer to integer of different size > [-Wpoint > er-to-int-cast] > (unsigned int) &_binary_GpakDsp_fw_size); > ^ > Making firmware object file for GpakDsp.fw > objcopy: architettura -O sconosciuta > make[4]: *** > [/home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1/GpakDsp.o] > Errore 1 > make[3]: *** > [/home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino/r1t1] > Errore 2 > make[2]: *** > [_module_/home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/drivers/rhino] > Errore 2 > make[2]: Leaving directory > `/home/musk/astlinux/1.0/output/build/linux-custom' > make[1]: *** [modules] Errore 2 > make[1]: Leaving directory > `/home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7' > make: *** [/home/musk/astlinux/1.0/output/build/rhino-linux-0.99.7/.built] > Errore 2 > > real 71m32.829s > user 54m47.766s > sys 20m0.550s > build: Incomplete build, no AstLinux Release for you. > [musk@localhost 1.0]$ > > The only change I did was add cisco-usecallmanager-13.15.0.patch && changing in asterisk.mk the version in 13.15.0.. i don't think it's related.. -- #musk from calabria.ninux.org - CS @openmusk |
|
From: Lonnie A. <li...@lo...> - 2017-06-02 01:31:08
|
On Jun 1, 2017, at 7:21 PM, David Kerr <Da...@Ke...> wrote: > Okay, so... occasionally I replace a file in e.g. /usr/sbin while testing some change I may have made. When that change is eventually incorporated into the build tree I am in the habit of going into /oldroot/mnt/asturw/usr and then rm -rf sbin. > > I think you are saying that this is bad? Right? I used to do that as well, don't remove any directories, though removing a file is fine. I found this out by cleaning-up after editing the traffic shaper plugin for testing. -- Rule: Never remove a directory in the path '/oldroot/mnt/asturw/...' -- > So instead I should go into /oldroot/mnt/asturw/usr/sbin and rm the file, and just leave the sbin directory alone? Yes, to help, the new "show-union" will not show you the empty directories anymore. Simply ignore the ASTURW empty directories. Some day we may consider automatically cleaning up these empty directories if we ever thought they could be a problem, but a non-issue today. That would have to be done in the initrd. > What are the consequences of erasing the directory? And if I do erase a directory will a reboot make things okay again? It seems any open file in the path will get flushed from memory, typically the AIF plugin helper scripts will be effected if '/oldroot/mnt/asturw/usr/...' and as such you won't get a clean shutdown, you will need to power cycle the box. We can hope the unionfs folks will generate a new set of patches, but I would expect we just need to live with this. As I recall, many years ago in the Linux 2.6 days. several versions of unionfs ago, this same problem existed. Lonnie > Thanks > David > > On Thu, Jun 1, 2017 at 9:55 AM, Lonnie Abelbeck <li...@lo...> wrote: > Hi Devs, > > First, it has been 10 days since we bumped the kernel to 3.16.43, and things appear to be running solid at this point, much thanks for all the assistance in getting this major task accomplished. > > Though I ran across a glitch, with unionfs, basically you no longer can remove a *directory* in the path '/oldroot/mnt/asturw/...' as unionfs with kernel 3.16 has an issue with that. Such a deletion now also effects open files in the same path, in memory. > > Removing a *file* in the '/oldroot/mnt/asturw/...' path appears to be OK, which is important, since that is the only way to "undo" an edit of a file on '/oldroot/mnt/asturo/...' > > I sent an email to Erez Zadok at Stony Brook University as well as the unionfs mailing list, where I go into more detail. > > [Unionfs] unionfs with Linux 3.16 > http://www.fsl.cs.sunysb.edu/pipermail/unionfs/2017-May/006196.html > > I looked over our scripts and we only needed a few changes to implement the new rule: > -- > Rule: Never remove a directory in the path '/oldroot/mnt/asturw/...' > -- > (Revision: 8361) > > The 'show-union' command now only shows files, so as not to encourage directory removal, except 'show-union all' shows directories as well. > > Any stale directories on ASTURW should not happen for normal users in production, but during development it can be handy to edit ASTURO files, so if you wanted to remove these stale directories (leaving them be is fine) you need to reboot to RUNNIX and mount /dev/sda2 as -t ext2. > > Lonnie > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: David K. <da...@ke...> - 2017-06-02 00:21:40
|
Okay, so... occasionally I replace a file in e.g. /usr/sbin while testing some change I may have made. When that change is eventually incorporated into the build tree I am in the habit of going into /oldroot/mnt/asturw/usr and then rm -rf sbin. I think you are saying that this is bad? Right? So instead I should go into /oldroot/mnt/asturw/usr/sbin and rm the file, and just leave the sbin directory alone? What are the consequences of erasing the directory? And if I do erase a directory will a reboot make things okay again? Thanks David On Thu, Jun 1, 2017 at 9:55 AM, Lonnie Abelbeck <li...@lo...> wrote: > Hi Devs, > > First, it has been 10 days since we bumped the kernel to 3.16.43, and > things appear to be running solid at this point, much thanks for all the > assistance in getting this major task accomplished. > > Though I ran across a glitch, with unionfs, basically you no longer can > remove a *directory* in the path '/oldroot/mnt/asturw/...' as unionfs with > kernel 3.16 has an issue with that. Such a deletion now also effects open > files in the same path, in memory. > > Removing a *file* in the '/oldroot/mnt/asturw/...' path appears to be OK, > which is important, since that is the only way to "undo" an edit of a file > on '/oldroot/mnt/asturo/...' > > I sent an email to Erez Zadok at Stony Brook University as well as the > unionfs mailing list, where I go into more detail. > > [Unionfs] unionfs with Linux 3.16 > http://www.fsl.cs.sunysb.edu/pipermail/unionfs/2017-May/006196.html > > I looked over our scripts and we only needed a few changes to implement > the new rule: > -- > Rule: Never remove a directory in the path '/oldroot/mnt/asturw/...' > -- > (Revision: 8361) > > The 'show-union' command now only shows files, so as not to encourage > directory removal, except 'show-union all' shows directories as well. > > Any stale directories on ASTURW should not happen for normal users in > production, but during development it can be handy to edit ASTURO files, so > if you wanted to remove these stale directories (leaving them be is fine) > you need to reboot to RUNNIX and mount /dev/sda2 as -t ext2. > > Lonnie > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > |
|
From: Lonnie A. <li...@lo...> - 2017-06-01 23:56:11
|
Michael, Possibly we can generate some early test builds in a few weeks to allow more people to play with the new stuff. Your DSL connections are a great test for the traffic shaping. The fq_codel qdisc is made possible by the Kernel 3.16 bump. Lonnie On Jun 1, 2017, at 6:50 PM, Michael Knill <mic...@ip...> wrote: > Thanks Lonnie. > > Im looking forward to testing it out. > > Regards > Michael Knill > > -----Original Message----- > From: Lonnie Abelbeck <li...@lo...> > Reply-To: AstLinux Developers Mailing List <ast...@li...> > Date: Friday, 2 June 2017 at 9:46 am > To: AstLinux Developers Mailing List <ast...@li...> > Subject: Re: [Astlinux-devel] traffic-shaper: fq_codel (Fair Queueing CoDel) > > Hi Michael, > > Basically yes, though this shaping stuff seems more of an art than a science. > > The 'htb' has some built-in reservation for priority traffic, for my 10 Mbps up it had a little too much reserved so I ended up setting the Uplink speed to 12000, though if you had a lower speed and a lot of voice traffic you might set it to less than the measured uplink speed. > > For the 'hfsc' shaper it is somewhat more dynamic, so setting it to the uplink speed is a good first guess (my ISP uplink is measured a little over 10 Mbps), but if you had a lot of voice traffic you may need to bump it down somewhat. > > For example using the 'hfsc' shaper, I maxed out the uplink with a HTTP speed test and ran a SIP call out and back, you could see the up max-speed test drop (minus one side of the SIP traffic) while the SIP call was smooth. > > Regardless it takes a little trial and error testing. > > Lonnie > > > On Jun 1, 2017, at 5:49 PM, Michael Knill <mic...@ip...> wrote: > >> Hi Lonnie >> >> Thanks again for all your work. >> >> So with htb you shape default traffic to the Line Rate (or line CIR) minus Required Voice Bandwidth (e.g. 100K G.711 x max sessions). But with hfsc, you set it to the Line Rate (or line CIR) and default traffic has access to the full Line Rate while there is no voice traffic. Is this correct? >> >> Regards >> Michael Knill >> >> From: Lonnie Abelbeck <li...@lo...> >> Reply-To: AstLinux Developers Mailing List <ast...@li...> >> Date: Friday, 2 June 2017 at 8:31 am >> To: AstLinux Developers Mailing List <ast...@li...> >> Subject: [Astlinux-devel] traffic-shaper: fq_codel (Fair Queueing CoDel) >> >> Hi Devs, >> >> A quick note, as of r8362, the "traffic-shaper" plugin, now uses the fq_codel (Fair Queueing CoDel) for both 'htb' and 'hfsc' types. >> >> In the past, many of us have found the 'hfsc' shaper not as good as expected. With the addition of fq_codel the 'hfsc' shaper type works much better than before in my limited testing. >> >> Personally I have a 50/10 Mbps cable connection, so I set the Uplink Speed to 10000 and disabled any ingress shaping, ex. >> >> PastedGraphic-1.tiff >> >> Testing this sort of shaping stuff is difficult to do, but so far is working well for me. >> >> Everyone reading this should do some tests of their own. >> >> Lonnie >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > |
|
From: Michael K. <mic...@ip...> - 2017-06-01 23:50:13
|
Thanks Lonnie. Im looking forward to testing it out. Regards Michael Knill -----Original Message----- From: Lonnie Abelbeck <li...@lo...> Reply-To: AstLinux Developers Mailing List <ast...@li...> Date: Friday, 2 June 2017 at 9:46 am To: AstLinux Developers Mailing List <ast...@li...> Subject: Re: [Astlinux-devel] traffic-shaper: fq_codel (Fair Queueing CoDel) Hi Michael, Basically yes, though this shaping stuff seems more of an art than a science. The 'htb' has some built-in reservation for priority traffic, for my 10 Mbps up it had a little too much reserved so I ended up setting the Uplink speed to 12000, though if you had a lower speed and a lot of voice traffic you might set it to less than the measured uplink speed. For the 'hfsc' shaper it is somewhat more dynamic, so setting it to the uplink speed is a good first guess (my ISP uplink is measured a little over 10 Mbps), but if you had a lot of voice traffic you may need to bump it down somewhat. For example using the 'hfsc' shaper, I maxed out the uplink with a HTTP speed test and ran a SIP call out and back, you could see the up max-speed test drop (minus one side of the SIP traffic) while the SIP call was smooth. Regardless it takes a little trial and error testing. Lonnie On Jun 1, 2017, at 5:49 PM, Michael Knill <mic...@ip...> wrote: > Hi Lonnie > > Thanks again for all your work. > > So with htb you shape default traffic to the Line Rate (or line CIR) minus Required Voice Bandwidth (e.g. 100K G.711 x max sessions). But with hfsc, you set it to the Line Rate (or line CIR) and default traffic has access to the full Line Rate while there is no voice traffic. Is this correct? > > Regards > Michael Knill > > From: Lonnie Abelbeck <li...@lo...> > Reply-To: AstLinux Developers Mailing List <ast...@li...> > Date: Friday, 2 June 2017 at 8:31 am > To: AstLinux Developers Mailing List <ast...@li...> > Subject: [Astlinux-devel] traffic-shaper: fq_codel (Fair Queueing CoDel) > > Hi Devs, > > A quick note, as of r8362, the "traffic-shaper" plugin, now uses the fq_codel (Fair Queueing CoDel) for both 'htb' and 'hfsc' types. > > In the past, many of us have found the 'hfsc' shaper not as good as expected. With the addition of fq_codel the 'hfsc' shaper type works much better than before in my limited testing. > > Personally I have a 50/10 Mbps cable connection, so I set the Uplink Speed to 10000 and disabled any ingress shaping, ex. > > PastedGraphic-1.tiff > > Testing this sort of shaping stuff is difficult to do, but so far is working well for me. > > Everyone reading this should do some tests of their own. > > Lonnie > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Lonnie A. <li...@lo...> - 2017-06-01 23:46:45
|
Hi Michael, Basically yes, though this shaping stuff seems more of an art than a science. The 'htb' has some built-in reservation for priority traffic, for my 10 Mbps up it had a little too much reserved so I ended up setting the Uplink speed to 12000, though if you had a lower speed and a lot of voice traffic you might set it to less than the measured uplink speed. For the 'hfsc' shaper it is somewhat more dynamic, so setting it to the uplink speed is a good first guess (my ISP uplink is measured a little over 10 Mbps), but if you had a lot of voice traffic you may need to bump it down somewhat. For example using the 'hfsc' shaper, I maxed out the uplink with a HTTP speed test and ran a SIP call out and back, you could see the up max-speed test drop (minus one side of the SIP traffic) while the SIP call was smooth. Regardless it takes a little trial and error testing. Lonnie On Jun 1, 2017, at 5:49 PM, Michael Knill <mic...@ip...> wrote: > Hi Lonnie > > Thanks again for all your work. > > So with htb you shape default traffic to the Line Rate (or line CIR) minus Required Voice Bandwidth (e.g. 100K G.711 x max sessions). But with hfsc, you set it to the Line Rate (or line CIR) and default traffic has access to the full Line Rate while there is no voice traffic. Is this correct? > > Regards > Michael Knill > > From: Lonnie Abelbeck <li...@lo...> > Reply-To: AstLinux Developers Mailing List <ast...@li...> > Date: Friday, 2 June 2017 at 8:31 am > To: AstLinux Developers Mailing List <ast...@li...> > Subject: [Astlinux-devel] traffic-shaper: fq_codel (Fair Queueing CoDel) > > Hi Devs, > > A quick note, as of r8362, the "traffic-shaper" plugin, now uses the fq_codel (Fair Queueing CoDel) for both 'htb' and 'hfsc' types. > > In the past, many of us have found the 'hfsc' shaper not as good as expected. With the addition of fq_codel the 'hfsc' shaper type works much better than before in my limited testing. > > Personally I have a 50/10 Mbps cable connection, so I set the Uplink Speed to 10000 and disabled any ingress shaping, ex. > > PastedGraphic-1.tiff > > Testing this sort of shaping stuff is difficult to do, but so far is working well for me. > > Everyone reading this should do some tests of their own. > > Lonnie > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <mic...@ip...> - 2017-06-01 22:49:25
|
Hi Lonnie Thanks again for all your work. So with htb you shape default traffic to the Line Rate (or line CIR) minus Required Voice Bandwidth (e.g. 100K G.711 x max sessions). But with hfsc, you set it to the Line Rate (or line CIR) and default traffic has access to the full Line Rate while there is no voice traffic. Is this correct? Regards Michael Knill From: Lonnie Abelbeck <li...@lo...> Reply-To: AstLinux Developers Mailing List <ast...@li...> Date: Friday, 2 June 2017 at 8:31 am To: AstLinux Developers Mailing List <ast...@li...> Subject: [Astlinux-devel] traffic-shaper: fq_codel (Fair Queueing CoDel) Hi Devs, A quick note, as of r8362, the "traffic-shaper" plugin, now uses the fq_codel (Fair Queueing CoDel) for both 'htb' and 'hfsc' types. In the past, many of us have found the 'hfsc' shaper not as good as expected. With the addition of fq_codel the 'hfsc' shaper type works much better than before in my limited testing. Personally I have a 50/10 Mbps cable connection, so I set the Uplink Speed to 10000 and disabled any ingress shaping, ex. PastedGraphic-1.tiff<cid:475...@pr...> Testing this sort of shaping stuff is difficult to do, but so far is working well for me. Everyone reading this should do some tests of their own. Lonnie |
|
From: Lonnie A. <li...@lo...> - 2017-06-01 22:31:27
|
Hi Devs, A quick note, as of r8362, the "traffic-shaper" plugin, now uses the fq_codel (Fair Queueing CoDel) for both 'htb' and 'hfsc' types. In the past, many of us have found the 'hfsc' shaper not as good as expected. With the addition of fq_codel the 'hfsc' shaper type works much better than before in my limited testing. Personally I have a 50/10 Mbps cable connection, so I set the Uplink Speed to 10000 and disabled any ingress shaping, ex. Testing this sort of shaping stuff is difficult to do, but so far is working well for me. Everyone reading this should do some tests of their own. Lonnie |
|
From: Lonnie A. <li...@lo...> - 2017-06-01 13:55:27
|
Hi Devs, First, it has been 10 days since we bumped the kernel to 3.16.43, and things appear to be running solid at this point, much thanks for all the assistance in getting this major task accomplished. Though I ran across a glitch, with unionfs, basically you no longer can remove a *directory* in the path '/oldroot/mnt/asturw/...' as unionfs with kernel 3.16 has an issue with that. Such a deletion now also effects open files in the same path, in memory. Removing a *file* in the '/oldroot/mnt/asturw/...' path appears to be OK, which is important, since that is the only way to "undo" an edit of a file on '/oldroot/mnt/asturo/...' I sent an email to Erez Zadok at Stony Brook University as well as the unionfs mailing list, where I go into more detail. [Unionfs] unionfs with Linux 3.16 http://www.fsl.cs.sunysb.edu/pipermail/unionfs/2017-May/006196.html I looked over our scripts and we only needed a few changes to implement the new rule: -- Rule: Never remove a directory in the path '/oldroot/mnt/asturw/...' -- (Revision: 8361) The 'show-union' command now only shows files, so as not to encourage directory removal, except 'show-union all' shows directories as well. Any stale directories on ASTURW should not happen for normal users in production, but during development it can be handy to edit ASTURO files, so if you wanted to remove these stale directories (leaving them be is fine) you need to reboot to RUNNIX and mount /dev/sda2 as -t ext2. Lonnie |
|
From: Lonnie A. <li...@lo...> - 2017-05-26 21:35:13
|
Hi Devs, We have made good progress on getting a major kernel upgrade (3.16.x) for the future AstLinux 1.3.x series. Special thanks to Michael Keuter for testing and research. Particularly for those of you who build your own images, here are a few tips: 1) The native build system now requires "bc" to build the kernel, this has been added to the Prerequisites - Package lists. 2) If you have any custom .config's they need to be updated, in particular the following entries: For i586: -- BR2_TOOLCHAIN_EXTERNAL_PATH="$(HOME)/astlinux/x-tools-1.20.0-3.16/i586-unknown-linux-gnu" BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.16.43.tar.gz" -- For x86_64: -- BR2_TOOLCHAIN_EXTERNAL_PATH="$(HOME)/astlinux/x-tools-1.20.0-3.16/x86_64-unknown-linux-gnu" BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.16.43.tar.gz" -- I would suggest removing (requires sudo) or renaming the previous "$(HOME)/astlinux/x-tools-1.20.0-3.2p1" directory to make sure the old toolchain does not get accidentally used. 3) The i586 and x86_64 toolchains need to be rebuilt with the new kernel header files, you will be automatically prompted with the new "crosstool-ng-src/README". No need to re-install "crosstool-ng-1.20.0", simply create new toolchains. The beginning of the new ChangeLog is here: http://svn.code.sf.net/p/astlinux/code/branches/1.0/docs/ChangeLog.txt Lonnie |
|
From: Lonnie A. <li...@lo...> - 2017-05-25 12:11:00
|
Announcing AstLinux Release: 1.2.10 More Info: AstLinux Project http://www.astlinux-project.org/ AstLinux 1.2.10 Highlights: • New package "sngrep" tool for displaying SIP call message flows from a terminal • New package "netcalc" IPv4 and IPv6 network calculator, also used for dnsmasq configuration • New package "gntp-send" CLI tool for sending Growl (GNTP) notifications • Added 'rbash' a restricted login shell /bin/rbash for non-root users • Added ddclient-curl support allowing mixed IPv4/IPv6 DNS updates and other dynamic DNS features • Added USB TTY feature to automatically spawn getty for selected usb tty serial devices • Added support for Hyper-V VM's with hv_netvsc and hv_utils kernel drivers (genx86_64-vm) • Web Interface enhancements and package upgrades providing important security and bug fixes Full ChangeLog: http://svn.code.sf.net/p/astlinux/code/tags/1.2.10/docs/ChangeLog.txt All users are encouraged to upgrade. AstLinux Team |
|
From: Lonnie A. <li...@lo...> - 2017-05-17 22:28:16
|
Announcing Pre-Release Version: astlinux-1.0-8306 Release Candidate for AstLinux 1.2.10 The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own. -- DHCPv6 Client Action Script http://doc.astlinux-project.org/userdoc:tt-dhcpv6-prefix-delegation#dhcpv6_client_action_script -- USB TTY Serial Login http://doc.astlinux-project.org/userdoc:usbtty_serial_login -- Hyper-V (only genx86_64-vm board type) http://doc.astlinux-project.org/userdoc:guest_vm_hyperv -- Restricted User Login http://doc.astlinux-project.org/userdoc:tt_restricted_user_login -- Asterisk Call Notification http://doc.astlinux-project.org/userdoc:tt_asterisk_call_notify -- Dynamic DNS Client http://doc.astlinux-project.org/userdoc:tt_dynamic_dns_client -- sngrep, version 1.4.3, new package, tool for displaying SIP call message flows from a terminal. These pre-release images are for those who would like to take advantage of the AstLinux development before the next official release, as well as providing testing for the project. The "AstLinux Pre-Release ChangeLog" and "Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ... AstLinux Project -> Development http://www.astlinux-project.org/dev.html If you should come across an issue, please report back here ASAP. AstLinux Team |
|
From: Lonnie A. <li...@lo...> - 2017-05-07 21:28:37
|
Announcing Pre-Release Version: astlinux-1.0-8288 The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own. -- USB TTY Serial Login http://doc.astlinux-project.org/userdoc:usbtty_serial_login -- Hyper-V (only genx86_64-vm board type) http://doc.astlinux-project.org/userdoc:guest_vm_hyperv -- Restricted User Login http://doc.astlinux-project.org/userdoc:tt_restricted_user_login -- Asterisk Call Notification http://doc.astlinux-project.org/userdoc:tt_asterisk_call_notify -- Dynamic DNS Client http://doc.astlinux-project.org/userdoc:tt_dynamic_dns_client -- sngrep, version 1.4.2, new package, tool for displaying SIP call message flows from a terminal. These pre-release images are for those who would like to take advantage of the AstLinux development before the next official release, as well as providing testing for the project. The "AstLinux Pre-Release ChangeLog" and "Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ... AstLinux Project -> Development http://www.astlinux-project.org/dev.html While these images are considered 'stable', the lack of testing will not make these images suitable for critical production systems. If you should come across an issue, please report back here. AstLinux Team |
|
From: David K. <da...@ke...> - 2017-05-04 13:05:32
|
I did not know about resize. Thanks. David On Wed, May 3, 2017 at 10:19 PM, Lonnie Abelbeck <li...@lo...> wrote: > As a tip, you can manually type "resize" after you login on a serial > console to do the same. > > Due to the lack of responses we probably should keep "/dev/ttyS*" pure and > no fancy stuff. > > A person can always enable "USB TTY Serial Login" > https://doc.astlinux-project.org/userdoc:usbtty_serial_login even if > there is a serial port. > for those cases when an non-network, out-of-band login is needed. The > "resize" is automatic there. > > Lonnie > > > On May 3, 2017, at 8:55 PM, David Kerr <Da...@Ke...> wrote: > > > So I rarely have to resort to serial terminal use... usually only when I > screw up. However on those rare occasions that I do have to go serial it > would be very very nice to be able to increase the screen size. In > particular 24x80 does restrict how many e.g. syslog messages are visible at > once. As I recall whatever terminal s/w I use doesn't have a scroll buffer > I can use to go back to see messages that already scrolled off. > > > > David > > > > On Mon, May 1, 2017 at 8:12 PM, Lonnie Abelbeck < > li...@lo...> wrote: > > Hi Devs, > > > > When adding the new "USB TTY Serial Login" feature, one thing we did in > the /etc/profile is to call the "resize" command to query the terminal to > automatically determine the LINES and COLUMNS and update "stty -a". > > -- > > # Set LINES and COLUMNS for USB TTY serial devices > > if [ -x /usr/bin/resize ]; then > > case $(tty) in > > /dev/ttyUSB*) resize >/dev/null ;; > > esac > > fi > > -- > > This works very nicely, and makes ncurses apps work as expected for an > arbitrary terminal window size, rather than assuming the default 24x80. > > > > Simple question, should we do the same for "/dev/ttyS*" for standard > serial consoles ? > > > > You may wonder how "resize" works, a vt100 terminal allows an escape > sequence to "Query Cursor Position" after moving to ROW;COLUMN position > 999;999 pinned at lower-right, lastly restore cursor back to where it > started. "resize" reads the data sent back indicating the size of the > terminal window. > > > > So clearly this will only work if you are emulating a vt100 or some > later ANSI flavor, but chances are you do. But what if you don't, then you > might see a few goofy escape sequences shown and the "resize" command waits > for up to 3 seconds to get a reply before giving-up and continuing as > normal. > > > > I'll gladly add "/dev/ttyS*" if people like the idea, but will leave it > as is until there is demand for the change. > > > > Lonnie > > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > |
|
From: Lonnie A. <li...@lo...> - 2017-05-04 02:19:22
|
As a tip, you can manually type "resize" after you login on a serial console to do the same. Due to the lack of responses we probably should keep "/dev/ttyS*" pure and no fancy stuff. A person can always enable "USB TTY Serial Login" https://doc.astlinux-project.org/userdoc:usbtty_serial_login even if there is a serial port. for those cases when an non-network, out-of-band login is needed. The "resize" is automatic there. Lonnie On May 3, 2017, at 8:55 PM, David Kerr <Da...@Ke...> wrote: > So I rarely have to resort to serial terminal use... usually only when I screw up. However on those rare occasions that I do have to go serial it would be very very nice to be able to increase the screen size. In particular 24x80 does restrict how many e.g. syslog messages are visible at once. As I recall whatever terminal s/w I use doesn't have a scroll buffer I can use to go back to see messages that already scrolled off. > > David > > On Mon, May 1, 2017 at 8:12 PM, Lonnie Abelbeck <li...@lo...> wrote: > Hi Devs, > > When adding the new "USB TTY Serial Login" feature, one thing we did in the /etc/profile is to call the "resize" command to query the terminal to automatically determine the LINES and COLUMNS and update "stty -a". > -- > # Set LINES and COLUMNS for USB TTY serial devices > if [ -x /usr/bin/resize ]; then > case $(tty) in > /dev/ttyUSB*) resize >/dev/null ;; > esac > fi > -- > This works very nicely, and makes ncurses apps work as expected for an arbitrary terminal window size, rather than assuming the default 24x80. > > Simple question, should we do the same for "/dev/ttyS*" for standard serial consoles ? > > You may wonder how "resize" works, a vt100 terminal allows an escape sequence to "Query Cursor Position" after moving to ROW;COLUMN position 999;999 pinned at lower-right, lastly restore cursor back to where it started. "resize" reads the data sent back indicating the size of the terminal window. > > So clearly this will only work if you are emulating a vt100 or some later ANSI flavor, but chances are you do. But what if you don't, then you might see a few goofy escape sequences shown and the "resize" command waits for up to 3 seconds to get a reply before giving-up and continuing as normal. > > I'll gladly add "/dev/ttyS*" if people like the idea, but will leave it as is until there is demand for the change. > > Lonnie |
|
From: David K. <da...@ke...> - 2017-05-04 01:56:40
|
No opinion on this one. I always change to 115200 as one of the first things I do anyway. David On Wed, May 3, 2017 at 8:15 PM, Darrick Hartman <dha...@dj...> wrote: > My vote would be to change it at a later date as part of a bigger change > set ( say like a kernel bump ). > > -----Original Message----- > From: Michael Knill [mailto:mic...@ip...] > Sent: Wednesday, May 3, 2017 4:52 PM > To: AstLinux Developers Mailing List <ast...@li... > > > Subject: Re: [Astlinux-devel] (geni586|genx86_64)-serial 115200 baud > default? > > I vote for 1. Do nothing. > It's a one liner as part of my standard build process. > > Regards > Michael Knill > > -----Original Message----- > From: Lonnie Abelbeck <li...@lo...> > Reply-To: AstLinux Developers Mailing List <astlinux-devel@lists. > sourceforge.net> > Date: Thursday, 4 May 2017 at 4:06 am > To: AstLinux Developers Mailing List <ast...@li... > > > Subject: [Astlinux-devel] (geni586|genx86_64)-serial 115200 baud default? > > Hi Devs, > > Question: Is it time to change our RUNNIX and geni586-serial and > genx86_64-serial board types to default to 115200 baud consoles ? > > The good news, for new installs this is only a documentation change. > > The bad news, for existing installs, a new (115200) run image would be a > mismatch between RUNNIX and possibly the BIOS if serial console redirection > was enabled. Messy. > > Recall we have a command 'setconsole-speed-tty" that edits the > /etc/inittab on unionfs and /oldroot/cdrom/syslinux.cfg on the FAT16 > (RUNNIX) partition to override any default settings. > > Therefore for an existing install, a user would either have to: > > 1) After upgrade: "setconsole-speed-tty 19200" to return back to using > 19200 baud. > > 2) Update to a RUNNIX with a 115200 default then upgrade to the new 115200 > AstLinux image .. then change any serial BIOS console redirection if needed. > > So, the options as I see them ... > > 1) Keep 19200 as the console default, do nothing. > > 2) Change the console default to 115200 and document how users need to > adapt to using 115200 baud. > > 3) Change the console default to 115200, but using the FIRSTRUN init.d > script automatically call "setconsole-speed-tty 19200" if syslinux.cfg > (RUNNIX) was configured for 19200 to keep things at 19200 for the future. > 3a) Note: still not perfect as a baud mis-match would occur one time > before "setconsole-speed-tty 19200" could be called. > > Of course a baud rate mismatch between the BIOS, RUNNIX or AstLInux will > not effect booting properly, just serial console access. > > Unless we have a consensus for a change, we will leave it as is. > > Lonnie > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most engaging > tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most engaging > tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > |
|
From: David K. <da...@ke...> - 2017-05-04 01:55:38
|
So I rarely have to resort to serial terminal use... usually only when I screw up. However on those rare occasions that I do have to go serial it would be very very nice to be able to increase the screen size. In particular 24x80 does restrict how many e.g. syslog messages are visible at once. As I recall whatever terminal s/w I use doesn't have a scroll buffer I can use to go back to see messages that already scrolled off. David On Mon, May 1, 2017 at 8:12 PM, Lonnie Abelbeck <li...@lo...> wrote: > Hi Devs, > > When adding the new "USB TTY Serial Login" feature, one thing we did in > the /etc/profile is to call the "resize" command to query the terminal to > automatically determine the LINES and COLUMNS and update "stty -a". > -- > # Set LINES and COLUMNS for USB TTY serial devices > if [ -x /usr/bin/resize ]; then > case $(tty) in > /dev/ttyUSB*) resize >/dev/null ;; > esac > fi > -- > This works very nicely, and makes ncurses apps work as expected for an > arbitrary terminal window size, rather than assuming the default 24x80. > > Simple question, should we do the same for "/dev/ttyS*" for standard > serial consoles ? > > You may wonder how "resize" works, a vt100 terminal allows an escape > sequence to "Query Cursor Position" after moving to ROW;COLUMN position > 999;999 pinned at lower-right, lastly restore cursor back to where it > started. "resize" reads the data sent back indicating the size of the > terminal window. > > So clearly this will only work if you are emulating a vt100 or some later > ANSI flavor, but chances are you do. But what if you don't, then you might > see a few goofy escape sequences shown and the "resize" command waits for > up to 3 seconds to get a reply before giving-up and continuing as normal. > > I'll gladly add "/dev/ttyS*" if people like the idea, but will leave it as > is until there is demand for the change. > > Lonnie > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > |
|
From: Darrick H. <dha...@dj...> - 2017-05-04 00:15:23
|
My vote would be to change it at a later date as part of a bigger change set ( say like a kernel bump ). -----Original Message----- From: Michael Knill [mailto:mic...@ip...] Sent: Wednesday, May 3, 2017 4:52 PM To: AstLinux Developers Mailing List <ast...@li...> Subject: Re: [Astlinux-devel] (geni586|genx86_64)-serial 115200 baud default? I vote for 1. Do nothing. It's a one liner as part of my standard build process. Regards Michael Knill -----Original Message----- From: Lonnie Abelbeck <li...@lo...> Reply-To: AstLinux Developers Mailing List <ast...@li...> Date: Thursday, 4 May 2017 at 4:06 am To: AstLinux Developers Mailing List <ast...@li...> Subject: [Astlinux-devel] (geni586|genx86_64)-serial 115200 baud default? Hi Devs, Question: Is it time to change our RUNNIX and geni586-serial and genx86_64-serial board types to default to 115200 baud consoles ? The good news, for new installs this is only a documentation change. The bad news, for existing installs, a new (115200) run image would be a mismatch between RUNNIX and possibly the BIOS if serial console redirection was enabled. Messy. Recall we have a command 'setconsole-speed-tty" that edits the /etc/inittab on unionfs and /oldroot/cdrom/syslinux.cfg on the FAT16 (RUNNIX) partition to override any default settings. Therefore for an existing install, a user would either have to: 1) After upgrade: "setconsole-speed-tty 19200" to return back to using 19200 baud. 2) Update to a RUNNIX with a 115200 default then upgrade to the new 115200 AstLinux image .. then change any serial BIOS console redirection if needed. So, the options as I see them ... 1) Keep 19200 as the console default, do nothing. 2) Change the console default to 115200 and document how users need to adapt to using 115200 baud. 3) Change the console default to 115200, but using the FIRSTRUN init.d script automatically call "setconsole-speed-tty 19200" if syslinux.cfg (RUNNIX) was configured for 19200 to keep things at 19200 for the future. 3a) Note: still not perfect as a baud mis-match would occur one time before "setconsole-speed-tty 19200" could be called. Of course a baud rate mismatch between the BIOS, RUNNIX or AstLInux will not effect booting properly, just serial console access. Unless we have a consensus for a change, we will leave it as is. Lonnie ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <mic...@ip...> - 2017-05-03 21:52:22
|
I vote for 1. Do nothing. It's a one liner as part of my standard build process. Regards Michael Knill -----Original Message----- From: Lonnie Abelbeck <li...@lo...> Reply-To: AstLinux Developers Mailing List <ast...@li...> Date: Thursday, 4 May 2017 at 4:06 am To: AstLinux Developers Mailing List <ast...@li...> Subject: [Astlinux-devel] (geni586|genx86_64)-serial 115200 baud default? Hi Devs, Question: Is it time to change our RUNNIX and geni586-serial and genx86_64-serial board types to default to 115200 baud consoles ? The good news, for new installs this is only a documentation change. The bad news, for existing installs, a new (115200) run image would be a mismatch between RUNNIX and possibly the BIOS if serial console redirection was enabled. Messy. Recall we have a command 'setconsole-speed-tty" that edits the /etc/inittab on unionfs and /oldroot/cdrom/syslinux.cfg on the FAT16 (RUNNIX) partition to override any default settings. Therefore for an existing install, a user would either have to: 1) After upgrade: "setconsole-speed-tty 19200" to return back to using 19200 baud. 2) Update to a RUNNIX with a 115200 default then upgrade to the new 115200 AstLinux image .. then change any serial BIOS console redirection if needed. So, the options as I see them ... 1) Keep 19200 as the console default, do nothing. 2) Change the console default to 115200 and document how users need to adapt to using 115200 baud. 3) Change the console default to 115200, but using the FIRSTRUN init.d script automatically call "setconsole-speed-tty 19200" if syslinux.cfg (RUNNIX) was configured for 19200 to keep things at 19200 for the future. 3a) Note: still not perfect as a baud mis-match would occur one time before "setconsole-speed-tty 19200" could be called. Of course a baud rate mismatch between the BIOS, RUNNIX or AstLInux will not effect booting properly, just serial console access. Unless we have a consensus for a change, we will leave it as is. Lonnie ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Lonnie A. <li...@lo...> - 2017-05-03 18:06:58
|
Hi Devs, Question: Is it time to change our RUNNIX and geni586-serial and genx86_64-serial board types to default to 115200 baud consoles ? The good news, for new installs this is only a documentation change. The bad news, for existing installs, a new (115200) run image would be a mismatch between RUNNIX and possibly the BIOS if serial console redirection was enabled. Messy. Recall we have a command 'setconsole-speed-tty" that edits the /etc/inittab on unionfs and /oldroot/cdrom/syslinux.cfg on the FAT16 (RUNNIX) partition to override any default settings. Therefore for an existing install, a user would either have to: 1) After upgrade: "setconsole-speed-tty 19200" to return back to using 19200 baud. 2) Update to a RUNNIX with a 115200 default then upgrade to the new 115200 AstLinux image .. then change any serial BIOS console redirection if needed. So, the options as I see them ... 1) Keep 19200 as the console default, do nothing. 2) Change the console default to 115200 and document how users need to adapt to using 115200 baud. 3) Change the console default to 115200, but using the FIRSTRUN init.d script automatically call "setconsole-speed-tty 19200" if syslinux.cfg (RUNNIX) was configured for 19200 to keep things at 19200 for the future. 3a) Note: still not perfect as a baud mis-match would occur one time before "setconsole-speed-tty 19200" could be called. Of course a baud rate mismatch between the BIOS, RUNNIX or AstLInux will not effect booting properly, just serial console access. Unless we have a consensus for a change, we will leave it as is. Lonnie |
28 messages has been excluded from this view by a project administrator.
