Re: First package build on aranym+distcc+NFS
> > I managed to build ghc6_6.4.2-2, but it really took ages, it uses the -x
> > option a lot, so the compiling happens on the local machine and to make it
> > worse, it manages to trigger the 2.6 VM problems, so I had to compile it
> > under 2.4. Using a lot of memory should also help (> 256MB) otherwise it
> > spends a lot of time swapping.
> >
> > bye, Roman
>
> Ethernec driver for my falcon would really help right about now. I
I know. I've already modified ne.c to set the card for 8 bit access, and
ignore the interrupt probe failure. Next thing I need to do is write a
macro to be used in place of inb/outb which implements the funky
read/write access on the ROM port. I will assume reads from the
0xFA0000 space just select /ROM4, reads from 0xFB0000 select /ROM3 as the
ethernec driver 'docs' suggest. I just need to find some time to sit down
with the kernel source and hack some assembly ...
The card I have does not respond favorably to the hardware test routines
provided with the driver kit (test 3 even hangs the machine), I'll assume
the card has been configured to use another I/O port than 0x300 for the
time being.
> don't know if I posted this yet, but my attempts to port the EtherNAT
> drivers were met with confusion. I'm just not good enough yet to get a
> job like this done. I can provide root access to the machine through
I can offer to look over the code you produced, but I'll need a few infos
to go along with that (what's the base address of the EtherNAT, for
instance).
> serial console if someone else wants to try it. With access they can
> make builds or whatever. If it'd be easier, I can also do a 115200
> serial ppp connection so you can use ssh, etc.
Serial PPP or SLIP would be a lot easier to handle than serial console.
Assuming the driver module being loaded does not hang the kernel, of
course.
Builds of the kernel and modules would preferably be done by cross
compiling.
> FWIW, linux is a heck of a lot faster at certain things than mint, no
> doubt due partially to the proper fork/threads implementation and proper
> MMU/virtual memory.
No doubt about that :-)
Michael
Reply to: