I have made an (ugly) hack around the transmit problem (but then again, aren't
hacks ugly all the time?). I still don't know if this is the proper thing, but
the point is that it seems to work now. I don't know if it is my mistake or
the cards mistake that I cannot schedule more than one write at a time, but
I'm looking into this. I don't know the difference in performance between this
driver and the one in R5, but I'm guessing this one's still a bit slower. I'll
continue to hack the driver in order to maximize performance.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@4364 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Borrowed the UHCI basic theory of operation from the freebsd handbook
- Started some work on the internals of devices
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@4279 a95241bf-73f2-0310-859d-f6bbb57e9c96
ready for testing. Also the documentation is far from complete (it's in it's early phases).
Unfortunately I don't have enough experience in hardware programming to prototype
it first, so I'll be testing the things that I design in the document.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@4275 a95241bf-73f2-0310-859d-f6bbb57e9c96
1.23: fix some compile errors on PPC
1.24: Finalising some PPC changes. In theory it should work
1.25: Second round of PPC fixes. I hope it works now.
1.26: Adding the reset function when there are rx problems
1.27: Added the chip id for the 8101L
1.28: Minor code cleanup
1.29: Implemented multipe card support
1.30: drop some debug output
1.31: FINALLY fixed the receive problem (where large packets slow down
everything)
What remains to be done is to fix the transmit bug, where the card
suddenly stops to send packets (after it gets behind by one).
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3993 a95241bf-73f2-0310-859d-f6bbb57e9c96
the same name somewhere else( I think). At least it works now. Renamed
to _resolve_configuration (probably will never clash with anything else ever)
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3565 a95241bf-73f2-0310-859d-f6bbb57e9c96
the same name somewhere else( I think). At least it works now.:
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3564 a95241bf-73f2-0310-859d-f6bbb57e9c96
think that it shouldn't drop any packets anymore (only delay them)
- I implemented a packet wrap, so after 64k the driver will start over again
- I fixed a bug where packets with the largest ethernet frame size (1514)
weren't accepted.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3561 a95241bf-73f2-0310-859d-f6bbb57e9c96
Sorry for the enthousiasm. For the first time in my life a made a driver
somewhat work. There's still a major list of things to do, but at least I
feel safer now that this is working. I can already do pings. Moreover, I'm
doing this commit with my own driver. I'm just ashamed for the major mistake
I made that took me so much time to find. I'm off sending this beast to
testers.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3555 a95241bf-73f2-0310-859d-f6bbb57e9c96
the interrupt handler, now it is done in the read_hook itself. This means that
less memory is used because the packet reception isn't double-buffered anymore.
It also wasn't the performance it I'd expect it to be (probably thanks to BeOS
scheduling!). The problem with the strange loss of around 50% of the packets
remains.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3526 a95241bf-73f2-0310-859d-f6bbb57e9c96
