[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: New Install



On Mon, Sep 18, 2000 at 05:32:35AM +0200, Marcus Brinkmann wrote:
> On Sun, Sep 17, 2000 at 08:19:38PM -0700, Steve Bowman wrote:
> > Sorry to followup on my own post, but....
> > 
> > On Sun, Sep 17, 2000 at 05:11:51PM -0700, Steve Bowman wrote:
> > > Any other ideas, comments, questions?  I think it's time to move on
> > > to trying gnumach with a newer via-rhine driver (if it'll compile).
> > 
> > Did a quick go at compiling gnumach.  Built with no problems using
> > the existing via-rhine.c using only: --enable-floppy --enable-ide
> > --enable-viarhine .  But it still doesn't work so it looks like it's not a
> > driver conflict.
> > 
> > Tried again with a via-rhine.c from linux-2.4.0-test1.  Doesn't compile -
> > I've updated 16 headers from the linux source tree so far and I've only
> > pushed the first error down about a quarter of the way through the file.
> 
> That way lies madness. It makes much more sense to look at the latest 2.0.x
> version of the driver, and probably 2.2.x as well, but do not blindy copy,
> but check which parts could be relevant, and always take care not to suck in
> interface changes. 

I know it.  I just wanted to see how radically the driver and its
supporting infrastructure had changed.  It's changed too much to be worth
it unless I want to do some more serious hacking than I had in mind.
The driver in the gnumach source is v1.00, the one in 2.4.0-test1 is
v1.05-LK1.1.5, and I found an older one in kernel-source-2.2.14 that is
v1.01 which I'll try when I can get back to this.  If this is close to
working, I may want to talk with you more about how to avoid sucking in
interface changes.  One of the reasons I wanted to bring up The Hurd is
that I'll learn it better by using it than reading about it.  Since I
haven't got there yet....  I'm not sure I'm ready to do that serious
of driver hacking yet since I don't know where the compatibility issues
and such lie.

While looking at the pci.c source, it occurred to me that changing slots
may be worth trying as well.  I remember this board needs a bus-master
slot and at least one slot won't work, but it's another thing I can
experiment with.  In fact, I'll probably do this next since it's easy and,
with luck, I'll be able to rule out any nagging IRQ doubts.

Another thing I could do, and the reason I was looking at pci.c, was to
see if I could just out-and-out disable detection of the USB controller,
i.e., arrange that it doesn't get an interrupt assigned.  If the slot
switching doesn't let me remove all (potential) conflicts, this should
do it.

If none of the above gets me anywhere, I'm pretty much stuck unless I
come up with some new ideas.  The only other thing that occurs to me at
the moment is to try oskit.

> Good luck,
> Marcus

I think I'll need it.  Thanks,
Steve

-- 
Steve Bowman  <sbowman@frostwork.net> (preferred)
Buckeye, AZ   <sbowman@goodnet.com> <bowmanc@acm.org>
              <http://www.goodnet.com/~sbowman/>

Powered by Debian GNU/Linux <http://www.debian.org>



Reply to: