|
Dialectronics - the dialect of electronic communications
|
|
|
About Us Our Mission Minix RISCV PowerPC Lua XCOFF Bootloader Old World Macs Open Firmware Words Journeys Home Repair Top Level |
Minix 3.1.6I spent a couple months investigating molecular mimicry, where pathogens mimic normal human tissue and cause the immune system to mistakenly attack healthy tissue. There is an amazing open database of genome profiles by U.S. National Institute of Health that allows the public to download genome profiles. They even have tools to assist in the analysis (like BLAST but I wanted to understand the process better so I wrote my own tools. BLAST uses a database approach by finding interesting segments within the genome profile and creating records of those segments. To do matching, it's just a matter of finding similar records. For what I was doing, I was interested in "off-axis" matching, where there are interesting matches away from the x == y matching. I wrote a brute force matching algorithm that literally checks each individual nucleotide (ACGT) in a profile against all of the nucleotides in the other profile. This has to be run twice, once in the forward direction for both samples, and then the reverse for one against the forward of the other. This is because there are two strands to DNA, the "sense" and the "antisense." During the assembly process, some of the fragments can be in the opposite direction. In order to identify possible matches, the comparison has to be run in both directions. I treated the smaller profile as the x-axis and the larger one as the y-axis. Once I found a match, I ran along the diagonal to keep matching, until there was a miss. I checked the parameters to see if the sequence passed or not, and I created "exclusion zones" to prevent searching in areas where there was already a significant match. This eliminated duplication and reduced the number of comparisons. For example, if the 20 nucleotide sequence "TGTGACCATTAATGGTCACA" matched starting at position (x, y), the comparison of x+1 would skip y through y+19 and would resume at y+20. This continues until x+20, which resumes comparison at y. For low enough matching requirements, there might be several exclusion zones along the y-axis for each position x. Keeping track of them in the correct order made for some interesting headscratching. I started in Lua and then migrated it to C, built with pcc on Minix 3.1.6 and clang on OS X. I ended up doing most of the comparisons on OS X, but image generation was done solely on Minix 3.1.6 on Udoo Advanced x86. The comparison code created a csv file that gave the starting point (x, y) and the ending point of the matching sequence. I used LibGD for generating GIFs of the resulting sequential matches. I generated dozens of images. Image generation from the file took longer to relay progress reports than to generate the GIF file. I used lighttpd to view the images via a web browser. While I did not find anything particularly interesting, I was also unable to reproduce the findings in some peer-review articles claiming cross-reactivity between assays for pathogens and human proteins. The articles claimed nucleotide sequences I could not find in the genes that generate that protein. After I was done with this exploration, I realized it provided me with a solid performance test to compare Minix 3.1.6 against other OSes, like FreeBSD. I picked one specific comparison that was long enough to differentiate run-times, but short enough I wasn't bored. In this case, it was comparing the profiles of two samples of the virus that causes Covid-19. To be specific, it was OM003364.1 and OM002793.1.
FreeBSD/VB/clang -O3: 14.57 sec FreeBSD/VB/pcc -O3: 21.50 FreeBSD/VB/pcc: 25.22 FreeBSD/VB/clang: 29.85 Minix/VB/clang -O3: 38.45 FreeBSD/Udoo/clang -O3: 48.40 Minix/VB/ACK: 1:09.91 min Minix/VB/ACK -O3: 1:11.48 Minix/VB/pcc -O3: 1:12.13 Minix/VB/pcc: 1:14.60 Minix/VB/clang: 1:19.20 FreeBSD/Udoo/clang: 1:40.25 Minix/Udoo/clang -O3: 1:45.05 Minix/Udoo/pcc -O3: 2:48.20 Minix/Udoo/pcc: 3:12.11The above table are representative times for each combination, give or take a few seconds. As discussed below, I took the Assembly output from clang on FreeBSD 13.1 and modified it to go through the yasm assembler in our custom toolchain, in order to run on Minix 3.1.6. I also modified the source code for pcc 1.2 to run on FreeBSD 13.1. This allows a direct comparison of compilers. pcc's code takes about 50% longer to execute on FreeBSD, which is consistent with our observations that the performance difference between Minix 3.1.6 and FreeBSD 13.1 is half compiler and half operating system. One thing quite notable is how much clang improves with -O3. Without optimization, the code was horrible. In fact, on both FreeBSD and Minix, clang without optimization is slower than pcc without it. However, the code with -O3 handily outperforms pcc with O3. You might notice "ACK" in two entries. After some code tweaking to meet the earlier C standard, I did compile with the native Amsterdam Compiler Kit just to see how it would perform. It actually slowed down with optimization, but was still faster than pcc -O3 (unfortunately). I also spent time running Minix 3.1.6's profiler:
================================================================================
Data file: vb_cmp_pcc_O3.stat
================================================================================
System process ticks: 1037 ( 1%)
User process ticks: 69470 ( 99%) Details of system process
Idle time ticks: 0 ( 0%) samples, aggregated and
---------- ---- per process, are below.
Total ticks: 70507 (100%)
--------------------------------------------------------------------------------
Total system process time 1037 samples
--------------------------------------------------------------------------------
clock _sdesc ******************************************************* 83.6%
e1000 _main **** 5.8%
random _printf *** 4.3%
system _sdesc ** 3.0%
e1000 _panic ** 1.8%
<1% * 1.5%
--------------------------------------------------------------------------------
total 100.0%
This allowed me to verify that the operating system wasn't taking a lot of time from the computation, and that the code itself is a bit of a bottleneck. Above is pcc -O3 on VirtualBox, and below is the clang code:
================================================================================
Data file: vb_cmp_cl_O3.stat
================================================================================
System process ticks: 745 ( 1%)
User process ticks: 41224 ( 83%) Details of system process
Idle time ticks: 7757 ( 16%) samples, aggregated and
---------- ---- per process, are below.
Total ticks: 49726 (100%)
--------------------------------------------------------------------------------
Total system process time 745 samples
--------------------------------------------------------------------------------
clock _sdesc ******************************************************* 71.3%
e1000 _main ******** 10.1%
random _printf ******* 8.1%
system _sdesc **** 3.9%
e1000 _panic *** 2.7%
<1% **** 3.9%
--------------------------------------------------------------------------------
total 100.0%
The code works well enough that there is idle time.
We released a RISC-V32 backend for C in PCC. We expect to improve the performance and fix the outstanding issues as time permits. We had a chance to do some extensive performance testing of Minix 3.1.6 against FreeBSD 13 on identical hardware, in both VirtualBox and on the Udoo x86 Advance SBC. We did two tests: count to 1 billion while printing out increments of 100,000,000, and comparing two 30k nucleotide genetic profiles against each other (approximately 900,000,000 comparisons). We used the mod operation to know when to print out intervals of 100,000,000 when counting to 1 billion. The results were quite interesting. FreeBSD 13 outperforms Minix 3.1.6 significantly. In fact, Minix 3.1.6 can take as much as three times as long for identical tasks. Timing was done through a combination of using "time ./count" as well as the profile code in Minix. About half of the performance difference comes down to the PCC compiler. We determined this by getting the clang Assembly output from compiling on FreeBSD 13 and building it with our toolchain. clang just seems to outperform pcc in keeping registers alive through out-of-order branching and other tricks. Some of the algorithms for doing certain operations are clearly optimized. One example is that clang uses division for mod operations, while pcc uses shifts. When I used clang's algorithm on Minix 3.1.6 to count to 1 billion with printing increments, the performance difference went away for that specific task. Minix 3.1.6 performed identically to FreeBSD 13. Compiling the genetic comparison code with -O3 made a huge difference in clang, on order of 30% or more, but only about a 10% difference with pcc. I was only able to reduce the performance difference by 50% when using clang-generated assembly. As a result, I conclude not all of it can be explained by the compiler, at least, not at the moment. Recall that Minix 3.1.6 is compiled by pcc in our environment. The same inefficiencies in userland code can impede performance in kernel space. While it was possible to assemble specific files compiled with clang through careful matching of ABIs and data structures, it is not feasible to do the entire kernel source code this way. Compiling with -O3 in pcc did result in a noticeable improvement in speed, but also appeared to introduce some instability in the vfs driver. Further examination of the dependency on the compiler will have to wait. We did notice during testing that there is a strange disparity between TLB flushes for identical tasks on VirtualBox vs. Udoo (we hacked in some code to count each time write_cr3() was called, as a proxy for TLB flushes). On the Udoo, there is a clear inverse correlation between the speed in which a task executes and the number of TLB flushes. This is not replicated in VB. There seems to be no correlation between TLB flushes and performance, and if there is, it is highly non-linear. A significant reduction in TLB flushes does not result in a significant improvement in performance. Figure 1: VB: TLB flushes Total time Sys time cmp_pcc_O3 932,411 1:19m 8.6s cmp_cl_O3 925,885 50.7s 9.03s cmp_pcc_O3_nopf 284,451 1:12m 1.0s cmp_cl_O3_nopf 223,567 42.2s 1.1s Udoo: cmp_pcc_O3 492,668 2:53m 1.95s cmp_pcc_O3_nopf 409,610 2:51m 0.2s cmp_cl_O3 352,914 1:49m 2.06s cmp_cl_O3_nopf 260,656 1:46m 0.26sThe nomenclature is cmp is the executable, [pcc | cl] is pcc or clang, O3 is the level of optimization, and [nopf | blank] is no printing of matching sequences or printing matches (181 between these two particular covid genome profiles, the longest being around 4100 nucleotides). Minix 3.1.6 invokes at least twice as many context switches as a monolithic kernel, due to the need to pass messages between userland applications and drivers and/or servers. In some cases, as when individual characters are the message such as ssh, this can create a significant number of context switches. IIRC, the same holds for tty. In Minix 3.1.6, context switches invoke TLB flushes (no PCID support). Eliminating as many context switches as possible by not printing increments or matching sequences resulted in a non-linear reduction in TLB flushes on VB. Whereas on the Udoo reducing context switches reduced TLB flushes by about 30% and performance improved by about 10%, as can be seen in Figure 1 above, reducing context switches on VB reduced TLB flushes by almost 70%, without a proportional gain in performance (it improved by about 10% as well). Odd, and currently unexplained. 10/25/22: We've posted our backport of the ahci driver for Minix 3.1.6 the Udoo Advanced x86 SBC. You will need to add cd ./ahci && $(MAKE) $@to src/drivers/Makefile. Also, to make sure it loads and works, you will need to add
service ahci
{
irq
10 # Controller 0
11 # Controller 1
;
system
UMAP # 14
IRQCTL # 19
DEVIO # 21
SDEVIO # 22
VDEVIO # 23
SETALARM # 24
TIMES # 25
GETINFO # 26
SAFECOPYFROM # 31
SAFECOPYTO # 32
SETGRANT # 34
READBIOS # 35
PROFBUF # 38
SYSCTL # 44
;
pci class
1/6 # Mass storage / SATA
;
};
to /etc/system.conf.
Addahci ---755 0 0 ahcito src/drivers/memory/ramdisk/proto.gen Additionally in src/drivers/memory/ramdisk/Makefile, add:
PROGRAMS=ahci
ahci: ../../ahci/ahci
install -s ../../$@/$@ $@
../../ahci/ahci:
cd ../../ahci && make
and finally,
if [ X`/bin/sysenv ahci` = Xyes ]
then
ahci_disk=`sysenv ahci_disk` || ahci_disk=0
echo "Using ahci d"${ahci_disk}
/bin/service -c up /bin/ahci -dev /dev/c0d${ahci_disk}
elif [ X`/bin/sysenv bios_wini` = Xyes ]
to src/drivers/memory/ramdisk/rc.Compiling was all done with our internal BSD-licensed toolchain (pcc/yasm/shim/led). Warning We have been using it on a dual-SSD (mirrored) drive on Udoo x86 Advanced for some time. However, if vfs fails, ahci will keep writing, regardless of where it is. This has resulted in overwrites of existing files with error messages destined for /usr/log/messages. You have been warned. Oct 22 06:44:51 192 kernel: probe_bus(0) Oct 22 06:44:51 192 kernel: probe_bus(1) Oct 22 06:44:51 192 kernel: probe_bus(2) Oct 22 06:44:51 192 kernel: AHCI0, bar_24: 0x800 bytes at 0x91427000 memory Oct 22 06:44:51 192 kernel: AHCI0: HBA v1.31, 2 ports, 32 commands, supports queuing, IRQ 10 Oct 22 06:44:51 192 kernel: AHCI0: CAP c334ff01, CAP2 0000003c, PI 00000003 Oct 22 06:44:51 192 kernel: AHCI0: libdriver, driver_announce skipped sys_statectl Oct 22 06:44:51 192 kernel: AHCI0-D1: port status changed (00400040, 00400040), ps->state 0x1 Oct 22 06:44:51 192 kernel: AHCI0-D1: device disconnected Oct 22 06:44:51 192 kernel: AHCI0-D1: device connected Oct 22 06:44:51 192 kernel: AHCI0, libdriver: DEV_OPEN Oct 22 06:44:51 192 kernel: AHCI0-D1: port_timeout not seeing an unhandled interrupt, ps->state 0x4 Oct 22 06:44:51 192 kernel: AHCI0-D1: first time STATE_WAIT_ID failed, retrying Oct 22 06:44:51 192 kernel: AHCI0-D1: port_timeout not seeing an unhandled interrupt, ps->state 0x4 Oct 22 06:44:51 192 kernel: AHCI0-D1: first time STATE_WAIT_ID failed, retrying Oct 22 06:44:51 192 kernel: AHCI0-D1: ATA, ASMT109x- Safe, 512 byte sectors, 114464 MB size Oct 22 06:44:51 192 kernel: readclock: CMOS RAM error(s) found... Oct 22 06:44:51 192 kernel: CMOS state = 0x80 Oct 22 06:44:51 192 kernel: RTC lost power. Reset CMOS RAM with SETUP. Oct 22 06:44:51 192 kernel: Sat Oct 22 06:43:51 GMT 2022 Oct 22 06:44:51 192 kernel: AHCI0-D1, libdriver: DEV_OPEN Oct 22 06:44:51 192 kernel: AHCI0-D1, libdriver: DEV_CLOSE7/23/18: We've posted the source code for the Minix 3.1.6 rtl8111 driver for the RealTek 8111G chip on the Udoo Advanced x86 SBC. You will need rtl8111.c, rtl8111.h, pcireg.h, and the Makefile. The code assumes pcc is present and might not compile with ACK. 7/16/18: As mentioned on the home page, the cure for the bad e1000 ethernet driver in Minix 3.1.6 is to make sure the pci bus mastering bit is set. This code works:
e1000.c, line 396
/* enable bus mastering for dbdma (1 << 4) */
/* enable memory write and invalidate (1 << 2) */
if (did == E1000_DEV_ID_82540EM) {
u16_t cr = pci_attr_r16(devind, PCI_CR);
pci_attr_w16(devind, PCI_CR, cr | ((1 << 2) | ( 1<< 4)));
}
We're not quite ready to release the source code for running Minix 3.1.6 on Udoo Advanced x86, but we can share
some details. The system has been built with a combination of the native ACK compiler and a custom toolchain
based on pcc, yasm, Minix's led/cv, and some custom shim code to convert from yasm's XDF object format ACK's
object file format. Linking is done by led/cv. This is a 100% BSD-licensed toolchain (which builds itself).
Why Minix 3.1.6? We have been big fans of Minix for a long time, but we strongly disagreed with the decision to merge with NetBSD. Instead of griping and complaining, we decided to do our own thing. We started with the most recent version that didn't go down the road of excessively using BSD-style .mk files, which ultimately led to the merger with NetBSD. We didn't want to unfairly take from the volunter work that had been done afterwards, and by starting at this point, we feel that we've stuck with the work of the original (funded) Minix development team. We needed native FPU execution instead of software emulation via gcc (and we wanted to exterminate any GPL'd code as quick as possible), so we ported pcc to the platform. Then we ported yasm for the assembler, since pcc and ACK's assembler were not compatible. We had to do some serious low-level stuff to get pcc and Minix to agree on how to use the registers (they disagreed over using one of the registers as scratch or preserved, that's a headache to debug), and some more to make the XDF relocations work with what led was expecting (ACK embeds the relocation address, XDF has a separate field). All of the C code in the microkernel compiles with pcc/yasm/led/cv, and most of the drivers do, too. There's no USB, and disk I/O has to go through BIOS interrupts, so that's slow, but the system will boot off a USB stick, and it has run the disease modeling code we've written for our PhD research on mathematical models of vector-borne diseases. It only runs on one of the four cores (for now). We've got an ethernet driver (rtl8111) to manage the RealTek 8111G chip on the Udoo, which we'll release soon (BSD-licensed, of course), and that has allowed us to grab the logs and produce proof of what we say. Enjoy!
Jun 21 05:23:09 10 syslogd: restart
Jun 21 05:23:09 10 kernel: bios_colums = 80, bios_rows = 24
Jun 21 05:23:09 10 kernel: scr_size = 2000, scr_lines = 25, scr_width = 80, nr_cons = 4
Jun 21 05:23:09 10 kernel: vid_base = 0xb8000, vid_size = 0x20000
Jun 21 05:23:09 10 kernel: scheduling idle clock system kernel pm vfs rs memory log tty ds mfs vm pfs init
Jun 21 05:23:09 10 kernel: pre arch init
Jun 21 05:23:09 10 kernel: fpu detected; cr0: 33, emulation mode: off
Jun 21 05:23:09 10 kernel: APIC disabled, using legacy PIC
Jun 21 05:23:09 10 kernel: post arch init
Jun 21 05:23:09 10 kernel:
Jun 21 05:23:09 10 kernel: MINIX 3.1.6. (branch-R3.1.6-r6084)
Jun 21 05:23:09 10 kernel: Copyright 2010, Vrije Universiteit, Amsterdam, The Netherlands
Jun 21 05:23:09 10 kernel: MINIX is open source software, see http://www.minix3.org
Jun 21 05:23:09 10 kernel: Initiating legacy i8253 timer
Jun 21 05:23:09 10 kernel: RS: do_up: using proc_name (from binary /bin/pci) 'pci'
Jun 21 05:23:09 10 kernel: RS: do_up: using label (custom) 'pci'
Jun 21 05:23:09 10 kernel: RS: do_up: I/O [cf8..cff]
Jun 21 05:23:09 10 kernel: RS: do_up: I/O [4d0..4d1]
Jun 21 05:23:09 10 kernel: RS: fork regular..
Jun 21 05:23:09 10 kernel: RS: publish_service: DS label registration done: pci -> 36571
Jun 21 05:23:09 10 kernel: RS: started '/bin/pci', major 0, pid 15, endpoint 36571, proc 13
Jun 21 05:23:09 10 kernel: pci_intel_init: Intel Braswell SoC Transaction Register (8086/2280)
Jun 21 05:23:09 10 kernel: probe_bus(0)
Jun 21 05:23:09 10 kernel: 0.0.0: Intel Braswell SoC Transaction Register (8086/2280)
Jun 21 05:23:09 10 kernel: Device index: 0
Jun 21 05:23:09 10 kernel: Subsystem: Vid 0x8086, did 0x7270
Jun 21 05:23:09 10 kernel: class Host bridge (6/0/0)
Jun 21 05:23:09 10 kernel: 0.2.0: Intel Braswell SoC Integrated Graphics Controller (8086/22B1)
Jun 21 05:23:09 10 kernel: Device index: 1
Jun 21 05:23:09 10 kernel: Subsystem: Vid 0x8086, did 0x7270
Jun 21 05:23:09 10 kernel: class VGA-compatible controller (3/0/0)
Jun 21 05:23:09 10 kernel: IRQ 7 for INTA
Jun 21 05:23:09 10 kernel: bar_0: 0x1000000 bytes at 0x90000000 memory, 64-bit
Jun 21 05:23:09 10 kernel: bar_2: 0x10000000 bytes at 0x80000000 prefetchable memory, 64-bit
Jun 21 05:23:09 10 kernel: bar_4: 64 bytes at 0x2000 I/O
Jun 21 05:23:09 10 kernel: @0xd0 (0x00229001): capability type 0x1: PCI Power Management
Jun 21 05:23:09 10 kernel: @0x90 (0x0000b005): capability type 0x5: Message Signaled Interrupts
Jun 21 05:23:09 10 kernel: @0xb0 (0x01070009): capability type 0x9: (unknown type)
Jun 21 05:23:09 10 kernel: 0.19.0: Intel Braswell SoC SATA Controller (8086/22A3)
Jun 21 05:23:09 10 kernel: Device index: 2
Jun 21 05:23:09 10 kernel: Subsystem: Vid 0x8086, did 0x7270
Jun 21 05:23:09 10 kernel: class Mass storage controller (1/6/1)
Jun 21 05:23:09 10 kernel: IRQ 10 for INTA
Jun 21 05:23:09 10 kernel: bar_4: 32 bytes at 0x2060 I/O
Jun 21 05:23:09 10 kernel: bar_5: 0x800 bytes at 0x91427000 memory
Jun 21 05:23:09 10 kernel: @0x80 (0x00007005): capability type 0x5: Message Signaled Interrupts
Jun 21 05:23:09 10 kernel: @0x70 (0x4003a801): capability type 0x1: PCI Power Management
Jun 21 05:23:09 10 kernel: @0xa8 (0x00100012): capability type 0x12: (unknown type)
Jun 21 05:23:09 10 kernel: 0.20.0: Intel Braswell SoC USB xHCI Controller (8086/22B5)
Jun 21 05:23:09 10 kernel: Device index: 3
Jun 21 05:23:09 10 kernel: Subsystem: Vid 0x8086, did 0x7270
Jun 21 05:23:09 10 kernel: class Serial bus controller (C/3/30)
Jun 21 05:23:09 10 kernel: IRQ 11 for INTA
Jun 21 05:23:09 10 kernel: bar_0: 0x10000 bytes at 0x91400000 memory, 64-bit
Jun 21 05:23:09 10 kernel: @0x70 (0xc1c28001): capability type 0x1: PCI Power Management
Jun 21 05:23:09 10 kernel: @0x80 (0x00860005): capability type 0x5: Message Signaled Interrupts
Jun 21 05:23:09 10 kernel: 0.26.0: Intel Braswell SoC Trusted Execution Engine (8086/2298)
Jun 21 05:23:09 10 kernel: Device index: 4
Jun 21 05:23:09 10 kernel: Subsystem: Vid 0x8086, did 0x7270
Jun 21 05:23:09 10 kernel: class Encryption/decryption controller (10/80/0)
Jun 21 05:23:09 10 kernel: IRQ 7 for INTA
Jun 21 05:23:09 10 kernel: bar_0: 0x100000 bytes at 0x91300000 memory
Jun 21 05:23:09 10 kernel: bar_1: 0x100000 bytes at 0x91200000 memory
Jun 21 05:23:09 10 kernel: @0x80 (0x4803a001): capability type 0x1: PCI Power Management
Jun 21 05:23:09 10 kernel: @0xa0 (0x00000005): capability type 0x5: Message Signaled Interrupts
Jun 21 05:23:09 10 kernel: 0.27.0: Intel Braswell SoC High Definition Audio Controller (8086/2284)
Jun 21 05:23:09 10 kernel: Device index: 5
Jun 21 05:23:09 10 kernel: Subsystem: Vid 0x8086, did 0x7270
Jun 21 05:23:09 10 kernel: class Multimedia device (4/3/0)
Jun 21 05:23:09 10 kernel: IRQ 10 for INTA
Jun 21 05:23:09 10 kernel: bar_0: 0x4000 bytes at 0x91410000 memory, 64-bit
Jun 21 05:23:09 10 kernel: @0x50 (0xc8426001): capability type 0x1: PCI Power Management
Jun 21 05:23:09 10 kernel: @0x60 (0x00800005): capability type 0x5: Message Signaled Interrupts
Jun 21 05:23:09 10 kernel: 0.28.0: Intel Braswell SoC PCI Express Port #1 (8086/22C8)
Jun 21 05:23:09 10 kernel: Device index: 6
Jun 21 05:23:09 10 kernel: Subsystem: Vid 0x0, did 0x0
Jun 21 05:23:09 10 kernel: class PCI-to-PCI bridge (6/4/0)
Jun 21 05:23:09 10 kernel: I/O window: base 0xf000, limit 0xfff, size -57344
Jun 21 05:23:09 10 kernel: Memory window: base 0xfff00000, limit 0xfffff, size 0x200000
Jun 21 05:23:09 10 kernel: Prefetchable memory window: base 0xfff00000, limit 0xfffff, size 0x200000
Jun 21 05:23:09 10 kernel: @0x40 (0x01428010): capability type 0x10: (unknown type)
Jun 21 05:23:09 10 kernel: @0x80 (0x00009005): capability type 0x5: Message Signaled Interrupts
Jun 21 05:23:09 10 kernel: @0x90 (0x0000a00d): capability type 0xd: (unknown type)
Jun 21 05:23:09 10 kernel: @0xa0 (0xc8030001): capability type 0x1: PCI Power Management
Jun 21 05:23:09 10 kernel: 0.28.2: Intel Braswell SoC PCI Express Port #3 (8086/22CC)
Jun 21 05:23:09 10 kernel: Device index: 7
Jun 21 05:23:09 10 kernel: Subsystem: Vid 0x0, did 0x0
Jun 21 05:23:09 10 kernel: class PCI-to-PCI bridge (6/4/0)
Jun 21 05:23:09 10 kernel: IRQ 10 for INTC
Jun 21 05:23:09 10 kernel: I/O window: base 0x1000, limit 0x1fff, size 4096
Jun 21 05:23:09 10 kernel: Memory window: base 0x91100000, limit 0x911fffff, size 0x100000
Jun 21 05:23:09 10 kernel: Prefetchable memory window: base 0x91000000, limit 0x910fffff, size 0x100000
Jun 21 05:23:09 10 kernel: @0x40 (0x01428010): capability type 0x10: (unknown type)
Jun 21 05:23:09 10 kernel: @0x80 (0x00009005): capability type 0x5: Message Signaled Interrupts
Jun 21 05:23:09 10 kernel: @0x90 (0x0000a00d): capability type 0xd: (unknown type)
Jun 21 05:23:09 10 kernel: @0xa0 (0xc8030001): capability type 0x1: PCI Power Management
Jun 21 05:23:09 10 kernel: 0.31.0: Intel Braswell SoC PCU (8086/229C)
Jun 21 05:23:09 10 kernel: Device index: 8
Jun 21 05:23:09 10 kernel: Subsystem: Vid 0x8086, did 0x7270
Jun 21 05:23:09 10 kernel: class ISA bridge (6/1/0)
Jun 21 05:23:09 10 kernel: @0xe0 (0x100c0009): capability type 0x9: (unknown type)
Jun 21 05:23:09 10 kernel: 0.31.3: Intel Braswell SoC SMBus Audio Controller (8086/2292)
Jun 21 05:23:09 10 kernel: Device index: 9
Jun 21 05:23:09 10 kernel: Subsystem: Vid 0x8086, did 0x7270
Jun 21 05:23:09 10 kernel: class SMBus (C/5/0)
Jun 21 05:23:09 10 kernel: IRQ 10 for INTB
Jun 21 05:23:09 10 kernel: bar_0: 0x20 bytes at 0x9141c000 memory
Jun 21 05:23:09 10 kernel: bar_4: 32 bytes at 0x2040 I/O
Jun 21 05:23:09 10 kernel: @0x50 (0x00030001): capability type 0x1: PCI Power Management
Jun 21 05:23:09 10 kernel: (warning) unsupported ISA bridge 8086/229C for bus 0
Jun 21 05:23:09 10 kernel: 0.28.0: PCI-to-PCI bridge: 8086/22C8
Jun 21 05:23:09 10 kernel: bus(table) = 1, bus(sec) = 1, bus(subord) = 1
Jun 21 05:23:09 10 kernel: probe_bus(1)
Jun 21 05:23:09 10 kernel: 0.28.2: PCI-to-PCI bridge: 8086/22CC
Jun 21 05:23:09 10 kernel: bus(table) = 2, bus(sec) = 2, bus(subord) = 2
Jun 21 05:23:09 10 kernel: probe_bus(2)
Jun 21 05:23:09 10 kernel: 2.0.0: Realtek RTL8168/RTL8111 (10EC/8168)
Jun 21 05:23:09 10 kernel: Device index: 10
Jun 21 05:23:09 10 kernel: Subsystem: Vid 0x10ec, did 0x123
Jun 21 05:23:09 10 kernel: class Ethernet controller (2/0/0)
Jun 21 05:23:09 10 kernel: IRQ 10 for INTA
Jun 21 05:23:09 10 kernel: bar_0: 256 bytes at 0x1000 I/O
Jun 21 05:23:09 10 kernel: bar_2: 0x10
Jun 21 05:23:09 10 kernel: 00 bytes at 0x91100000 memory, 64-bit
Jun 21 05:23:09 10 kernel: bar_4: 0x4000 bytes at 0x91000000 prefetchable memory, 64-bit
Jun 21 05:23:09 10 kernel: @0x40 (0xffc35001): capability type 0x1: PCI Power Management
Jun 21 05:23:09 10 kernel: @0x50 (0x00807005): capability type 0x5: Message Signaled Interrupts
Jun 21 05:23:09 10 kernel: @0x70 (0x0202b010): capability type 0x10: (unknown type)
Jun 21 05:23:09 10 kernel: @0xb0 (0x0003d011): capability type 0x11: (unknown type)
Jun 21 05:23:09 10 kernel: @0xd0 (0x00000003): capability type 0x3: Vital Product Data
Jun 21 05:23:09 10 kernel: complete_bars: initial gap: [0x73a40000 .. 0xfe000000>
Jun 21 05:23:09 10 kernel: complete_bars: intermediate gap: [0x91427800 .. 0xfe000000>
Jun 21 05:23:09 10 kernel: I/O range = [0x2080..0x10000>
Jun 21 05:23:09 10 kernel: RS: initialization succeeded for service 36571
Jun 21 05:23:09 10 kernel: RS: do_up: using proc_name (from binary /bin/floppy) 'floppy'
Jun 21 05:23:09 10 kernel: RS: do_up: using label (custom) 'floppy'
Jun 21 05:23:09 10 kernel: RS: read_exec: copying exec image from: /bin/floppy
Jun 21 05:23:09 10 kernel: RS: do_up: IRQ 6
Jun 21 05:23:09 10 kernel: RS: do_up: I/O [3f0..3f7]
Jun 21 05:23:09 10 kernel: RS: do_up: I/O [0..f]
Jun 21 05:23:09 10 kernel: RS: do_up: I/O [81..81]
Jun 21 05:23:09 10 kernel: RS: fork_nb..
Jun 21 05:23:09 10 kernel: RS: publish_service: DS label registration done: floppy -> 73128
Jun 21 05:23:09 10 kernel: RS: started '/bin/floppy', major 2, pid 17, endpoint 73128, proc 12
Jun 21 05:23:09 10 kernel: RS: initialization succeeded for service 73128
Jun 21 05:23:09 10 kernel: RS: do_up: using proc_name (from binary /bin/bios_wini) 'bios_wini'
Jun 21 05:23:09 10 kernel: RS: do_up: using label (custom) 'bios_wini'
Jun 21 05:23:09 10 kernel: RS: read_exec: copying exec image from: /bin/bios_wini
Jun 21 05:23:09 10 kernel: RS: fork_nb..
Jun 21 05:23:09 10 kernel: RS: publish_service: DS label registration done: bios_wini -> 73130
Jun 21 05:23:09 10 kernel: RS: started '/bin/bios_wini', major 3, pid 20, endpoint 73130, proc 14
Jun 21 05:23:09 10 kernel: RS: initialization succeeded for service 73130
Jun 21 05:23:09 10 kernel: RS: do_up: using proc_name (from binary /sbin/mfs) 'mfs'
Jun 21 05:23:09 10 kernel: RS: do_up: using label (custom) 'fs_c0d0p0s0'
Jun 21 05:23:09 10 kernel: RS: fork regular..
Jun 21 05:23:09 10 kernel: RS: publish_service: DS label registration done: fs_c0d0p0s0 -> 36582
Jun 21 05:23:09 10 kernel: RS: started '/sbin/mfs', major 0, pid 28, endpoint 36582, proc 24
Jun 21 05:23:09 10 kernel: RS: initialization succeeded for service 36582
Jun 21 05:23:09 10 kernel: bios-d0: 3915776 sectors
Jun 21 05:23:09 10 kernel: bios-d1: 0 sectors
...
Jun 21 07:07:55 10 kernel: S: do_up: using proc_name (from binary /usr/sbin/rtl8111) 'rtl8111'
Jun 21 07:07:55 10 kernel: RS: do_up: using label (custom) 'rtl8111'
Jun 21 07:07:55 10 kernel: RS: do_up: PCI 10ec/8111
Jun 21 07:07:55 10 kernel: RS: do_up: PCI 10ec/8168
Jun 21 07:07:55 10 kernel: RS: fork regular..
Jun 21 07:07:55 10 kernel: RS: init_pci: calling pci_set_acl
Jun 21 07:07:55 10 kernel: PCI: got message from 2, type 0x311
Jun 21 07:07:55 10 kernel: PCI: do_acl: setting ACL for 36661 ('rtl8111') at entry 0
Jun 21 07:07:55 10 kernel: RS: init_pci: after pci_set_acl
Jun 21 07:07:55 10 kernel: RS: publish_service: DS label registration done: rtl8111 -> 36661
Jun 21 07:07:55 10 kernel: RS: started '/usr/sbin/rtl8111', major 0, pid 107, endpoint 36661, proc 103
Jun 21 07:07:55 10 kernel: rtl8111 main()
Jun 21 07:07:55 10 kernel: rtl8111 m.m_type = 0x20a
Jun 21 07:07:55 10 kernel: rtl8111 m.m_type = 0x207
Jun 21 07:07:55 10 kernel: RS: initialization succeeded for service 36661
Jun 21 07:07:55 10 kernel: PCI: got message from 36661, type 0x300
Jun 21 07:07:55 10 kernel: PCI: do_init: called by '36661'
Jun 21 07:07:55 10 kernel: PCI: got message from 36661, type 0x301
Jun 21 07:07:55 10 kernel: PCI: got message from 36661, type 0x30f
Jun 21 07:07:55 10 kernel: rtl8111#0: PCI: got message from 36661, type 0x310
Jun 21 07:07:55 10 kernel: Realtek RTL8168/RTL8111 (10ec/8168) at 2.0.0
Jun 21 07:07:55 10 kernel: PCI: got message from 36661, type 0x307
Jun 21 07:07:55 10 kernel: pci_reserve2: for proc 36661, adding I/O range [0x1000..0x10ff]
Jun 21 07:07:55 10 kernel: pci_reserve3: adding IRQ 10
Jun 21 07:07:55 10 kernel: PCI: got message from 36661, type 0x30a
Jun 21 07:07:55 10 kernel: PCI: got message from 36661, type 0x308
Jun 21 07:07:55 10 kernel: rtl8111#0: using I/O address 0x1000, IRQ 10
Jun 21 07:07:55 10 kernel: PCI: got message from 36661, type 0x309
Jun 21 07:07:55 10 kernel: PCI: got message from 36661, type 0x308
Jun 21 07:07:55 10 kernel: pci_find_cap: dev 0xa, header_type 0x0, ptr 0x34
Jun 21 07:07:55 10 kernel: PCI: got message from 36661, type 0x308
Jun 21 07:07:55 10 kernel: PCI: got message from 36661, type 0x308
Jun 21 07:07:55 10 kernel: pci_find_cap: dev 0xa, ptr 0x40, cap 0x1
Jun 21 07:07:55 10 kernel: PCI: got message from 36661, type 0x308
Jun 21 07:07:55 10 kernel: PCI: got message from 36661, type 0x308
Jun 21 07:07:55 10 kernel: pci_find_cap: dev 0xa, ptr 0x50, cap 0x5
Jun 21 07:07:55 10 kernel: PCI: got message from 36661, type 0x308
Jun 21 07:07:55 10 kernel: PCI: got message from 36661, type 0x308
Jun 21 07:07:55 10 kernel: pci_find_cap: dev 0xa, ptr 0x70, cap 0x10
Jun 21 07:07:55 10 kernel: rtl8111#0: PCI-Express found
Jun 21 07:07:55 10 kernel: PCI: got message from 36661, type 0x309
Jun 21 07:07:55 10 kernel: PCI: got message from 36661, type 0x30c
Jun 21 07:07:55 10 kernel: PCI: got message from 36661, type 0x309
Jun 21 07:07:55 10 kernel: rtl8111#0: bus mastering/invalidate set
Jun 21 07:07:55 10 kernel: PCI: got message from 36661, type 0x309
Jun 21 07:07:55 10 kernel: PCI: got message from 36661, type 0x309
Jun 21 07:07:55 10 kernel: PCI: got message from 36661, type 0x30c
Jun 21 07:07:55 10 kernel: rtl8111#0: ASPM disabled
Jun 21 07:07:55 10 kernel: rtl8111#0: PCI device is present, setting rl_*
Jun 21 07:07:55 10 kernel: rtl8111#0: Chip rev. 0x4c000000
Jun 21 07:07:55 10 kernel: rtl8111#0: MAC rev. 0x00000000
Jun 21 07:07:55 10 kernel: rtl8111#0: checking 8168G/8111G...match
Jun 21 07:07:55 10 kernel: this is where the RTL81111G chip would be configured
Jun 21 07:07:55 10 kernel: rl_reset_hw: (before reset) port = 0x1000, RL_CR = 0x0
Jun 21 07:07:55 10 kernel: rl_reset_hw: (after reset) port = 0x1000, RL_CR = 0x0
Jun 21 07:07:55 10 kernel: rtl8111#0: model: RTL8168G/8111G mac: 0x00000000
Jun 21 07:07:55 10 kernel: rtl8111#0: Ethernet address 0:c0:8:93:47:f6
Jun 21 07:07:55 10 kernel: rtl8111 m.m_type = 0x1003
Jun 21 07:07:55 10 kernel: rtl8111 m.m_type = 0x20d
Jun 21 07:07:55 10 kernel: rtl8111 m.m_type = 0x1003
Jun 21 07:07:55 10 kernel: rtl8111#0: rl_flags = 0x200582fa
Jun 21 07:07:55 10 kernel: rtl8111#0: link up at 100 Mbps, full duplex
Jun 21 07:07:55 10 kernel: CONFIG0 : No Boot ROM
Jun 21 07:07:55 10 kernel: CONFIG1 : LED1 LED0 IOMAP MEMMAP VPD PME
Jun 21 07:07:55 10 kernel: CONFIG2 : AUX PCI-64-Bit
Jun 21 07:07:55 10 kernel: MII_CTRL : ANE Full-duplex 1000 Mb/s
Jun 21 07:07:55 10 kernel: MII_STATUS : 100BaseX-FD 100BaseX-HD 10Mbps-FD 10Mbps-HD Ext-stat res-0x80 MFPS ANC
ANA Extended-capability
Jun 21 07:07:55 10 kernel: MII_ANA : 0x0de1
Jun 21 07:07:55 10 kernel: MII_ANLPA : 0x45e1
Jun 21 07:07:55 10 kernel: MII_ANE : res-0x60 Loc-Next-Page-Able Page-Received LP-Auto-Neg-Able
Jun 21 07:07:55 10 kernel: MII_1000_CTRL : 1000BaseT-FD
Jun 21 07:07:55 10 kernel: generic/ipr.c, 1178: ip[0] (ipr_chk_itab): addr 192.168.1.2 mask 255.255.255.0
Jun 21 07:07:55 10 kernel: generic/ipr.c, 464: ip[0] (ipr_chk_otab): addr 192.168.1.2 mask 255.255.255.0
Jun 21 07:07:55 10 kernel: generic/tcp.c, 553: tcp_put_pkt: using address 192.168.1.2, netmask 255.255.255.0,
mtu 1500
Jun 21 07:07:55 10 kernel: generic/udp.c, 938: udp_ip_arrived: using address 192.168.1.2
Jun 21 07:07:55 10 kernel: rtl8111 m.m_type = 0x207
Jun 21 07:07:55 10 kernel: rtl8111 m.m_type = 0x20c
Jun 21 07:07:55 10 kernel: rl_readv_s: skipping to suspend
Jun 21 07:07:55 10 kernel: rl_readv_s: suspending/replying
Jun 21 07:07:55 10 kernel: generic/ipr.c, 1178: ip[0] (ipr_chk_itab): addr 192.168.1.2 mask 255.255.255.0
Jun 21 07:07:55 10 kernel: generic/ipr.c, 464: ip[0] (ipr_chk_otab): addr 192.168.1.2 mask 255.255.255.0
Jun 21 07:07:55 10 kernel: generic/tcp.c, 553: tcp_put_pkt: using address 192.168.1.2, netmask 255.255.255.0,
mtu 1500
Jun 21 07:07:55 10 kernel: generic/udp.c, 938: udp_ip_arrived: using address 192.168.1.2
...
Jul 3 10:59:42 192 sshd[128]: Accepted password for root from 192.168.10.248 port 61957 ssh2
Jul 3 11:01:13 192 sshd[204]: Accepted password for root from 192.168.10.248 port 61958 ssh2
Some feedback from the toolchain:
# pcc --version
Portable C Compiler 1.2.0.DEVEL 20171212 for i686-pc-minix3
# which pcc
/usr/local/bin/pcc
# file /usr/local/bin/pcc
/usr/local/bin/pcc: MINIX-PC 32-bit executable, sep I&D not stripped
# yasm --version
yasm 1.3.0
Compiled on Mar 9 2018.
Copyright (c) 2001-2014 Peter Johnson and other Yasm developers.
Run yasm --license for licensing overview and summary.
# cat /etc/hostname.file
192.168.10.86
# cat /etc/inet.conf
eth0 rtl8111 0 { default; };
# ifconfig -a
/dev/ip0: address 192.168.10.86 netmask 255.255.255.0 mtu 1500
# ls /usr/sbin/rtl*
/usr/sbin/rtl8111 /usr/sbin/rtl8139 /usr/sbin/rtl8169
Hopefully that satisfies everyone's doubt.(If you want to contact tim, you know the routine - gtkelly at this domain.) |
