Re: Further on P4R800-VM and 3c59x

Andrej Prsa <[email protected]> Mon, 5 Jan 2004 16:18:16 +0100
Newsgroups gmane.linux.drivers.vortex.devel
Organization Faculty of Mathematics and Physics
Message-ID <[email protected]>
Hi!

> > I assure you I won't give up until we all run out of ideas! ;)
> 
> OK, let's see :-)
> 
> > nothing out of the ordinary is reported in /var/log/messages,
> 
> You don't get tons of messages prefixed by "eth0:" (or whatever number
> the interface is) ? Then setting up the debug level didn't work...

Hmmm, that's weird; my settings are:

/etc/modules

  3c59x

/etc/modules.conf

  alias eth0 3c59x
  options 3c59x debug=6

I don't get any extensive printout to /var/log/messages.

> > media link is found and recognized as 100Mbit full duplex.
> 
> When this happens, what is the state of the desktop computer ? Is the 
> driver loaded or not ? If yes, does mii-diag report something different 
> before connecting the cable and while it's connected ?

The driver was loaded, but I tried unloading it (even removing it from
/etc/modules and rebooting, just to be 100% sure), the link still gets
recognized as 100Mbit full duplex. Here is the relevant part from laptop's
dmesg:

eth0: Media Link Off
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timeout, status 00000004 00000000 
eth0: Media Link On 100mbps full-duplex 

This is with or without the 3c59x driver loaded.

> > network cards have to talk to each other, right?
> 
> Yep, carrier signals and so on.
> 
> > I also checked /proc/interrupts, which are increasing as they
> > should,
> 
> When ? Could you try to make a difference between transmitting and 
> receiving ? For example, if you assign a fixed IP on the same subnet to 
> your laptop, you could start "ping" from the laptop; if /proc/interrupts
> start increasing, it means that it's receiving.

Desktop:
  ifconfig 192.168.0.1 pointopoint 192.168.0.2 netmask 255.255.255.255 up
Laptop:
  ifconfig 192.168.0.2 pointopoint 192.168.0.1 netmask 255.255.255.255 up

When pinging from laptop to desktop, /proc/interrupts increases by 2 per
ping (1 second).
When pinging from desktop to laptop, /proc/interrupts increases by 1 per
ping (1 second).

In both pinging cases /proc/interrupts on the laptop doesn't change. The
laptop card is a SiS7012, which works without issues with other cards.

> For transmission is a bit more difficult, one way would be to watch with
> tcpdump/ethereal if any packets arrive at the other end (on the laptop, 
> for example).

Listening on laptop with tcpdump is silent, but listening on desktop with
tcpdump clearly sees packets:

16:03:45.501167 arp who-has 192.168.0.1 tell 192.168.0.2
16:03:45.501187 arp reply 192.168.0.1 is-at 0:e:a6:d:d7:65

(one such block per ping). Thus I suspect receiving is ok, but sending
doesn't work, right?

> > /proc/dev/net seems ok as well.
> 
> But as you didn't include it, I can't see if there were any
> packets/bytes accounted for transmission and/or reception :-)

eth0:

Receive bytes:    9594
Receive packets:  80
Everything else:  0

Transmit bytes:   7140
Transmit packets: 120
Everything else:  0

Where these transmition packets probably come from pinging its own IP (I
was checking whether self-pinging produces any eth0: logs in
/var/log/messages, it doesn't).

> > Everything is ok that I can tell, except for this glitch of not
> > working at all! ;)
> 
> Isn't it always like this ? :-)

Yep, but especially like that with this troublesome motherboard; network
card is the very first device I'm trying to bring to life and there are 12
pci entries with "Unknown device" description... Glb... ;)

> > 	Flags: bus master, medium devsel, latency 64, IRQ 3
> 
> By the way, is the interrupt shared with some other device ?

Not that I know of. Any certain way to make sure?

After a last look at /var/log/messages, there is a new eth0 entry:

16:03:36 eth0: Setting promiscuous mode.
16:03:36 device eth0 entered promiscous mode
16:03:52 device eth0 left promiscous mode

No idea what that means. ;)

Thanks a lot,

Andrej
_______________________________________________
vortex mailing list
[email protected]
http://www.scyld.com/mailman/listinfo/vortex