# sit0 and how long ?

## whathappenedtoadduser

Does anyone know where sit0 comes from and what it is for ?  The IPv6 scripts are not where the IPv6 web page says they will be.  There are hints elsewhere that sit0 interferes with eth0 assignment and routing and people have #'d it out in /etc/hosts.

Any thoughts.

I have 2006 cooking now (as basic as I could make it and live with it) but GLI has stopped logging DEBUG at call to /sbin/dhcpcd complete.  Is it stalled ?  I can hear the fan increase speed and it sounds like the cdrom is being called periodically, but otherwise no sign of life or progress.  Should I wait 19 hours before pulling the plug ?

----------

## NeddySeagoon

whathappenedtoadduser,

sit0 is an IP6 over IP4 tunnel device. It does not interfere with anything.

----------

## whathappenedtoadduser

If I pointed to the hole in the ground at Baltimore and asked, "Where did that come from and what's it for ?" and got the reply "that's the Baltimore Harbor Tunnel", it would be fairly comparable to your post.  It's unresponsive to the questions where did it come from and what is it for ?

I appreciate your guarantee that sit0 interferes with nothing.  There are other opinions on the matter though.  As you say, the IPv6 tunnel is a device.  I will just observe I have never seen a report of a sit1, but have seen innumerable reports of eth1's when only one network card has been installed.

----------

## NeddySeagoon

whathappenedtoadduser,

Having eth0 and eth1 when you only have one real network card (and its eth1) is a well understood issue.

Its invarably due to using genkernel on a box that supports firewire. eth0 is then ethernet over firewire, which almost nobody wants because the implementation of ethernet over firewire is incomplete. The few people who do want ethernet over firewire usually don't want it to be eth0 either.

Preventing eth1394 loading fixes this. The long term fix is to avoid allowing genkernel to configure your kernel.

I'm not sure why sit0 is created for you but you can create others if you need to. I don't have any IP6 support at all and I don't have it. I guess it comes with IP6 support in the kernel.

----------

## whathappenedtoadduser

Well, as I still have not learned what this IPv6 tunnel for the future is for in the here and now, but sit0 is now a well known issue with firewire, or, I think more accurately, what hardware detection reports as firewire, I admit to some confusion.  I was hoping somebody would post IPv6 must be in the kernal because...  Now, it just seems all the instances of the well known issue with sit0 are happening because nobody took the code for IP6 support out of genkernal.

Is 19 hours about right for cooking time ?

----------

## cyrillic

 *whathappenedtoadduser wrote:*   

> If I pointed to the hole in the ground at Baltimore and asked, "Where did that come from and what's it for ?" and got the reply "that's the Baltimore Harbor Tunnel", it would be fairly comparable to your post.  It's unresponsive to the questions where did it come from and what is it for ? 

 

LOL

Are you actually having an installation problem related to IPv6 ?

Most people have an IPv4 only local network and an IPv4 only ISP, so IPv6 can be ignored in most cases.

----------

## whathappenedtoadduser

Actually, I don't know for sure if the computer is stalled or compiling.  I started it yesterday and nothing has changed since the last DEBUG message I originally posted.

If anything comes from what I have done so far, I expect an IPv6 problem because I have never yet gotten to the internet with the gentoo.  I put up 

dhcpcd does not communicate with westell 2200 via DP83815

in Networking and Security a while ago and 32 have read it but noone has replied.  I was hoping a bunch would jump up and say "Oh, yes it does."

Anyway, I found this and started compiling (I think) on hope alone:

"I commented the Ip 6 lines in /etc/hosts. Until now this solved my dhcp and loosing connection to the router problems

127.0.0.1 localhost.localdomain localhost ubuntu

# The following lines are desirable for IPv6 capable hosts

# ::1 ip6-localhost ip6-loopback

# fe00::0 ip6-localnet

# ff00::0 ip6-mcastprefix

# ff02::1 ip6-allnodes

# ff02::2 ip6-allrouters

# ff02::3 ip6-allhosts

# In other words:

# The preceding lines are undesirable for me and quite a few other people  :Wink: "

Here's something which says there should be no sit mode used at all if you don't need IPv6.

4.1. GRE tunnels

If you don't need IPv6 but for example you want to carry normal IPv4 traffic through a non-cooperating transit network, then you'd better use mode gre instead of mode sit.

http://members.ferrara.linux.it/pioppo/howto/iproute2tunnel-en.html

Will To completely discard our tunnel we use:

ip tunnel del foo

work on gentoo ?

I don't think there is a present need to go into the IPv6 tunnel unless you are French military, maybe,

IPv6-DRET is a public implementation of the next generation Internet Protocol, IPv6, funded by the DGA/DRET (French Military Research Agency) and co-developped by INRIA Sophia-Antipolis and MASI laboratories.

http://www-sop.inria.fr/rodeo/IPv6/IPv6-noframe.html

This turned up in an relatively ancient document, but I wonder what has changed:

"There are only about three IPV6 options, and I recommend turning them all on.  It may be

easier modularising all IPV6 code, so you know you can completely remove it anytime you

don't want to be using it.  By this I mean, disabling it after you've finished playing

doesn't require a kernel compile.  I've noticed that once support is enabled, all interfaces

seem to bind to an IPV6 address, even if not specified when being raised, remembering the

last given address.  This may irritate some people."

I may be one of those people.

----------

## NeddySeagoon

whathappenedtoadduser,

/etc/hosts is a one to one index of names and IP addresses. Providied you don't use the same name for both an IP4 and and IP6 IP addess, they happily co-exist. On IP6, there is no auto IP address assignment by DHCP because its not required. All IP6 devices assign themselves an IP6 IP and broadcast it to the next hop router. Thats why with IP4 and IP6 installed your interfaces can get an IP6 adddress but not an IP4 one.

Anyway, your can't get internet on Gentoo issue. Please post the output of 

```
lspci
```

 command, at least your firewire and ethernet lines. Also the names of any interfaces you see in 

```
ifconfig -a
```

 Lets take the guesswork out of it and start from first principles.

If you do have an ethX interface at all, whats its HWAddr ?

----------

## whathappenedtoadduser

No doubt IPv4 and IPv6 can happily co-exist.

OK, in the startalloveragainnoguesswork spirit, I rebooted and entered

gentoo-nofb acpi=off doscsi noapic nohotplug nofirewire nox doload=alsa

because I saw it whining about no alsa modules last go around.  I plugged the RJ45 in and let 'er rip again.  All lights green.

So it whirled and churned and complained again about alsa modules and no evdev and no open GL capable card found.  [I'd like to know what that last means.]  This is an installation for a compaq presario 2190US.

So, at the livecd root# prompt lspci yields (I'm abbreviating some)

Host Bridge  ATI Corp  RS200/RS200M

PCI bridge ATI Corp  IGP 340M

USB controller ALi Corp

Multimedia controller ALi

ISA bridge ALi M1533/M1535 Aladdin IV/V/V+

Modem ALi M5457 AC '97

Cardbus Bridge 02 Micro Inc OZ601/1912/711E0

IDE interface ALi M5229 rev c4

Bridge: ALi Corporation M7101 Power Management Controller

Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter)

VGA compatible controller  ATI Radeo IGP 330M/340M/350M

ifconfig -a yields

eth0 Link encap: Ethernet

                   BROADCAST NOTRAILERS MTU 1500 Metric:1

                   RX all zeros for packets

                   TX packets 12 errors

                    no collisions txqueuelen:1000

                    7070 TX bytes

                   Interrupt 10  Base address 0x80000

lo Link encap:local Loopback

               UP  no errors

[notice no sit0 which gives me greater confidence about the possibilities for peaceful co-existence between IPv4 and IPv6 in the bowels of the machine]

ping 192.168.1.254 yields connect: Network is unreachable.

The first module listed by lsmod is natsemi.  There is no module with 1394 in it listed.

So, I moved the RJ45 back to this machine and here we are.  Let me say going in that if the gentoo cannot plug and chug with the dhcp as is on the westell 2200, I'd be sad but it would'nt be for me, until it can.

----------

## whathappenedtoadduser

I might add dmesg says

natsemi eth0: NatSemi DP8381[56] at 0xd0004000 (0000:00:12:0), 00:0d:9d:44:cc:93 [note, ecept for letter case, this is the same as HWaddr], IRQ 10, port TP

eth0: DSPCFG accepted after 0 isec.

eth0: remaining active for wake-on-lan

----------

## NeddySeagoon

whathappenedtoadduser,

Looking at your hardware list, its should all work with gentoo with the possible exception of the winmodem but thats a sound card extension, so you never know. The ATI video card is a bad choice for Linux but doable.

Your network card needs the natsemi kernel module, so its good to know its loaded.

It appears that you didn't get an IP address from DHCP, that can be fixed for the install when you know why.

Meanwhile, run 

```
net-setup eth0
```

to give it another go. Maybe you need a timeout setting thats not part of the liveCD default. I presume 192.168.1.254 is the address of something on your network that has a static IP, e.g. your router ?

evdev is the kernel touchpad module, its only needed for the advanced touchpad features.

openGL is a Graphics Lanugauge. Its high level commands can be implemented in hardware, in which case its said to be hardware accelerated, or software, which is much slower, since the CPU has to do all the calculations and pixel plotting.

It can also be a mix, which is much more usual. You used the nox option, so the liveCD should not check for openGL. It needs X.

ALSA will work but you don't need it for the install - ignore the messages.

----------

## cyrillic

 *whathappenedtoadduser wrote:*   

> I might add dmesg says
> 
> natsemi eth0: NatSemi DP8381[56] at 0xd0004000 (0000:00:12:0), 00:0d:9d:44:cc:93 [note, ecept for letter case, this is the same as HWaddr], IRQ 10, port TP 

 

OK, eth0 wants IRQ 10

Now check /proc/interrupts to see if eth0 has IRQ 10 there also.

If eth0 doesn't show up in /proc/interrupts , then you have an IRQ routing problem.  This will prevent your NIC from working properly, including getting an IP address from DHCP.

----------

## whathappenedtoadduser

ok, in the spirit of simplifying, I rebooted and started with

gentoo-nofb acpi=off doscsi noapic nohotplug nofirewire nosata nosmp nox

Everything as before, up to and including dmesg output.  I did net-setup, selecting wired and dhcp.  I got this output:

type ifconfig to make sure the interface was configured correctly.

The output to ifconfig is lo UP & RUNNING.  In other woids, going through net-setup knocked eth0 to a down state.

ifconfig eth0 up followed by ifconfig yields

eth0 Link encap:Ethernet HWaddr 00:0D:9D:44:cc:93

UP BROADCAST NOTRAILERS MULTICAST MTU:1500 Metric:1

RX Packets:  all zeros

TX packets: 14 errors

TX bytes 8260

Interrupt 10 Base address  0x2000

lo Link encap: Local Loopback 

inet addr: 127.0.0.1 Mask 255.0.0.0

UP RUNNING MTU: 16436 Metric:1

RX & TX packets: 4 no errors, drops, overruns frame:0 and carrier: 0

RX & TX bytes: 280

When the RJ45 is inserted the console message is eth0: link up

During boot something like "DHCP broadcasting" was output.

Machine needs to be a dhcp client.  192.168.1.254 is the machine side address [it has another address on its network side] of the westell 2200.  When this is working properly nameserver is 192.168.1.254 and search is launchmodem.com in /etc/resolv.conf.  At the moment, /etc/resolv.conf has the junk entries I listed in my post in Network & Security.

I can ping 127.0.0.1.

----------

## whathappenedtoadduser

In /proc/interrupts there is a row reading

10:  16   XT-PIC ohci_hcd:usb1, eth0

I have no usb devices plugged in.

----------

## whathappenedtoadduser

Here is something maybe interesting, which I have not noticed before.  On this ubuntu implementation 2.6.12-10-386 (which did the dhcp dance)

ifconfig -a yields

eth0      Link encap:Ethernet  HWaddr 00:13:46:77:E8:33

          inet addr:192.168.1.97  Bcast:255.255.255.255  Mask:255.255.255.0

          inet6 addr: fe80::213:46ff:fe77:e833/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:4479 errors:0 dropped:0 overruns:0 frame:0

          TX packets:4283 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:3953961 (3.7 MiB)  TX bytes:556650 (543.6 KiB)

          Interrupt:10 Base address:0x3000

lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0

          inet6 addr: ::1/128 Scope:Host

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:133796 errors:0 dropped:0 overruns:0 frame:0

          TX packets:133796 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:8319386 (7.9 MiB)  TX bytes:8319386 (7.9 MiB)

sit0      Link encap:IPv6-in-IPv4

          NOARP  MTU:1480  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

And it does not seem to matter whether the IPv6 lines are #'d out in /etc/hosts or not.  However, they are at the moment and I have rebooted since #ing them.

# The following lines are desirable for IPv6 capable hosts

#::1     ip6-localhost ip6-loopback

#fe00::0 ip6-localnet

#ff00::0 ip6-mcastprefix

#ff02::1 ip6-allnodes

#ff02::2 ip6-allrouters

#ff02::3 ip6-allhosts

----------

## whathappenedtoadduser

I just had a micro brainstorm.  It looks like usb and eth0 are sharing IRQ 10.  I am going to restart with nousb and see what happens in /procs/interrupts and generally and will post after.

----------

## whathappenedtoadduser

OK, did all that and now there is no competition in /procs/interrupts for IRQ 10.  eth0 has it all to its lonesome.

Otherwise, nothing changed.

----------

## NeddySeagoon

whathappenedtoadduser,

Can you get a working IP with Gentoo if you run 

```
net-setup eth0
```

----------

## whathappenedtoadduser

Running net-setup eth0 gives exactly the same result as before.

/etc/init.d/net.etho start does not succeed either.

This is after having started 

gentoo-nofb acpi=off noapic nohotplug nofirewire nosata nosmp nousb nox

lsmod shows 4 modules total.  natsemi is number 1.

eth0 transmits, sets up full duplex,  and it autonegotiates 

advertising 0x5e1 partner 0x00

dmesg says eth0:  remaining active for wake-on-lan

ping 192.168.1.254 returns network unreachable

----------

## cyrillic

 *whathappenedtoadduser wrote:*   

> Let me say going in that if the gentoo cannot plug and chug with the dhcp as is on the westell 2200, I'd be sad but it would'nt be for me, until it can.

 

At this point, I would just give up, pop in a KNOPPIX CD, and use that to install Gentoo.

It looks like the Gentoo 2006.0 CD does not like your hardware very much (or vice versa).

----------

## whathappenedtoadduser

"Looking at your hardware list, its should all work with gentoo with the possible exception of the winmodem" ...

What is going to be any different about the gentoo on my hard drive ?  Isn't  the livecd live gentoo ? what are these DHCP options which I am invited to enter by the livecd ?

Is there a command  like dhclient which will give feedback during the attempt to obtain an IP and lease ?

----------

## whathappenedtoadduser

Can I emerge dhclient using "emerge net-misc/dhcp" from the cdrom into the livecd environment ?  How do I address the emerge request to the proper file system on the cdrom ?  

DHCP can be provided by dhcpcd, dhclient, udhcpc or pump.  I notice that dhclient supports hibernation.   None of the dhcpcd options is working to get an answer from the westell 2200 and there is no feedback and the debug info is going into the void, apparently, since a log file it depends on is not there.

----------

## cyrillic

 *whathappenedtoadduser wrote:*   

> "Looking at your hardware list, its should all work with gentoo with the possible exception of the winmodem" ... 

 

I happen to agree with NeddySeagoon.

 *whathappenedtoadduser wrote:*   

> What is going to be any different about the gentoo on my hard drive ?  Isn't  the livecd live gentoo ? 

 

The LiveCD is Gentoo with a poorly configured kernel, and quite a bit of weirdness in the init scripts.  Don't assume that Gentoo on your harddrive will work the same way.

----------

## NeddySeagoon

whathappenedtoadduser,

You can't emerge anything until your have the stage3 tarball untarred. There is no tool chain on the minimal liveCD.

I'm with cyrillic on the alternate install. Its time to give the very new 2006.0 a bye and use another install method.

You don't need Gentoo to install Gentoo and the gentoo you get on your hard drive will be different to the liveCD.

The liveCD tries to be a general purpose distro, to run on as many hardware platforms as possible - but it does not cover everything.

You could try one of the older command line liveCDs - you will get exactly the same Gentoo when its installed.

----------

## nixnut

Moved from Installing Gentoo to Networking & Security.

networking stuff, so beter off here.

----------

## whathappenedtoadduser

OK, thanks for comments.  Sorry I'm having such a hard time.  If anybody has installed gentoo and gotten it to work with the DP83815 and natsemi driver, I hope they will come forward.

To get more facts for analysis, I attempted to reach the network using the livecd 2006 on my 600is e-machine (don't laugh; it's a good value) and my advice is don't try (too many missing modules).  On the other hand, the 2005 livecd started with (this took some experimenting to find) 'gentoo-nofb noapic nohotplug' cranked right up and networked with the via-rhine driver loaded to Via Tech VT6105, which I think is retailed as D-Link.

This told me dhcpcd will communicate with the westell 2200 via via-rhine-VT6105 and it enabled me to get facts for comparison.  The via-rhine-VT6105 is using port MII, internal transceiver, wake-on disabled, and message level 0x00000001 (1). From ifconfig, it reports NO TRAILERS.  The natsemi-DP83815 is using port TP, internal transceiver, wake-on ub, and message level 0x000040c5 (16581).  From ifconfig, it does not report NO TRAILERS.  The values set for the DP83815 cannot be changed using ethtool to match those in the VT6105.   When port is changed to MII, transceiver changes to external, speed to 10, and mode to half duplex, and link detected changes to no.  Something is preventing the DP83815 from supporting all speeds and modes on all ports.

So, if there are options to pass to the natsemi driver, can that be done when it is modprobed or included for compile ?  Or is there an alternative to natsemi for the DP83815 ?

And is IPv6 support in the installed kernel, because now I know it's not in the livecd kernel ?

Just my opinion, but I think this is an install not a network issue.

----------

## whathappenedtoadduser

I found this at 

http://www.national.com/appinfo/networks/files/linux_readme_2_2.txt

DP83815 10/100 PCI Ethernet Driver v1.31 for Linux v2.2.x

=====================================================================

1. FILES IN THIS RELEASE

------------------------

The following files are included in a tar ball, linux_2_2_dp83815.tar.gz

  README.Linux   - This file

  dp83815.c      - Driver source file

  dp83815.h      - Driver header file

  dp83815.o      - Driver object module for v2.2.14

  Makefile       - Rules to compile and install the driver.

2. INSTALLATION

---------------

This version of the driver requires a base RedHat Linux ver 6.2 with 

linux kernel version 2.2.14 basic utilities and the C development system.

To install the driver, login as root, and extract the files into an 

appropriate directory.

	# mkdir /nsc

	# cd /nsc

	# gzip -cd linux_2_2_dp83815.tar.gz | tar xvzf -

	# cd /nsc/linux_2_2_dp83815

To create a new driver object module, run

	# make

To install the current driver object module in the filesystem run,

	# make install

	# linuxconf

And, inside the linuxconf, choose "Config", "Networking", "Client tasks",

"Basic host information".  Supply the appropriate information 

such as a valid IP address, Netmask, etc.  For Kernel module, choose

or type "dp83815".  Accept the configuration and "Quit" to exit this

menu page.  On the next menu page, select "Activate the changes" to

put the system in sync with the latest configuration.

The dp83815 driver module will be automatically loaded next time when

the system starts up.

The driver can also be dynamically loaded and unloaded:

To load the driver

	# insmod dp83815.o

To verify the driver has been loaded

	# dmesg

the last line of the messages indicate the interface name (eg: eth0,

eth1 etc) associates with the driver.  The inferface name is needed

for binding the driver to the network.

To bind the driver with the network

	# ifconfig <interface name> <valid IP address>

To shutdown the network connection

	# ifconfig <interface name> down

To unload the driver

	# rmmod dp83815

3. FUNCTIONALITY TESTING

------------------------

When the driver is loaded into the system via `insmod' it probes the

PCI bus to locate all DP83815 devices, and creates control structures

for each. The driver logs a couple of messages available in

`/var/log/messages' for each device with information about its PCI

geographic location, IRQ, IO address, and some basic debug information 

(addresses of some important structures).

All the devices on the PCI bus can be listed by,

	# cat /proc/pci

IRQ and IO address information from this can be correlated with the

information displayed by the driver in `/var/log/messages'

When the TCP/IP stack is initialized, it opens all configured ethernet 

devices, and initializes them for use. At this time, the driver will

perform autonegotiation and log information about the link status.

The driver can then be tested by running ping, telnet, ftp, NFS etc.

4. KNOWN DRIVER PROBLEMS

------------------------

o  Since the device requires that the receive buffer be aligned on a

   4-byte (word) boundary, it is not possible to align the IP header

   on a word boundary unless the received packet is copied. Since this

   version of the driver support a no-copy receive operation, the IP

   header will not be aligned. This is not a problem for Intel CPUs,

   but will cause exceptions on RISC CPUs (PowerPC, Alpha, ...). While

   porting the driver to these platforms, the no-copy receive can be

   turned off, but setting the DP_RX_COPY_THRESHOLD to ETH_MAX_PKT_SIZE,

   whereby forcing all receive buffers to be copied.

   The driver ensures that the IP headers in a copied buffer is aligned

   on a word-boundary.

5. BUG REPORTS

--------------

Bug reports and enhancement requests should be directed to

<support@nsc.com>. Please include the driver version number,

hardware information, and Linux kernel version number along with the

bug report.

------------------------------------------------

What is also interesting is that there is a later driver there for the DP83815 and linux kernel 2.4,2.6

http://www.national.com/appinfo/networks/files/dp8381x_linux_ver_1.0.tgz

Apparently, kernel changes have required driver changes, so, why is natsemi being distributed at all ?  I just don't think install is done until network is available.

----------

## NeddySeagoon

whathappenedtoadduser,

First, the natsemi driver has been upated from kernel 2.2, to 2.4 to 2.6 its fine.

MII is not an interface It means Media Independant Interface, the media being the wiring. TP is on the otherhand a medium.

Its the most common today.  There is AUI (thich-net) thin-net (10 BASE-2), 10 BASE-T (10 Mb Twisted pair) ....

----------

## whathappenedtoadduser

As I said, and I can read, MIII is a port type on the  dp83815.  I guess you don't take my word for it that its not working here with the natsemi driver or you want me not to believe my lying eyes.  I'm not going to dispute about it.  adieu.

----------

## cyrillic

 *whathappenedtoadduser wrote:*   

> If anybody has installed gentoo and gotten it to work with the DP83815 and natsemi driver, I hope they will come forward. 

 

My rather quirky HP pavilion ze4125 laptop has one of these NICs, and I have been running Gentoo on it for about 2 years.  I am using the natsemi driver that is part of the regular kernel sources.

It may be some other factor that is preventing the LiveCD's natsemi driver from working properly in your case, that is why I was asking about IRQ routing issues earlier.

----------

## whathappenedtoadduser

I appreciate the suggestion regarding IRQ.  But, even when there was only the ethernet card on IRQ 10, nothing changed.  I found 123 matches when I searched on DP83815.   Some seem to have solved out; others not.  In one case, as reported, natsemi did not work with two distributions, but did with a third, the oldest.    I am pretty sure the DSDT is buggy on this compaq.  It seems remote to me at the moment that it would cause this problem, but lots of things have turned out to be differently than they seem.  I admit to a bias in favor of the maker of a card being in the best position to write the driver for it.  Best wishes.

----------

## whathappenedtoadduser

There is an IRQ routing problem but also the natsemi is a 2.4.x kernel port.  Using 2006 livecd, even though I add noload=ieee1394 to the kernel options, I have this from dmesg "ieee1394: initialized config rom entry 'ip1394'".

I am booting with this gentoo-nofb acpi=off lapic pci=routeirq pci=usepirqmask nohotplug doapm nofirewire nousb nosound noload=ieee1394 

legacy is disabled in bios; version KE.MI.73 on compaq type DM745A (presario 2190US laptop)

Early in the boot process PCI is setting IRQ 10 as level triggered and assigning IRQ 10 for device 0000:00:08:0, but then says 'could't register serial port 0000:00:08:0: -28.

Later PCI finds IRQ 10 for the ethernet card.    However, cat /proc/interrupts show nothing for IRQ's 10 or 11, though both are found per putput of dmesg.

I am getting a lot of messages from reiserfs, ext-3-fs, FAT and VFS and an XFS message in dmesg that SB read failed.  

Any suggestions are more than welcome (except install using knoppix).

----------

## cyrillic

 *whathappenedtoadduser wrote:*   

> Any suggestions are more than welcome (except install using knoppix).

 

How about installing with an older Gentoo CD (2005.1, 2005.0, 2004.3, etc.) ?

Or for that matter, how about any distro's LiveCD that has a different kernel than the one on the Gentoo 2006.0 CD ?

ps.  What I am suggesting is that you need a different kernel and/or kernel configuration for things to work properly.

----------

## whathappenedtoadduser

I just found some more kernel options to try.

----------

## whathappenedtoadduser

using 2006 livecd, on compaq 2190US, booting as gentoo-nofb nolapic apm=off acpi=on pci=usepirqmask nosound nofirewire nousb nox,

dmesg shows 12 devices found.  I don't see anything left unregistered by the end of the boot process.  There will even be a laptop lid event for configuration.  So, this is very good.

I still cannot network (wired).  After the livecd prompt, there is this message to console, twice: eth0: link up.  However, ifconfig shows eth0 then is not up.  cat /proc/interrupts then shows no eth0 on interrupt 10, where it should be per dmesg.  modprobe -r natsemi followed by modprobe natsemi causes the same eth0:link up message to console again, in duplicate, and another cat /proc/interrupts at that time shows eth0 on interrupt 10.  Another cat /proc/interrupts a minute or so later shows eth0 missing, again.  ifconfig eth0 up causes the same eth0: link up message to console and restores eth0 to /proc/interrupts.  /etc/init.d/net.eth0 restart causes starting eth0, bringing up eth0, dhcp, Running dhcpcd ... then a pause before two red exclamation marks in blue brackets to the right of the screen and then the livecd prompt returns.  /proc/interrupts then shows no eth0.

ohci_hcd:usb1 is also on interrupt 10.  modprobe -r ohci_hcd removes it from /proc/interrupts.  Then modprobe -r natsemi followed by modprobe natsemi causes the etho: link up to console message and shows eth0 is the only device on interrupt 10.  But then eth0 drops out of /proc/interrupts in 20 or so seconds, leaving no device showing on interrupt 10.

So, not only is dhcpcd failing, but natsemi does not stay in use.

ethtool -i eth0 shows driver: natsemi

version: 1.07+LK1.0.17

firmware-version:

bus-info: 0000:00:12:0

I would be interested to know if there is a firmware version which shows on the  HP pavilion ze4125 laptop when ethtool -i eth0 is run and whether or not XP2 has been used on that machine in the last year or so.  TIA

----------

## cyrillic

 *whathappenedtoadduser wrote:*   

> I would be interested to know if there is a firmware version which shows on the  HP pavilion ze4125 laptop when ethtool -i eth0 is run and whether or not XP2 has been used on that machine in the last year or so.  TIA

 

My ethtool results are identical to yours, and firmware-version is also blank.

I currently have XP pro with SP2 installed.  Every couple of months I will actually boot it, just to see if it is still there.  :Wink: 

----------

## whathappenedtoadduser

Nix that.  I can't get version info out of the via rhine on this machine either.  Per the DP8381x maker, "When the TCP/IP stack is initialized, it opens all configured ethernet devices, and initializes them for use. At this time, the driver will perform autonegotiation and log information about the link status."    What I can't determine, is why the DP8381x is initialized using its port option TP and not port option MII.  The driver is definitely autonegotiating and informing about link status.  If the 'ipieee1394" 'from rom configuration' relates to the DP8381x, that is the initialization problem and its source.  Maybe, the chip maker will respond to a question or two.

----------

## whathappenedtoadduser

Oops.  Post intermediation.  Well, it's interesting nobody reports firmware or maybe ethtool can't ask the right question.  I can't see this as an IRQ problem, now.  Something is causing this driver to go into unused state.  There is a CPU0 colum in /proc/interrupts with numeric values.  Are those the number of interrupt events ?  I just modprobed natsemi out and in.  A few seonds later and natsemi was not listed, again.  That's with no link, no cable attached.  Maybe that's normal when there is nothing attached to a TP port.

I have compiled the maker's 2.6 driver and if I can figure out how to get it onto a floppy here and into the net directory in the livecd environment, I will settle the driver question once and for all.

----------

## cyrillic

 *whathappenedtoadduser wrote:*   

> If the 'ipieee1394" 'from rom configuration' relates to the DP8381x, that is the initialization problem and its source. 

 

ieee1394 is the firewire subsystem, and is not related to your regular NIC (even though firewire can be used as a networking device).

----------

## cyrillic

 *whathappenedtoadduser wrote:*   

> There is a CPU0 colum in /proc/interrupts with numeric values.  Are those the number of interrupt events ?  

 

Yes

 *whathappenedtoadduser wrote:*   

> I just modprobed natsemi out and in.  A few seonds later and natsemi was not listed, again.  That's with no link, no cable attached.  Maybe that's normal when there is nothing attached to a TP port. 

 

No, that's not normal.  The driver will stay loaded and the NIC will still show up in /proc/interrupts with the cable unplugged.

----------

## whathappenedtoadduser

The 'ipieee1394' entry is USB related here, though as you say, normally firewire.  

Kernel v2.6.9 /drivers/net/natsemi.c at http://www.linuxhq.com/kernel/v2.6/9/drivers/net/natsemi.c.  googling reveals a known driver crash problem with pre-patch natsemi, attributed to a random phys reset.  I also notice the maker changed his driver to "3) Wait 100 us between writing dspcfg and reading tdata."  natsemi appears not to wait but accepts DSPCFG in "0 usec".  Anyway, maybe the natsemi has the latest patches, but how could you tell ?   It's obviously crashing though.

----------

## cyrillic

I'm not sure how to tell what patches have been applied to the natsemi driver ...

I am running a fairly recent kernel (2.6.16-rc5), and dmesg shows a fairly ancient version string, but it is working.

```
natsemi dp8381x driver, version 1.07+LK1.0.17, Sep 27, 2002

  originally by Donald Becker <becker@scyld.com>

  http://www.scyld.com/network/natsemi.html

  2.4.x kernel port by Jeff Garzik, Tjeerd Mulder

ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11

PCI: setting IRQ 11 as level-triggered

ACPI: PCI Interrupt 0000:00:12.0[A] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11

natsemi eth0: NatSemi DP8381[56] at 0xe0003000 (0000:00:12.0), 00:c0:9f:13:01:47, IRQ 11, port TP.

eth0: DSPCFG accepted after 0 usec.

eth0: link up.

eth0: Setting full-duplex based on negotiated link capability. 
```

Just curious, but doesn't it seem like a waste of effort to troubleshoot a kernel (the one on the CD) that you won't be using as soon as you have finished installing the base system ?

----------

## whathappenedtoadduser

LOL. I don't see a kernel issue and  I thought it was the distribution I was after.  Portage is not much use with no network.

----------

## cyrillic

 *whathappenedtoadduser wrote:*   

> LOL. I don't see a kernel issue ...

 

I do, and I am surprised that you have not tried a single alternative.

BTW, the Gentoo 2006.0 CD chokes miserably on my laptop too, that's why I usually use a KNOPPIX CD to do my Gentoo installations.

----------

## whathappenedtoadduser

There is no issue of livecd choking the laptop here.  I get a good livecd desktop, good HW detection. lspci is good.  The issue is installing wired network, period.    I want to get the portage during the install.  This is not the only install  or kernel I have tried.   I guess you didn't google natsemi.  Don't care to dispute, though.

----------

## cyrillic

 *whathappenedtoadduser wrote:*   

> The issue is installing wired network, period.  

 

Does wired networking not work with the kernel you compiled ?

I was under the impression that you had not gotten as far as installing the kernel, and you were still struggling with the Gentoo CD.

 *whathappenedtoadduser wrote:*   

> I want to get the portage during the install.  

 

I'm not sure I understand.  If you are installing Gentoo, then you will get portage, that part can't really be avoided.

 *whathappenedtoadduser wrote:*   

> I guess you didn't google natsemi.  Don't care to dispute, though.

 

Well no, I haven't, but that is because the natsemi driver works when I am the one compiling the kernel for my laptop.

----------

