Hi,
I accepted the advice and recompiled the ore package, then I started it in qemu, this time I got the result:
simplets| Configured for 64 tasks. io | Using platform configuration 'x86' io | PCI: Using configuration type 1 io | PCI: Probing PCI hardware io | PCI: Probing PCI hardware (bus 00) io | PCI: PIIX3: Enabling Passive Release on 00:01.0 io | Limiting direct PCI/PCI transfers. io | Activating ISA DMA hang workarounds. io | 00000000-ffffffff : PCI mem io | e0000000-e1ffffff : Cirrus Logic GD 5446 io | e2000000-e2000fff : Cirrus Logic GD 5446 io | e3000000-e30000ff : Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/
io : 8139C+ io | 0000-ffff : PCI IO io | 0cf8-0cff : PCI conf1 io | 1000-100f : Intel Corporation 82371SB PIIX3 IDE
[Natoma/Triton II]
io | 1400-14ff : Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+
io | b100-b11f : Intel Corporation 82371AB/EB/MB PIIX4 ACPI bmodfs | Passed the following modules: bmodfs | module "/ore" (2322kB) loader | "ore" is a valid binary image loader | ore: Starting sigma0-style application loader | ore: Loading binary loader | ore,#d: Entry at 00009f8c => 01800000 loader | ore,#d: Started io | Available IRQs=[ <!0> 1 <!2> 3 <!4> 5 6 7 8 9 a b c d e f
10 11 ]
ore | Softirq daemon starting ore | Initializing DDE page cache ore | unimplemented: pci_fixup_device ore | unimplemented: pci_fixup_device ore | _add_ddekit_device: Detected device: 8086:7000 ore | unimplemented: pci_fixup_device ore | unimplemented: pci_fixup_device ore | _add_ddekit_device: Detected device: 8086:7010 ore | unimplemented: pci_fixup_device ore | unimplemented: pci_fixup_device ore | _add_ddekit_device: Detected device: 8086:7113 ore | unimplemented: pci_fixup_device ore | unimplemented: pci_fixup_device ore | _add_ddekit_device: Detected device: 1013:b8 ore | unimplemented: pci_fixup_device ore | unimplemented: pci_fixup_device ore | _add_ddekit_device: Detected device: 10ec:8139 ore | <6>e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI ore | <6>e100: Copyright(c) 1999-2006 Intel Corporation ore | <6>8139too Fast Ethernet driver 0.9.28 ore | <6>8139too 0000:00:04.0: This (id 10ec:8139 rev 20) is an
enhanced 81
ore : 39C+ chip ore | <6>8139too 0000:00:04.0: Use the "8139cp" driver for
improved perform
ore : ance and stability. ROOT: Sending ports 1400-14ff to task #07 io | PCI: Setting latency timer of device 00:03.0 to 64 ore | <7>8139too 0000:00:04.0: unknown chip version, assuming
RTL-8139
ore | <7>8139too 0000:00:04.0: TxConfig = 0x74800000 ore | <6>eth0: RealTek RTL8139 at 0x8000, 52:54:00:12:34:56, IRQ
10
ore | <7>eth0: Identified 8139 chip type 'RTL-8139' ore | unimplemented: pci_fixup_device ore | unimplemented: pci_fixup_device ore | unimplemented: pci_fixup_device ore | unimplemented: pci_fixup_device ore | unimplemented: pci_fixup_device ore | l4dde26_register_rx_callback: New rx callback @
0x018012f0.
ore | main(): initialized DDELinux2.6 ore | main(): loopback: 0 ore | <6>device lo entered promiscuous mode ore | <6>device eth0 entered promiscuous mode ore | <6>eth0: link up, 100Mbps, full-duplex, lpa 0x05E1 ore | main(): Initialized 2 network devices. ore | Device = lo, IRQ = 0, MAC = 00:00:00:00:00:00 ore | Device = eth0, IRQ = 10, MAC = 52:54:00:12:34:56 ore | main(): Registering 'ORe' at names..
That looks good.
first is what does "unimplemented: pci_fixup_device" mean, is there any driver I haven't installed or anything else?
No. That's just the DDE being a bit verbose. You can safely ignore this.
The second is "ore | <7>8139too 0000:00:04.0: unknown chip version, assuming RTL-8139", I have choosed the 8139 and 8139c+ options, what does "unknown" mean? Can't recognize?
Yes. Maybe the NIC emulated by Qemu doesn't expose a correct chipset version. You may ignore this, too.
The third is "device eth0 entered promiscuous mode", when we let promiscuous mode enabled, we know maybe it's under monitoring or .., what does this mean?
ORe assigns "virtual" MAC addresses to its clients. Normally, a network interface only accepts packets that are designated for its physical MAC address and drops everything else. This is not intended here, because the physical NIC now also needs to accept packets for the "virtually" assigned NICs. Therefore we put it into promiscuous mode, which just means that the physical device accepts all packets and delivers them to ORe. ORe then checks whether the MAC is one of its virtual MACs and otherwise drops the packet.
Kind regards, Bjoern