Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 13 Jun 1999 21:55:45 +0200 (CEST)
From:      Rene de Vries <rene@canyon.demon.nl>
To:        wpaul@ctr.columbia.edu (Bill Paul)
Cc:        freebsd-alpha@freebsd.org
Subject:   Re: Problems getting the 'rl' driver to work
Message-ID:  <199906131955.VAA00550@canyon.demon.nl>
In-Reply-To: <199906131746.NAA01613@sirius.ctr.columbia.edu> from Bill Paul at "Jun 13, 1999  1:46:43 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
From the keyboard of Bill Paul:
> There is a saying that goes "that's like putting a jet engine on a
> rowboat." What you are attempting to do is exactly the opposite of
> that saying. Perhaps like trying to put oars on an aircraft carrier.

This particulare alpha is more like an inflatable raft. Full kernel builds
take about 45 min (with softupdates, although that does not really matter
;-(). A complete build takes about 13 to 14 hours. This alpha is sort of my
little sandbox....

> > With the help of some printf statements I found that the problem must be in
> > calling the 'CSR_WRITE_1(sc, RL_COMMAND, RL_CMD_RESET);' macro, which
> > translates to a 'bus_space_write_1'. I know that there is a problem/feature
> > on alphas keeping them from accessing memory at unaligned adresses, but I
> > assumed that that whould be handled in writeb (called from bus_space_write).
> 
> I don't think this is the real problem. The situation is complicated
> somewhat by the fact that gdb on FreeBSD/Alpha isn't smart enough to
> debug kernel crash dumps (at least, I don't think it is) otherwise you
> would have a better way to track down the problem. The 3Com XL driver
> uses byte-wite I/O accesses in a few places and has no problems, so
> I'm doubtful that this is really what's tripping you up.

I also took a look at that driver and tried to initiate a "monkey see monkey
do" (where I am playing the role of monkey). In other words what some other
driver can do must be possible to do in this one.

I also tried the code with the bus_space... changed into a construct with 
a lot of ((*(volatile u_int8_t*)((sc)->csr + (u_int32_t)(reg))) stuff. This 
resulted in a non-panicing kernel, but it complained that the reset did not
appear to work. So this also lead me to think that these bus_space...
thingies do something special (like checking the exact machine type). I know
that this alpha chipset needs a workaround to read/write unaligned bytes.
But I thought that this was where the bus_space... stuff came in.

> Ideally, there should be only two things that need to be fixed in order
> to make this driver work with the Alpha:
> 
> - rl_btag has to be set correctly, which you say you already did

Did this to keep the compiler from screaming...

> - Receive buffer handling has to be tweaked to force longword alignment
>   of packet payload data.
>
> The RealTek driver uses m_devget()/m_copyback() to read packet data
> out of the receive buffer and into mbuf chains. The problem is that
> m_devget() doesn't allow you to specifty an offset into the mbuf
> data area, so all data starts at the very beginning of the mbuf,
> which is longword aligned. The ethernet header is only 14 bytes long
> though, so the actual packet data is only word aligned. The simplest
> thing to do is to copy two extra bytes from the receive buffer starting
> from the current buffer position minus 2. You can then use m_adj()
> to shave off the 2 leading bytes after the copying is done and
> end up with the proper alignment.

Sounds like a hack, but I'll try to encorporate this into the driver over
here. But I'd wish that the driver came this far... It doesn't even get thru
its reset cycle.

> I have some code to do this but I can't test it until Monday because
> my sample RealTek card is at work, and me and my alpha are at home.
> In the meantime, I would suggest trying to find another card.

Hmmm, have to look at that, I could always swap this card with some other
W95 machine that has a DE500 card. They probably won't see any difference...
But on the other hand this might be the project for me to lose my fear to
modify some kernel bits...

> -Bill

-- 
Rene de Vries                    http://www.tcja.nl/~rene; mailto:rene@tcja.nl


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906131955.VAA00550>