<lekernel>
larsc: how is your linux port going btw? any progress recently?
<lekernel>
rejon: do you feel like submitting a gsoc application this year?
<lekernel>
(there have been many disappointing things last year and i'd not do it)
<wpwrak>
lekernel: (gsoc) similar experience on my side from some years ago. i think it would be more useful if google just handed out some money to pay people who are already active in the project :)
<larsc>
lekernel: nothing new. it still works more or less. I'm waiting for mwalle uclibc port, so we can overhaul syscalls and signal handling
<rejon>
lekernel yes, lets do it
<rejon>
they have some new people running it
<Fallenou>
rejon: on what are you porting linux ?
<rejon>
huh?
<Fallenou>
oh it's larsc sorry
<kristianpaul>
Fallenou: hi
<Fallenou>
hi kristianpaul  !
<kristianpaul>
Fallenou: Do you have some idea about the Minimac RX FIFO overflow ramdon bug?
<kristianpaul>
As you developed the driver i want to read your comments about it :-)
<Fallenou>
no I really don't
<Fallenou>
but i am looking for a scenario to reproduce the bug
<Fallenou>
Is the bug present using qemu ?
<Fallenou>
because I don't have a board
<lekernel>
no, it probably won't be present with qemu
<Fallenou>
arg
<Fallenou>
how would you process to track the bug ? can kristianpaul send me informations that could help finding out what's going on ?
<kristianpaul>
yday i experienced the bug when doing a _ping_ nothing hangup but every time i pinged the board i got the Minimac RX FIFO overflow
<Fallenou>
wo
<Fallenou>
the driver has serious issue then =(
<kristianpaul>
this was just before configure minimac0 networking using ifconfig ....
<kristianpaul>
I must do more test and send it back to you, yes
<Fallenou>
sure sure send me your test scenario and test results
<Fallenou>
and if you find a way to reproduce the bug at 100% chance, please gimme the exact scenario :)
<Fallenou>
it would really help a lot
<Fallenou>
because searching randomly in the source code (even if the code of the driver is not that big) is not an easy task
<kristianpaul>
100% chance i doubt it... it something happes just after powerup..
<Fallenou>
humm ok :x
<Fallenou>
anyway, send me all the information you have about it please
<Fallenou>
(send it to the ML actually)
<kristianpaul>
yeah sure
<Fallenou>
so that everyone can read it
<kristianpaul>
ah i forgot said, i never got ping reply
<Fallenou>
hummm i think i did, but not sore
<Fallenou>
sure*
<Fallenou>
don't remember
<Fallenou>
i tried ARP, TCP
<Fallenou>
don't remember if i tried icmp
<lekernel>
try with large frames too
<lekernel>
those seem rather prone to triggering bugs in the ethernet drive
<Fallenou>
actually i tried with TFTP
<Fallenou>
and I transfered like 20 MB
<lekernel>
but to be honest, I believe large parts of the ethernet driver needs to be cleaned up and rewritten
<kristianpaul>
Fallenou: tftp is not very smart, i just burst data from thr board to the other end i think
<kristianpaul>
Fallenou: i wonder if you never tried the oposite?
<Fallenou>
do you think we can keep the RTEMS_EVENT principle lekernel ?
<Fallenou>
or rewrite everything using another principle (i don't know what)
<Fallenou>
kristianpaul: actually it was from the host computer to the board
<kristianpaul>
Fallenou: oh
<Fallenou>
and the board was printing the data on serial output
<Fallenou>
you can find the source code i was using and do the test yourself
<kristianpaul>
wait no, i was talking about the 20 MB transfer
<lekernel>
first, for the tenth time or so, use the stock crc32 for fuck's sake
<Fallenou>
and use the tftpclient
<lekernel>
then don't mix softc and global variables, this just doens't make sense (I told you that several times, too)
<Fallenou>
lekernel: yes it would be better, but the last time I tried it didn't work
<lekernel>
once those problems are fixed, to avoid overflows, i'd keep a pool of buffers and refill the ethernet core in the interrupt handler
<Fallenou>
humm ok instead of delaying it
<Fallenou>
doing the change of dma address on the top half
<lekernel>
yes
<Fallenou>
that should improve network performance yes
<lekernel>
the crc32 is an easy problem to track down, you can run both functions (working and supposedly non-working) side by side in a x86 C program on your computer
<lekernel>
i'd be very surprised if there would be no stock crc32 suitable for ethernet in rtems
<Fallenou>
there are two actually, one for big endians and one for little endians
<Fallenou>
maybe I did it wrong while testing
<Fallenou>
but both of them failed :/
<lekernel>
everything is big endian there
<larsc>
Fallenou: for the milkymist
<Fallenou>
oh nice
<Fallenou>
are you using the original port of Lattice ? or the modified one by the japanese guy ?
<larsc>
its based on takeshis tree
<Fallenou>
yes ok
<larsc>
it basically rewrote most of the code from lattice/theobroma because it was either broken or outdated
<larsc>
so now it is quite stable
<Fallenou>
do you plan on making the shared library and relocation stuff working ?
<Fallenou>
oh good :)
<larsc>
mwalle has been working on uclibc and stuff
<lekernel>
just discovered that C support complex numbers
<Fallenou>
hehe
<Fallenou>
I was surprised too when I discovered that
<wpwrak>
(weird C features) one of the more galling features of C is that math.h provides y0, y1, and yn ...
<kristianpaul>
ok tftpclient worked well it seems..
<kristianpaul>
lets see tftpd :-)
<Fallenou>
tftpd ?
<Fallenou>
on milkymist ?
<kristianpaul>
yes
<Fallenou>
it's not in netwok-demos is it ?
<kristianpaul>
tftpTest
<kristianpaul>
it is
<Fallenou>
oh ok
<Fallenou>
tftpclient is something i wrote because i never got tftpTest to work :)
<kristianpaul>
But i guess i requires a working fs
<Fallenou>
so if you do, tell me :p
<Fallenou>
yes
<Fallenou>
it is using a tftp file system
<kristianpaul>
s/i/it
<Fallenou>
i never managed to get it working
<Fallenou>
it mounts the tftp directory in the filesystem
<Fallenou>
it's kind of weird
<Fallenou>
to test the network driver i had to write the tftpclient
<kristianpaul>
why you dont used  ttcp to test? it inmeadiatly fire the overflow bug ! ;)
<Fallenou>
oh !
<Fallenou>
never tried
<Fallenou>
can you repeat several times ?
<Fallenou>
and confirm it triggers the problem ?
<Fallenou>
thanks !
<kristianpaul>
dint said yes yet
<kristianpaul>
ok
<kristianpaul>
Fallenou: you already know that ifconfig trigger the problem, why no start from there?
<kristianpaul>
There are more that one trgger for sure
<Fallenou>
if i have several things to test it's better
<Fallenou>
and i think ifconfig may be another bug
<kristianpaul>
hmm, ok
<Fallenou>
because it's obviously not a full fifo problem
<kristianpaul>
yeah, that call  my atention with ifconfig (fifo)