The ultimate HOW-TO
adam at os.inf.tu-dresden.de
Tue Sep 18 00:16:37 CEST 2007
On Sat Sep 15, 2007 at 03:00:43 -0700, ComputerScienceStudent wrote:
> 02. ..I've tried with adding the module ore:
> l4lx | l4ore_open() : descriptor 0
> ore | eth=: OEM i82557/i82558 10/100 Ethernet 00:0C:F1:B6:75:AA, IRQ 10.
> ore | Board assembly 000401-003, Physical connectors present: RJ45
> ore | Primary interface chip i82555 PHY #1
> ore | Secondary interface chip i82555.
> ore | General self-test: passed.
> ore | Serial sub-system self-test: passed.
> ore | Internal registers self-test: passed.
> ore | ROM checksum self-test: passed (0xed626fe2).
> ore | main(): initialized DDELinux2.4
> ore | main(): loopback: 0
> ore | device l0 entered promiscuous mode
> ore | device eth0 entered promiscuous mode
> ore | Device = l0, IRQ = 0, MAC = 00:00:00:00:00:00
> ore | Device = eth0, IRQ = 10, MAC = 00:0C:F1:B6:75:AA
> ore | main(): Registering 'ORe' at names...
> ore | main(): Ready for service.
> l4lx | ore_lookup_server(): ORe server ORe = E.02
> l4lx | ore_do_open(): called
> ore | __init_mac(): Allocating physical MAC address to client.
> ore | __init_mac(): MAC = 00:0C:F1:B6:75:AA
> l4lx | ore_do_open(): opened worker = E.06
> l4lx | panic: going to sleep forever, bye
> Why is it so sleepy?? :-D
Doesn't look too bad actually, at least concerning the network side.
> This is just a test, because I'd thought that if it can't find the ORe
> server maybe starting ORe it
> will should be happy, but I was wrong..
When you added earlyprintk=keep, did it say 'keeping early console'
somewhere in the log?
> PS. I'm trying to recompile the source version to disable the Stub drivers,
> as Bjoern Doebel said to me..
> ..but if there's an option to disable this ORe server in the current
> L4Linux it should be better for the
> time spent..
Maybe l4ore.instances= works to disable?
Adam adam at os.inf.tu-dresden.de
More information about the l4-hackers