Re: New Install
On Mon, Sep 18, 2000 at 12:35:21AM +0200, Marcus Brinkmann wrote:
> On Sun, Sep 17, 2000 at 05:23:27PM -0500, Neal H Walfield wrote:
> > > > > All in all, I think the interrupt business is where the problem lies.
> > > > > The behavior is just like what I'd expect if I knew there were interrupt
> > > > > problems.
> > >
> > > I'm beginning to have my doubts. Is there a way to get information about
> > > what devices are using what interrupts, ioports, etc.? The boot messages
> > > go by pretty fast and the logs are pretty barren. Diagnostic information
> > > of any kind would be helpful.
> >
> > Under linux, try looing in proc (ie cat /proc/interrupts). As gnumach uses
> > the 2.2 drivers, things should be detected in the same manner.
Been there, done that. The BIOS isn't assigning an interrupt anymore
but linux is (to the USB controller that is). /proc/interrupts says:
...
5: 2186 XT-PIC eth0
...
But, /proc/pci says:
...
Bus 0, device 7, function 2:
USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 1).
IRQ 5.
Master Capable. Latency=32.
I/O at 0xc000 [0xc01f].
... and ...
Bus 0, device 9, function 0:
Ethernet controller: VIA Technologies, Inc. VT86C100A [Rhine 10/100] (rev 6).
IRQ 5.
Master Capable. Latency=32. Min Gnt=118.Max Lat=152.
I/O at 0xc400 [0xc47f].
Non-prefetchable 32 bit memory at 0xea001000 [0xea00107f].
...
I was hoping for some hurd/gnumach specific tools to find out how they're
initialized there.
>
> You wish...
>
> 1998-11-17 OKUJI Yoshinori <okuji@kuicr.kyoto-u.ac.jp>
>
> * i386/README-Drivers: Update to Linux 2.0.36 device drivers.
> ^^^^^^
That's kind of why I was thinking that rebuilding gnumach with a newer
via-rhine driver may be worthwhile, if it's not too much grief due to
changes in the pci code or anything like that.
>
> But your argument still holds.
Does that mean that if linux assigns an interrupt to the USB controller
that I can expect gnumach to do the same?
While I was "away", did some more experiments.... With no --netmask
argument to settrans, ping doesn't hang, I get instead:
ping: sendto: Network is unreachable
ping: wrote: 192.168.56.1 64 chars, ret=-1
Which looks more like a routing problem than a network card problem.
Sort of - could be the kernel never sends it to the card. Dunno if this
is useful.
Next experiment. Found and used rpctrace (rpctrace -ologfile ping
192.168.56.1). 4241 lines of cryptic logfile, maybe meaningful to you
guys but not to me. The interesting part is at the very end.
port 128(=>118) receives (type 17) msgid 20018, 1068 bytes in msg
reply port 106 (type 18)
"lib/libnss_files.so.2"
0x1 (type 2, 1*4)
which is where it stalls. So, I poked around with taking dns out of
the hosts line of nsswitch.conf, changed resolv.conf to "nameserver
127.0.0.1", created a networks file, then an ethers file, pinged
from the other side in case it needed an entry in the arp/rarp cache.
Tested after each change and none of this panned out. I wonder what
libnss_files is stuck on?
BTW, changing the NIC IRQ from Windows is not an option. I mis-remembered
- it's the modem that can be tweaked this way, not the NIC. Disabling USB
IRQ assignment by the BIOS appears the best I can do with this mobo/BIOS
combo (the mobo is an ABIT BE6).
Also, I checked the error I got from tcpd postinst. It's a postinst bug.
I'll file it later if it's not already submitted. A misplaced EOF or a
missing # which results in comments intended for hosts.deny not getting
there - harmless.
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).
This'll probably have to wait until next weekend or so. I've spent
another day on this when I should be doing other stuff :) (but it's fun!
I love this debugging stuff...)
Thanks and TIA for anything else you can think to try,
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: