On 12/4/17 12:12 PM, Daniel Ouellet wrote: > On 12/4/17 8:49 AM, Ivo Chutkin wrote: >> Hello list, >> >> When I read OpenBSD could run on EdgeRouter Lite, I give it a try (now >> with 6.2 current as of 28.11.2017). >> I expected closer performance to Alix, but ERL even do not respond on >> console in reasonable times, for example, it takes 10-15 sec to log in. >> After reboot, it takes about 5 min on "reordering libraries:" vs 30 sec >> on Alix. >> >> Is it what I should expect from ERL or I am doing something wrong here? >> >> Thanks for your input, >> Ivo > > Get better USB Flash Drive! > > Mine is: > > sd0 at scsibus0 targ 1 lun 0: <SanDisk, Cruzer Fit, 1.27> SCSI4 0/direct > removable serial.07815571360927117103 > > When I simply ping the box to see how long the reboot is and include the > full reorder of library... > > Well here it is: > > 64 bytes from 10.0.0.13: icmp_seq=21 ttl=255 time=0.404 ms > 64 bytes from 10.0.0.13: icmp_seq=72 ttl=255 time=274.757 ms > > See 51 lost ping at 1 per/sec, so 51 sec to be out of service to be back > online ready for processing again. > > $ dmesg > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2017 OpenBSD. All rights reserved. > https://www.OpenBSD.org > > OpenBSD 6.2 (GENERIC) #0: Wed Oct 4 04:56:39 UTC 2017 > visa@octeon:/usr/src/sys/arch/octeon/compile/GENERIC > real mem = 536870912 (512MB) > avail mem = 524009472 (499MB) > mainbus0 at root > cpu0 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation > cpu0: cache L1-I 32KB 4 way D 8KB 64 way, L2 128KB 8 way > clock0 at mainbus0: int 5 > iobus0 at mainbus0 > simplebus0 at iobus0: "soc" > octciu0 at simplebus0 > cn30xxsmi0 at simplebus0 > com0 at simplebus0: ns16550a, 64 byte fifo > com0: console > dwctwo0 at iobus0 base 0x1180068000000 irq 56 > usb0 at dwctwo0: USB revision 2.0 > uhub0 at usb0 configuration 1 interface 0 "Octeon DWC2 root hub" rev > 2.00/1.00 addr 1 > octrng0 at iobus0 base 0x1400000000000 irq 0 > cn30xxgmx0 at iobus0 base 0x1180008000000 > cnmac0 at cn30xxgmx0: RGMII, address 44:d9:e7:40:ac:f8 > atphy0 at cnmac0 phy 7: AR8035 10/100/1000 PHY, rev. 2 > cnmac1 at cn30xxgmx0: RGMII, address 44:d9:e7:40:ac:f9 > atphy1 at cnmac1 phy 6: AR8035 10/100/1000 PHY, rev. 2 > cnmac2 at cn30xxgmx0: RGMII, address 44:d9:e7:40:ac:fa > atphy2 at cnmac2 phy 5: AR8035 10/100/1000 PHY, rev. 2 > /dev/ksyms: Symbol table not valid. > umass0 at uhub0 port 1 configuration 1 interface 0 "SanDisk Cruzer Fit" > rev 2.00/1.27 addr 2 > umass0: using SCSI over Bulk-Only > scsibus0 at umass0: 2 targets, initiator 0 > sd0 at scsibus0 targ 1 lun 0: <SanDisk, Cruzer Fit, 1.27> SCSI4 0/direct > removable serial.07815571360927117103 > sd0: 15267MB, 512 bytes/sector, 31266816 sectors > vscsi0 at root > scsibus1 at vscsi0: 256 targets > softraid0 at root > scsibus2 at softraid0: 256 targets > boot device: sd0 > root on sd0a (55072c2137c3a4e7.a) swap on sd0b dump on sd0b > WARNING: No TOD clock, believing file system. > WARNING: CHECK AND RESET THE DATE! >
I was wrong for one thing. The kernel reordering happened after the reboot, not before like when you install the OS. My bad sorry about miss leading you here! The reordering time is 2 minutes 16 seconds on mine But this below is still true. I should also have added that in this very small box, the re-order of the kernel is pointless I guess as the kernel the box load is the one form the FAT partition. Look it up: mount_msdos /dev/sd0i /mnt and when you reboot and the kernel is reorder, the one that is replace is the one on /, not the one the box boot on the fat partition. SO, in this case, unless you write a script that actually mount the fat partition, copy the new kernel to it for the next reboot, then you still are NOT using a different kernel every time. So, if you don't do that then may as well disable the kernel re-link part... Just a simple thing missing in my previous observation. So, you may not get what you think your getting....
