Re: Sun Fire V210 NIC's now working

[Kaya Saman]

Hi Richard,

sorry for the delay. I've been running into a few issues which started 
after I added your 'hack'.


The system kept freezing after a few days uptime.

I thought it could be the kernel which I updated so I switched OS's to 
NetBSD, thought it would be a good idea to test/learn that too since I 
don't have that yet in my arsenal.


Unfortunately the system is still locking up with the new OS too.

I'm not sure what the issue could be however, I did notice on NetBSD 
that the HD light is lit consistently, also graphing by SNMP I saw a 
spike in the loopback network interface before the system went bang.


I do have some more HD's to re-jump Debian into the box so it's not an 
issue to test stuff with and upload bugs etc... but I think this is my 
immediate problem as I'm not sure why the system is locking without any 
warning. The Serial console also locks too meaning I have no access and 
need to press the power button to shut the system off?



Regards,

Kaya


p.s. will try out the things you suggested soon, once I figure out 
what's going on with the hangups.


On 11/23/2012 12:41 PM, Richard Mortimer wrote:

Hi,

(Cc'ing debian-sparc back in so that others who follow have a full 
email trail)


Sorry for not responding sooner. I saw you message yesterday and its 
good news that the hack allows the driver to attach.


On 22/11/2012 21:01, Kaya Saman wrote:

Hi Richard,

I just wanted to say thanks as everything is working fine now!!! :-)


As you said earlier eth1 was bound to NIC2 on the system board and hence
my confusion; since NIC1 was connected it meant that I needed to add 
eth2.

Glad that was the issue there.

If you are feeling brave you can probably re-order things manually by 
editing /etc/udev/rules.d/70-persistent-net.rules
There will be one entry per interface and you will see the MAC address 
and interface name on one line.
Just switch move the interface names around so that the lowest MAC 
address (ending 1e:7e in your case) is on eth0, the next ending 1e:7f 
for eth1, 1e:80 eth2 and 1e:81 eth3. When you reboot the interfaces 
should then be in the correct order. Don't forget you will need to 
fixup /etc/network/interfaces after that to match too.


Those changes should be pretty safe to experiment with so long as you 
have access to the machine console to fix things up if things go wrong.





I just wanted to ask 2 very simple things in the meantime:

how do I get from Debian to OpenBoot? Normally I power-off then take out
the HD and power back on again. It's a little inefficient... but since
sending the "break" signal from a Serial Term doens't work like on
Solaris I was wondering how to do this from the booted OS.


That's a pain taking the HD out. Here are a few ways that you can do 
what you want.


1 - at the end of the powerup/reset sequence you can send a break when 
OBP prints the banner starting "Sun Fire V210 (UltraSPARC ...". That 
will get you to the ok prompt if you get that sent before boot gets 
too far.


2 - You can enable break dropping to OBP from Linux.
echo "1" > /proc/sys/kernel/stop-a
change 1 to 0 to disable again.





In addition, you mentioned a way to make the settings semi-permenant.
That's all fine however, how would I revert them back to defualts if I
needed to? - say once the kernel bug has been fixed?


Actually I think I forgot a bit. You also need to do

setenv use-nvramrc? true

to turn on the nvram stuff.

To disable on a temporary basis do

setenv use-nvramrc? false

To disable/delete permanently

setenv use-nvramrc? false
set-default nvramrc

Those changes in settings take place after the next reset (i.e. 
reset-all from OBP)


Finally did you get chance to log a bug in the Debian bug tracking 
system yet? It would be really useful to have that to refer to when I 
get time to ask a few questions upstream.


Regards

Richard



Regards,


Kaya




--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50b65b2d.3060...@gmail.com

Re: Sun Fire V210 NIC's now working

[Richard Mortimer]

Hi,

(Cc'ing debian-sparc back in so that others who follow have a full email 
trail)


Sorry for not responding sooner. I saw you message yesterday and its 
good news that the hack allows the driver to attach.


On 22/11/2012 21:01, Kaya Saman wrote:

Hi Richard,

I just wanted to say thanks as everything is working fine now!!! :-)


As you said earlier eth1 was bound to NIC2 on the system board and hence
my confusion; since NIC1 was connected it meant that I needed to add eth2.

Glad that was the issue there.

If you are feeling brave you can probably re-order things manually by 
editing /etc/udev/rules.d/70-persistent-net.rules
There will be one entry per interface and you will see the MAC address 
and interface name on one line.
Just switch move the interface names around so that the lowest MAC 
address (ending 1e:7e in your case) is on eth0, the next ending 1e:7f 
for eth1, 1e:80 eth2 and 1e:81 eth3. When you reboot the interfaces 
should then be in the correct order. Don't forget you will need to fixup 
/etc/network/interfaces after that to match too.


Those changes should be pretty safe to experiment with so long as you 
have access to the machine console to fix things up if things go wrong.





I just wanted to ask 2 very simple things in the meantime:

how do I get from Debian to OpenBoot? Normally I power-off then take out
the HD and power back on again. It's a little inefficient... but since
sending the "break" signal from a Serial Term doens't work like on
Solaris I was wondering how to do this from the booted OS.


That's a pain taking the HD out. Here are a few ways that you can do 
what you want.


1 - at the end of the powerup/reset sequence you can send a break when 
OBP prints the banner starting "Sun Fire V210 (UltraSPARC ...". That 
will get you to the ok prompt if you get that sent before boot gets too far.


2 - You can enable break dropping to OBP from Linux.
echo "1" > /proc/sys/kernel/stop-a
change 1 to 0 to disable again.





In addition, you mentioned a way to make the settings semi-permenant.
That's all fine however, how would I revert them back to defualts if I
needed to? - say once the kernel bug has been fixed?


Actually I think I forgot a bit. You also need to do

setenv use-nvramrc? true

to turn on the nvram stuff.

To disable on a temporary basis do

setenv use-nvramrc? false

To disable/delete permanently

setenv use-nvramrc? false
set-default nvramrc

Those changes in settings take place after the next reset (i.e. 
reset-all from OBP)


Finally did you get chance to log a bug in the Debian bug tracking 
system yet? It would be really useful to have that to refer to when I 
get time to ask a few questions upstream.


Regards

Richard



Regards,


Kaya




--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50af6efb.3030...@oldelvet.org.uk

Re: Sun Fire V210 NIC's don't work

[Kaya Saman]

On 11/21/2012 09:46 AM, Richard Mortimer wrote:

Hi,

On 20/11/2012 19:47, Kaya Saman wrote:

On 11/20/2012 06:54 PM, Richard Mortimer wrote:

On 19/11/2012 22:36, Kaya Saman wrote:

I suspect that this can be worked around quite quickly. From a quick
look at the tg3 driver source code I don't think that the BAR 2
registers are actually used on the model present in that version.

As a quick and dirty hack it might just be as simple as removing the
BAR 2 entry from the assigned-addresses property. My
Openboot/forth-foo is a little rusty but I'll see if I can find some
time to work out a quick hack to try that.

If that works then I'd suspect that the correct way to handle this is
to workaround the issue would be somewhere in the sparc platform setup
code in the kernel.



Try this...

The following needs typing from the "ok" prompt prior to typing boot. 
It will not persist after a reboot (would needed adding into the 
nvramrc for that).


For testing I would suggest setting auto-boot? to false and resetting 
the box. At the ok prompt do


setenv auto-boot? false
reset-all

Once OBP has reset then the following should get rid of the 
assigned-addresses on the net1 and net3 nodes in OBP.


hex
cd net1
83001110 encode-int
0 encode-int encode+
40 encode-int encode+
0 encode-int encode+
20 encode-int encode+
" assigned-addresses" property
device-end
cd net3
83001110 encode-int
0 encode-int encode+
40 encode-int encode+
0 encode-int encode+
20 encode-int encode+
" assigned-addresses" property
device-end

Once that is done you can boot using

boot

But be careful. If OBP resets the box when you type boot then you need 
to try again.


Once the box is booted then an  "/sbin/ifconfig -a" should show you 
all 4 interfaces if the hack works.


Once tested you can make the hack semi-permanent by adding it to the 
nvramrc in OBP.


nvedit
... prompt turns to something like  "   0:"
... commands from above one per line ...
... control-c after the last line to get back to the "ok" prompt
nvstore
reset-all

Fingers crossed.

Best Regards

Richard


Tada

# ifconfig -a
eth0  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:7e
  inet addr:192.168.1.116  Bcast:192.168.1.255 Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:1155 errors:0 dropped:0 overruns:0 frame:0
  TX packets:673 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:82099 (80.1 KiB)  TX bytes:48963 (47.8 KiB)
  Interrupt:6

eth1  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:80
  UP BROADCAST MULTICAST  MTU:1500  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:1000
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
  Interrupt:31

eth2  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:7f
  BROADCAST MULTICAST  MTU:1500  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:1000
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
  Interrupt:7

eth3  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:81
  BROADCAST MULTICAST  MTU:1500  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:1000
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
  Interrupt:32

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:108 errors:0 dropped:0 overruns:0 frame:0
  TX packets:108 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:9426 (9.2 KiB)  TX bytes:9426 (9.2 KiB)



Unfortunately though with eth1 set to dhcp the "link" is still being 
shown as not ready?


As pointed out previously, with my laptop using the same port on the 
switch and cable an IP address is received from my DHCP server.



I will however try the other ports and see if they work in addition.


Regards,


Kaya


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50ad284d.6090...@gmail.com

Re: Sun Fire V210 NIC's don't work

[Richard Mortimer]

Hi,

On 20/11/2012 19:47, Kaya Saman wrote:

On 11/20/2012 06:54 PM, Richard Mortimer wrote:

On 19/11/2012 22:36, Kaya Saman wrote:

I suspect that this can be worked around quite quickly. From a quick
look at the tg3 driver source code I don't think that the BAR 2
registers are actually used on the model present in that version.

As a quick and dirty hack it might just be as simple as removing the
BAR 2 entry from the assigned-addresses property. My
Openboot/forth-foo is a little rusty but I'll see if I can find some
time to work out a quick hack to try that.

If that works then I'd suspect that the correct way to handle this is
to workaround the issue would be somewhere in the sparc platform setup
code in the kernel.



Try this...

The following needs typing from the "ok" prompt prior to typing boot. It 
will not persist after a reboot (would needed adding into the nvramrc 
for that).


For testing I would suggest setting auto-boot? to false and resetting 
the box. At the ok prompt do


setenv auto-boot? false
reset-all

Once OBP has reset then the following should get rid of the 
assigned-addresses on the net1 and net3 nodes in OBP.


hex
cd net1
83001110 encode-int
0 encode-int encode+
40 encode-int encode+
0 encode-int encode+
20 encode-int encode+
" assigned-addresses" property
device-end
cd net3
83001110 encode-int
0 encode-int encode+
40 encode-int encode+
0 encode-int encode+
20 encode-int encode+
" assigned-addresses" property
device-end

Once that is done you can boot using

boot

But be careful. If OBP resets the box when you type boot then you need 
to try again.


Once the box is booted then an  "/sbin/ifconfig -a" should show you all 
4 interfaces if the hack works.


Once tested you can make the hack semi-permanent by adding it to the 
nvramrc in OBP.


nvedit
... prompt turns to something like  "   0:"
... commands from above one per line ...
... control-c after the last line to get back to the "ok" prompt
nvstore
reset-all

Fingers crossed.

Best Regards

Richard


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50aca2dc.5040...@oldelvet.org.uk

Re: Sun Fire V210 NIC's don't work

[Kaya Saman]

On 11/20/2012 06:54 PM, Richard Mortimer wrote:



On 19/11/2012 22:36, Kaya Saman wrote:

So Richard, what's your opinion on when this might get fixed or a
workaround found?

Crystal ball time :-)


I like crystal balls!! Do you read palms too?? :-)



I suspect that this can be worked around quite quickly. From a quick 
look at the tg3 driver source code I don't think that the BAR 2 
registers are actually used on the model present in that version.


As a quick and dirty hack it might just be as simple as removing the 
BAR 2 entry from the assigned-addresses property. My 
Openboot/forth-foo is a little rusty but I'll see if I can find some 
time to work out a quick hack to try that.


If that works then I'd suspect that the correct way to handle this is 
to workaround the issue would be somewhere in the sparc platform setup 
code in the kernel.




Thanks, if you have time! I don't mind waiting a bit for a fix, as long 
as it'll save me the work of having to rebuild everything while my 
systems already setup.




Basically I'm a bit in limbo now as the machine is built to the spec I
need bar the NICs.

Should I switch OS for now or do you think I should persist in debugging
until a solution is reached?
I rather suspect that the only way this will get fixed is if someone 
with the "broken" setup is willing to test.


I'm around :-)



If we can try a couple of the simple/hacky tests just to confirm my 
hypothesis that would be good. I'll try to find time to do that later 
tonight.


Thanks again I really appreciate this!



Regards

Richard





Regards,


Kaya


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50abde3e.2090...@gmail.com

Re: Sun Fire V210 NIC's don't work

[Kaya Saman]

On 11/20/2012 11:22 AM, Anonymous wrote:

You wrote:


License aside,

Solaris whether it be 10 or 11 doesn't have many applications available
for it that Linux or FreeBSD contain.

Solaris has virtually everything available, it's UNIX. You can get virtually
anything to build unless it's specifically written to require Linux. If you
can't build it yourself there are 3rd party package repos and sites and
there are mailing lists for Solaris help too.


Ok I understand your point and Sun Freeware and OpenCSW et el are 
really good projects however, since I'm trying to use the server for VDI 
I need things like the Gnome3 and KDE4 user environments not to mention 
end user based apps. It's easier to apt-get then build things from 
source all the time!


This box is used in conjunction with Solaris 10 running SRSS and SGD.




So if Firefox and Thunderbird are enough that's great but anything else
forget about.

How many packages do you need? Do you need all 22,000 in FreeBSD ports (btw
only a fraction of those will build on any given platform aside from i386)
or can you live with the 6,000 packages from OpenBSD?

You do realize you're being a bit silly. I have 12 Debian Linux (Opteron)
servers in production and 15 Suns running Solaris. We haven't noticed a
problem with lack of software for our enterprise. Not sure why you think you
can't use an Enterprise OS on the hardware it was designed to run
on. Watching you try to get a Swedish engine control system to run your
Italian Ferrari is a bit painful. Just trying to help. There is no better OS
for Sun SPARC boxes than Solaris. Nothing comes close.


Desktop based packages as stated above which Solaris is really weak for 
not to mention different Desktop environments.





For application based servers which as the OP I am using my box as, my
choices for SPARC platform are either Debian or FreeBSD.

Why not Net or OpenBSD?


OpenBSD is awsome but lacks the desktop apps I need. I've never used 
NetBSD however the Force10 OS is built round it so that's a good thing :-)





I think soon I'm going to re-jumpstart the machine with FreeBSD 9 -
though it means extra work however, at least the NICs will be usable.

Yep, better choice than Linux on SPARC. I love Debian on my AMD boxes but
Linux is not a good choice on SPARC.




Am gona wait for this and see if I can actually help sort out the NIC 
issue rather then just complaining about things not working.



Regards,


Kaya


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50abddaa.1030...@gmail.com

Re: Sun Fire V210 NIC's don't work

[Richard Mortimer]

On 19/11/2012 22:36, Kaya Saman wrote:

So Richard, what's your opinion on when this might get fixed or a
workaround found?

Crystal ball time :-)

I suspect that this can be worked around quite quickly. From a quick 
look at the tg3 driver source code I don't think that the BAR 2 
registers are actually used on the model present in that version.


As a quick and dirty hack it might just be as simple as removing the BAR 
2 entry from the assigned-addresses property. My Openboot/forth-foo is a 
little rusty but I'll see if I can find some time to work out a quick 
hack to try that.


If that works then I'd suspect that the correct way to handle this is to 
workaround the issue would be somewhere in the sparc platform setup code 
in the kernel.




Basically I'm a bit in limbo now as the machine is built to the spec I
need bar the NICs.

Should I switch OS for now or do you think I should persist in debugging
until a solution is reached?
I rather suspect that the only way this will get fixed is if someone 
with the "broken" setup is willing to test.


If we can try a couple of the simple/hacky tests just to confirm my 
hypothesis that would be good. I'll try to find time to do that later 
tonight.


Regards

Richard



Of course I would love to help out anyway that I could as I started with
Debian all the way back from Sarge and Etch days but on the other hand I
need a usable system too. !humph!

Regards,

Kaya

On 11/19/2012 10:29 PM, Richard Mortimer wrote:



On 19/11/2012 17:34, Kaya Saman wrote:

On 11/19/2012 04:28 PM, Richard Mortimer wrote:
# dmesg | grep tg3
[   41.528377] tg3.c:v3.121 (November 2, 2011)
[   42.096605] tg3 :00:02.0: vpd r/w failed.  This is likely a
firmware bug on this device.  Contact the card vendor for a firmware
update.sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
[   42.249670] tg3 :00:02.0: vpd r/w failed.  This is likely a
firmware bug on this device.  Contact the card vendor for a firmware
update.
[   42.305863] tg3 :00:02.0: vpd r/w failed.  This is likely a
firmware bug on this device.  Contact the card vendor for a firmware
update.
[   42.308810] tg3 :00:02.0: eth0: Tigon3 [partno(none) rev 2100]
(PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:7e
[   42.446140] tg3 :00:02.0: eth0: attached PHY is 5704
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[   42.575463] tg3 :00:02.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0]
ASF[0] TSOcap[1]
[   42.679542] tg3 :00:02.0: eth0: dma_rwctrl[763f]
dma_mask[32-bit]
[   43.278806] tg3 :00:02.1: BAR 2: can't reserve [mem
0x7f7-0x7f7]
[   43.380653] tg3 :00:02.1: Cannot obtain PCI resources, aborting
[   43.741325] tg3: probe of :00:02.1 failed with error -16


A bit more information for the bug report...

Looking at the prtconf output for your machine I suspect that the
problem is that the OBP assigned-addresses properties corresponding to
BAR (base address register) 2 are pointing to the same address. That
means that the 2nd device on that PCI bus fails to attach because the
PCI framework is saying that the address is already in use.



Node 0xf00697a0
.node:  f00697a0
available:  8100..0300..fd00.
8200..0010..0010.
8200..0060..bfa0.
8200..e000..2000
reg:  0400.0ff0..b000.
  0400.0fc1..7020.
  07f6...0100.
  0400.0ff8..0001
ranges:
...07f6...0100.
0100...07f6.0100..0100.
0200...07f7..0001..
0300...07f7..0001.
bus-range:  .
#address-cells:  0003
#size-cells:  0002

Node 0xf00bea74
.node:  f00bea74
local-mac-address:  00144f5d.1e7e
assigned-addresses:
   83001010..0020..0020.
   83001018....0001
   
** BAR 2 here. Start Address = 0x0, length 0x1 **

reg:
   1000.....
   03001010....0020.
   03001018....0001

Node 0xf00c58d8
.node:  f00c58d8
local-mac-address:  00144f5d.1e7f
assigned-addresses:
   83001110..0040..0020.
   83001118....0001
   
** BAR 2 here. Start Address = 0x0, length 0x1 **
reg:
   1100.00

Re: Sun Fire V210 NIC's don't work

[Anonymous]

You wrote:

> License aside,
> 
> Solaris whether it be 10 or 11 doesn't have many applications available 
> for it that Linux or FreeBSD contain.

Solaris has virtually everything available, it's UNIX. You can get virtually
anything to build unless it's specifically written to require Linux. If you
can't build it yourself there are 3rd party package repos and sites and
there are mailing lists for Solaris help too.

> So if Firefox and Thunderbird are enough that's great but anything else
> forget about.

How many packages do you need? Do you need all 22,000 in FreeBSD ports (btw
only a fraction of those will build on any given platform aside from i386)
or can you live with the 6,000 packages from OpenBSD?

You do realize you're being a bit silly. I have 12 Debian Linux (Opteron)
servers in production and 15 Suns running Solaris. We haven't noticed a
problem with lack of software for our enterprise. Not sure why you think you
can't use an Enterprise OS on the hardware it was designed to run
on. Watching you try to get a Swedish engine control system to run your
Italian Ferrari is a bit painful. Just trying to help. There is no better OS
for Sun SPARC boxes than Solaris. Nothing comes close.

> For application based servers which as the OP I am using my box as, my 
> choices for SPARC platform are either Debian or FreeBSD.

Why not Net or OpenBSD?

> I think soon I'm going to re-jumpstart the machine with FreeBSD 9 - 
> though it means extra work however, at least the NICs will be usable.

Yep, better choice than Linux on SPARC. I love Debian on my AMD boxes but
Linux is not a good choice on SPARC. 


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/22609145686a36eb2385730024cec...@remailer.paranoici.org

Re: Sun Fire V210 NIC's don't work

[Kaya Saman]

So Richard, what's your opinion on when this might get fixed or a 
workaround found?


Basically I'm a bit in limbo now as the machine is built to the spec I 
need bar the NICs.


Should I switch OS for now or do you think I should persist in debugging 
until a solution is reached?


Of course I would love to help out anyway that I could as I started with 
Debian all the way back from Sarge and Etch days but on the other hand I 
need a usable system too. !humph!


Regards,

Kaya

On 11/19/2012 10:29 PM, Richard Mortimer wrote:



On 19/11/2012 17:34, Kaya Saman wrote:

On 11/19/2012 04:28 PM, Richard Mortimer wrote:
# dmesg | grep tg3
[   41.528377] tg3.c:v3.121 (November 2, 2011)
[   42.096605] tg3 :00:02.0: vpd r/w failed.  This is likely a
firmware bug on this device.  Contact the card vendor for a firmware
update.sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
[   42.249670] tg3 :00:02.0: vpd r/w failed.  This is likely a
firmware bug on this device.  Contact the card vendor for a firmware
update.
[   42.305863] tg3 :00:02.0: vpd r/w failed.  This is likely a
firmware bug on this device.  Contact the card vendor for a firmware
update.
[   42.308810] tg3 :00:02.0: eth0: Tigon3 [partno(none) rev 2100]
(PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:7e
[   42.446140] tg3 :00:02.0: eth0: attached PHY is 5704
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[   42.575463] tg3 :00:02.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0]
ASF[0] TSOcap[1]
[   42.679542] tg3 :00:02.0: eth0: dma_rwctrl[763f]
dma_mask[32-bit]
[   43.278806] tg3 :00:02.1: BAR 2: can't reserve [mem
0x7f7-0x7f7]
[   43.380653] tg3 :00:02.1: Cannot obtain PCI resources, aborting
[   43.741325] tg3: probe of :00:02.1 failed with error -16


A bit more information for the bug report...

Looking at the prtconf output for your machine I suspect that the 
problem is that the OBP assigned-addresses properties corresponding to 
BAR (base address register) 2 are pointing to the same address. That 
means that the 2nd device on that PCI bus fails to attach because the 
PCI framework is saying that the address is already in use.




Node 0xf00697a0
.node:  f00697a0
available:  8100..0300..fd00.
8200..0010..0010.
8200..0060..bfa0.
8200..e000..2000
reg:  0400.0ff0..b000.
  0400.0fc1..7020.
  07f6...0100.
  0400.0ff8..0001
ranges:
...07f6...0100.
0100...07f6.0100..0100.
0200...07f7..0001..
0300...07f7..0001.
bus-range:  .
#address-cells:  0003
#size-cells:  0002

Node 0xf00bea74
.node:  f00bea74
local-mac-address:  00144f5d.1e7e
assigned-addresses:
   83001010..0020..0020.
   83001018....0001
   
** BAR 2 here. Start Address = 0x0, length 0x1 **

reg:
   1000.....
   03001010....0020.
   03001018....0001

Node 0xf00c58d8
.node:  f00c58d8
local-mac-address:  00144f5d.1e7f
assigned-addresses:
   83001110..0040..0020.
   83001118....0001
   
** BAR 2 here. Start Address = 0x0, length 0x1 **
reg:
   1100.....
   03001110....0020.
   03001118....0001






[   44.072115] tg3 0003:00:02.0: vpd r/w failed.  This is likely a
firmware bug on this device.  Contact the card vendor for a firmware
update.
[   44.129861] tg3 0003:00:02.0: vpd r/w failed.  This is likely a
firmware bug on this device.  Contact the card vendor for a firmware
update.
[   44.559842] tg3 0003:00:02.0: vpd r/w failed.  This is likely a
firmware bug on this device.  Contact the card vendor for a firmware
update.
[   44.562363] tg3 0003:00:02.0: eth1: Tigon3 [partno(none) rev 2100]
(PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:80
[   44.699696] tg3 0003:00:02.0: eth1: attached PHY is 5704
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[   44.829020] tg3 0003:00:02.0: eth1: RXcsums[1] LinkChgREG[0] MIirq[0]
ASF[0] TSOcap[1]
[   44.933095] tg3 0003:00:02.0:

Re: Sun Fire V210 NIC's don't work

[Richard Mortimer]

On 19/11/2012 17:34, Kaya Saman wrote:

On 11/19/2012 04:28 PM, Richard Mortimer wrote:
# dmesg | grep tg3
[   41.528377] tg3.c:v3.121 (November 2, 2011)
[   42.096605] tg3 :00:02.0: vpd r/w failed.  This is likely a
firmware bug on this device.  Contact the card vendor for a firmware
update.sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
[   42.249670] tg3 :00:02.0: vpd r/w failed.  This is likely a
firmware bug on this device.  Contact the card vendor for a firmware
update.
[   42.305863] tg3 :00:02.0: vpd r/w failed.  This is likely a
firmware bug on this device.  Contact the card vendor for a firmware
update.
[   42.308810] tg3 :00:02.0: eth0: Tigon3 [partno(none) rev 2100]
(PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:7e
[   42.446140] tg3 :00:02.0: eth0: attached PHY is 5704
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[   42.575463] tg3 :00:02.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0]
ASF[0] TSOcap[1]
[   42.679542] tg3 :00:02.0: eth0: dma_rwctrl[763f]
dma_mask[32-bit]
[   43.278806] tg3 :00:02.1: BAR 2: can't reserve [mem
0x7f7-0x7f7]
[   43.380653] tg3 :00:02.1: Cannot obtain PCI resources, aborting
[   43.741325] tg3: probe of :00:02.1 failed with error -16


A bit more information for the bug report...

Looking at the prtconf output for your machine I suspect that the 
problem is that the OBP assigned-addresses properties corresponding to 
BAR (base address register) 2 are pointing to the same address. That 
means that the 2nd device on that PCI bus fails to attach because the 
PCI framework is saying that the address is already in use.




Node 0xf00697a0
.node:  f00697a0
available:  8100..0300..fd00.
8200..0010..0010.
8200..0060..bfa0.
8200..e000..2000
reg:  0400.0ff0..b000.
  0400.0fc1..7020.
  07f6...0100.
  0400.0ff8..0001
ranges:
 ...07f6...0100.
 0100...07f6.0100..0100.
 0200...07f7..0001..
 0300...07f7..0001.
bus-range:  .
#address-cells:  0003
#size-cells:  0002

Node 0xf00bea74
.node:  f00bea74
local-mac-address:  00144f5d.1e7e
assigned-addresses:
   83001010..0020..0020.
   83001018....0001
   
** BAR 2 here. Start Address = 0x0, length 0x1 **

reg:
   1000.....
   03001010....0020.
   03001018....0001

Node 0xf00c58d8
.node:  f00c58d8
local-mac-address:  00144f5d.1e7f
assigned-addresses:
   83001110..0040..0020.
   83001118....0001
   
** BAR 2 here. Start Address = 0x0, length 0x1 **
reg:
   1100.....
   03001110....0020.
   03001118....0001






[   44.072115] tg3 0003:00:02.0: vpd r/w failed.  This is likely a
firmware bug on this device.  Contact the card vendor for a firmware
update.
[   44.129861] tg3 0003:00:02.0: vpd r/w failed.  This is likely a
firmware bug on this device.  Contact the card vendor for a firmware
update.
[   44.559842] tg3 0003:00:02.0: vpd r/w failed.  This is likely a
firmware bug on this device.  Contact the card vendor for a firmware
update.
[   44.562363] tg3 0003:00:02.0: eth1: Tigon3 [partno(none) rev 2100]
(PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:80
[   44.699696] tg3 0003:00:02.0: eth1: attached PHY is 5704
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[   44.829020] tg3 0003:00:02.0: eth1: RXcsums[1] LinkChgREG[0] MIirq[0]
ASF[0] TSOcap[1]
[   44.933095] tg3 0003:00:02.0: eth1: dma_rwctrl[763f]
dma_mask[32-bit]
[   45.125173] tg3 0003:00:02.1: BAR 2: can't reserve [mem
0x7c7-0x7c7]
[   45.227044] tg3 0003:00:02.1: Cannot obtain PCI resources, aborting
[   45.317544] tg3: probe of 0003:00:02.1 failed with error -16
[   57.680406] tg3 :00:02.0: eth0: No firmware running
[   59.335720] tg3 :00:02.0: eth0: Link is up at 100 Mbps, full duplex
[   59.422695] tg3 :00:02.0: eth0: Flow control is off for TX and
off for RX



--
To U

Re: Sun Fire V210 NIC's don't work

[Martin]

On Mon, 2012-11-19 at 20:04 +, Anonymous wrote:
> SOLARIS 10 SPARC!!!
> 
> You KNOW you want it! ;-)
> 
> No Linux, no FSF, no problem!

I'm going to assume this is meant as a helpful suggestion rather than a
troll*.  But, this is the Debian SPARC mailing list, about running
Debian (mostly GNU+Linux based) on SPARC hardware, so saying Solaris,
although it may be the fast route to getting a working system, isn't
really that helpful and doesn't solve the problem actually being
discussed.

Cheers,
 - Martin

*. Anyway, the first thing anyone does with a Solaris box is install the
FSF/GNU userland and a bunch of developed-for-Linux applications, I
mean, that's how you make it useful, right? 



-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1353356668.19277.552.ca...@white.sevalidation.com

Re: Sun Fire V210 NIC's don't work

[Kaya Saman]

License aside,

Solaris whether it be 10 or 11 doesn't have many applications available 
for it that Linux or FreeBSD contain. So if Firefox and Thunderbird are 
enough that's great but anything else forget about. OpenSolaris was 
becoming much better but thanks to Oracle they killed that off and Open 
Indiana is no way complete yet.


For application based servers which as the OP I am using my box as, my 
choices for SPARC platform are either Debian or FreeBSD. CentOS or 
Fedora aren't available and nor is Ubuntu and with such a short term 
life I'm not content to go with Ubuntu either.



Thanks to Richard Mortimer and everyone else for the support in the 
meantime!


I think soon I'm going to re-jumpstart the machine with FreeBSD 9 - 
though it means extra work however, at least the NICs will be usable.




Regards,


Kaya




On 11/19/2012 08:25 PM, Patrick Baggett wrote:

Right, no problems except for this:

http://www.oracle.com/technetwork/licenses/solaris-cluster-express-license-167852.html

That's right, the EULA. You probably haven't read it, but I have, and 
in particular, this clause is more problematic than the GPL, FSF, or 
BSD license ever will be:


"Except for any included software package or file that is licensed to 
you by Oracle under different license terms, we grant you a perpetual 
(unless terminated as provided in this agreement), nonexclusive, 
nontransferable, limited License to use the Programs *only for the 
purpose of developing, testing, prototyping and demonstrating your 
applications, and not for any other purpose.*"


So in other words, useless for hosting your home website, useless for 
running any kind of in-house service, and prohibited from doing any 
real work. Please, continue about how Solaris 10 empowers this machine 
to be useful.


Patrick

On Mon, Nov 19, 2012 at 2:04 PM, Anonymous > wrote:


SOLARIS 10 SPARC!!!

You KNOW you want it! ;-)

No Linux, no FSF, no problem!


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org

with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org 
Archive:
http://lists.debian.org/7987e47f0532f145633ef5d380e0c...@mail.hoi-polloi.org

Re: Sun Fire V210 NIC's don't work

[Patrick Baggett]

Right, no problems except for this:

http://www.oracle.com/technetwork/licenses/solaris-cluster-express-license-167852.html

That's right, the EULA. You probably haven't read it, but I have, and in
particular, this clause is more problematic than the GPL, FSF, or BSD
license ever will be:

"Except for any included software package or file that is licensed to you
by Oracle under different license terms, we grant you a perpetual (unless
terminated as provided in this agreement), nonexclusive, nontransferable,
limited License to use the Programs *only for the purpose of developing,
testing, prototyping and demonstrating your applications, and not for any
other purpose.*"

So in other words, useless for hosting your home website, useless for
running any kind of in-house service, and prohibited from doing any real
work. Please, continue about how Solaris 10 empowers this machine to be
useful.

Patrick

On Mon, Nov 19, 2012 at 2:04 PM, Anonymous  wrote:

> SOLARIS 10 SPARC!!!
>
> You KNOW you want it! ;-)
>
> No Linux, no FSF, no problem!
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> http://lists.debian.org/7987e47f0532f145633ef5d380e0c...@mail.hoi-polloi.org
>
>

Re: Sun Fire V210 NIC's don't work

[Anonymous]

SOLARIS 10 SPARC!!!

You KNOW you want it! ;-)

No Linux, no FSF, no problem!


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/7987e47f0532f145633ef5d380e0c...@mail.hoi-polloi.org

Re: Sun Fire V210 NIC's don't work

[Kaya Saman]

On 11/19/2012 04:28 PM, Richard Mortimer wrote:



On 19/11/2012 15:46, Kaya Saman wrote:

On 11/19/2012 03:36 PM, Richard Mortimer wrote:



So as I suspected eth0 and eth1 are the ports labelled net0 and net2

Did you try connecting the cable to those ports and testing. From what
I've see and what others have said I suspect that will just work.


I've connected cables to eth0 and eth1 or NICs 0 and 1. In addition I
tried NIC 2 but because Debian doesn't show the card itself I wasn't
able to get any connectivity.
I think you may be getting confused here.  eth0 and eth1 are just 
arbitrary names that are assigned to the devices and they do not 
correspond to the names printed on the V210 chassis.


In your case  eth0 looks to be  NET0 and  eth1 is  NET2.


Well, I thought with the Backport I would have more luck but 
unfortunately even kernel 3.2 is causing issues:


# dmesg | grep tg3
[   41.528377] tg3.c:v3.121 (November 2, 2011)
[   42.096605] tg3 :00:02.0: vpd r/w failed.  This is likely a 
firmware bug on this device.  Contact the card vendor for a firmware 
update.sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
[   42.249670] tg3 :00:02.0: vpd r/w failed.  This is likely a 
firmware bug on this device.  Contact the card vendor for a firmware update.
[   42.305863] tg3 :00:02.0: vpd r/w failed.  This is likely a 
firmware bug on this device.  Contact the card vendor for a firmware update.
[   42.308810] tg3 :00:02.0: eth0: Tigon3 [partno(none) rev 2100] 
(PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:7e
[   42.446140] tg3 :00:02.0: eth0: attached PHY is 5704 
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[   42.575463] tg3 :00:02.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] 
ASF[0] TSOcap[1]

[   42.679542] tg3 :00:02.0: eth0: dma_rwctrl[763f] dma_mask[32-bit]
[   43.278806] tg3 :00:02.1: BAR 2: can't reserve [mem 
0x7f7-0x7f7]

[   43.380653] tg3 :00:02.1: Cannot obtain PCI resources, aborting
[   43.741325] tg3: probe of :00:02.1 failed with error -16
[   44.072115] tg3 0003:00:02.0: vpd r/w failed.  This is likely a 
firmware bug on this device.  Contact the card vendor for a firmware update.
[   44.129861] tg3 0003:00:02.0: vpd r/w failed.  This is likely a 
firmware bug on this device.  Contact the card vendor for a firmware update.
[   44.559842] tg3 0003:00:02.0: vpd r/w failed.  This is likely a 
firmware bug on this device.  Contact the card vendor for a firmware update.
[   44.562363] tg3 0003:00:02.0: eth1: Tigon3 [partno(none) rev 2100] 
(PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:80
[   44.699696] tg3 0003:00:02.0: eth1: attached PHY is 5704 
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[   44.829020] tg3 0003:00:02.0: eth1: RXcsums[1] LinkChgREG[0] MIirq[0] 
ASF[0] TSOcap[1]

[   44.933095] tg3 0003:00:02.0: eth1: dma_rwctrl[763f] dma_mask[32-bit]
[   45.125173] tg3 0003:00:02.1: BAR 2: can't reserve [mem 
0x7c7-0x7c7]

[   45.227044] tg3 0003:00:02.1: Cannot obtain PCI resources, aborting
[   45.317544] tg3: probe of 0003:00:02.1 failed with error -16
[   57.680406] tg3 :00:02.0: eth0: No firmware running
[   59.335720] tg3 :00:02.0: eth0: Link is up at 100 Mbps, full duplex
[   59.422695] tg3 :00:02.0: eth0: Flow control is off for TX and 
off for RX


uname -a

3.2.0-0.bpo.4-sparc64-smp #1 SMP Debian 3.2.32-1~bpo60+1 sparc64 GNU/Linux






[...]


From what I have seen you are using squeeze with kernel 2.6.32. I 
believe that there is a backport of 3.2.x available so it might be 
worth trying that to see if it is already fixed there.


http://packages.debian.org/search?suite=all&arch=sparc&searchon=names&keywords=linux-image 



It wou
ld also be useful if you could report a bug into the Debian tracking 
system.




Doesn't look like it's fixed yet :-( Will post bug!


Regards

Richard









Regards,


Kaya


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50aa6dae.9040...@gmail.com

Re: Sun Fire V210 NIC's don't work

[Richard Mortimer]

On 19/11/2012 15:46, Kaya Saman wrote:

On 11/19/2012 03:36 PM, Richard Mortimer wrote:



So as I suspected eth0 and eth1 are the ports labelled net0 and net2

Did you try connecting the cable to those ports and testing. From what
I've see and what others have said I suspect that will just work.


I've connected cables to eth0 and eth1 or NICs 0 and 1. In addition I
tried NIC 2 but because Debian doesn't show the card itself I wasn't
able to get any connectivity.
I think you may be getting confused here.  eth0 and eth1 are just 
arbitrary names that are assigned to the devices and they do not 
correspond to the names printed on the V210 chassis.


In your case  eth0 looks to be  NET0 and  eth1 is  NET2.






... snip ...



Additionally it looks like the 2nd network device on each PCI bus is
not getting
attached properly.

Does

dmesg | grep tg3


[   39.625716] tg3.c:v3.116 (December 3, 2010)
[   40.264438] tg3 :00:02.0: eth0: Tigon3 [partno(none) rev 2100]
(PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:7e
[   40.401775] tg3 :00:02.0: eth0: attached PHY is 5704
(10/100/1000Base-T Ethernet) (WireSpeed[1])
[   40.521950] tg3 :00:02.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0]
ASF[0] TSOcap[1]
[   40.626026] tg3 :00:02.0: eth0: dma_rwctrl[763f]
dma_mask[32-bit]




[   41.439201] tg3 :00:02.1: BAR 2: can't reserve mem region
[0x7f7-0x7f7]
[   41.549032] tg3 :00:02.1: Cannot obtain PCI resources, aborting
[   41.734027] tg3: probe of :00:02.1 failed with error -16


This explains why the other two ports are not showing up.

A quick search shows up.
http://www.spinics.net/lists/netdev/msg200255.html

Not sure if that has been addressed in later kernel versions yet.


Hmm if this is the case at present as I predicted I am thinking of
switching to FreeBSD for the time being to gain usage out of the other
NICs. Both Solaris 10 and OpenBSD 5.1 work perfectly so as a temporary
measure I could try that.


From what I have seen you are using squeeze with kernel 2.6.32. I 
believe that there is a backport of 3.2.x available so it might be worth 
trying that to see if it is already fixed there.


http://packages.debian.org/search?suite=all&arch=sparc&searchon=names&keywords=linux-image

It would also be useful if you could report a bug into the Debian 
tracking system.


Regards

Richard



I know it's not something to be mentioning on a Debian mailing list
however, if I have no other choice at present it is unfortunate :-(




--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50aa5e26.6020...@oldelvet.org.uk

Re: Sun Fire V210 NIC's don't work

[Kaya Saman]

On 11/19/2012 03:36 PM, Richard Mortimer wrote:

[...]




ok watch-net-all
/pci@1d,70/network@2,1
Timed out waiting for Autonegotiation to complete
Check cable and try again
Link Down

/pci@1d,70/network@2
100 Mbps full duplex  Link up
Looking for Ethernet Packets.
'.' is a Good Packet.  'X' is a Bad Packet.
Type any key to stop.
..
/pci@1f,70/network@2,1
Timed out waiting for Autonegotiation to complete
Check cable and try again
Link Down

/pci@1f,70/network@2
100 Mbps full duplex  Link up
Looking for Ethernet Packets.
'.' is a Good Packet.  'X' is a Bad Packet.
Type any key to stop.
 






So as I suspected eth0 and eth1 are the ports labelled net0 and net2

Did you try connecting the cable to those ports and testing. From what 
I've see and what others have said I suspect that will just work.


I've connected cables to eth0 and eth1 or NICs 0 and 1. In addition I 
tried NIC 2 but because Debian doesn't show the card itself I wasn't 
able to get any connectivity.





... snip ...



Additionally it looks like the 2nd network device on each PCI bus is
not getting
attached properly.

Does

dmesg | grep tg3


[   39.625716] tg3.c:v3.116 (December 3, 2010)
[   40.264438] tg3 :00:02.0: eth0: Tigon3 [partno(none) rev 2100]
(PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:7e
[   40.401775] tg3 :00:02.0: eth0: attached PHY is 5704
(10/100/1000Base-T Ethernet) (WireSpeed[1])
[   40.521950] tg3 :00:02.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0]
ASF[0] TSOcap[1]
[   40.626026] tg3 :00:02.0: eth0: dma_rwctrl[763f]
dma_mask[32-bit]




[   41.439201] tg3 :00:02.1: BAR 2: can't reserve mem region
[0x7f7-0x7f7]
[   41.549032] tg3 :00:02.1: Cannot obtain PCI resources, aborting
[   41.734027] tg3: probe of :00:02.1 failed with error -16


This explains why the other two ports are not showing up.

A quick search shows up.
http://www.spinics.net/lists/netdev/msg200255.html

Not sure if that has been addressed in later kernel versions yet.


Hmm if this is the case at present as I predicted I am thinking of 
switching to FreeBSD for the time being to gain usage out of the other 
NICs. Both Solaris 10 and OpenBSD 5.1 work perfectly so as a temporary 
measure I could try that.


I know it's not something to be mentioning on a Debian mailing list 
however, if I have no other choice at present it is unfortunate :-(




[...]


Regards,


Kaya


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50aa546b.6060...@gmail.com

Re: Sun Fire V210 NIC's don't work

[Richard Mortimer]

Hi,

On 19/11/2012 14:45, Kaya Saman wrote:

Hi Richard,

sorry for the delay in response. Please see in line output below:

On 11/15/2012 12:19 PM, Richard Mortimer wrote:



On 15/11/2012 08:35, Michael Leicht wrote:

How about looking into OBP Config? Something like "test net" ?

I was going to suggest trying using "watch-net-all". It relies on
there being traffic on the connected networks but can be useful. See
http://people.ee.ethz.ch/~ballisti/computer_topics/docs/U10svc/HTML/files/c0406.htm



ok watch-net-all
/pci@1d,70/network@2,1
Timed out waiting for Autonegotiation to complete
Check cable and try again
Link Down

/pci@1d,70/network@2
100 Mbps full duplex  Link up
Looking for Ethernet Packets.
'.' is a Good Packet.  'X' is a Bad Packet.
Type any key to stop.
..
/pci@1f,70/network@2,1
Timed out waiting for Autonegotiation to complete
Check cable and try again
Link Down

/pci@1f,70/network@2
100 Mbps full duplex  Link up
Looking for Ethernet Packets.
'.' is a Good Packet.  'X' is a Bad Packet.
Type any key to stop.




So as I suspected eth0 and eth1 are the ports labelled net0 and net2

Did you try connecting the cable to those ports and testing. From what 
I've see and what others have said I suspect that will just work.



... snip ...



Additionally it looks like the 2nd network device on each PCI bus is
not getting
attached properly.

Does

dmesg | grep tg3


[   39.625716] tg3.c:v3.116 (December 3, 2010)
[   40.264438] tg3 :00:02.0: eth0: Tigon3 [partno(none) rev 2100]
(PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:7e
[   40.401775] tg3 :00:02.0: eth0: attached PHY is 5704
(10/100/1000Base-T Ethernet) (WireSpeed[1])
[   40.521950] tg3 :00:02.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0]
ASF[0] TSOcap[1]
[   40.626026] tg3 :00:02.0: eth0: dma_rwctrl[763f]
dma_mask[32-bit]




[   41.439201] tg3 :00:02.1: BAR 2: can't reserve mem region
[0x7f7-0x7f7]
[   41.549032] tg3 :00:02.1: Cannot obtain PCI resources, aborting
[   41.734027] tg3: probe of :00:02.1 failed with error -16


This explains why the other two ports are not showing up.

A quick search shows up.
http://www.spinics.net/lists/netdev/msg200255.html

Not sure if that has been addressed in later kernel versions yet.


[   42.014260] tg3 0003:00:02.0: eth1: Tigon3 [partno(none) rev 2100]
(PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:80
[   42.151574] tg3 0003:00:02.0: eth1: attached PHY is 5704
(10/100/1000Base-T Ethernet) (WireSpeed[1])
[   42.271747] tg3 0003:00:02.0: eth1: RXcsums[1] LinkChgREG[0] MIirq[0]
ASF[0] TSOcap[1]
[   42.375821] tg3 0003:00:02.0: eth1: dma_rwctrl[763f]
dma_mask[32-bit]
[   42.465517] tg3 0003:00:02.1: BAR 2: can't reserve mem region
[0x7c7-0x7c7]
[   42.575366] tg3 0003:00:02.1: Cannot obtain PCI resources, aborting
[   42.658141] tg3: probe of 0003:00:02.1 failed with error -16


Same error here



[   79.475629] tg3 :00:02.0: firmware: requesting tigon/tg3_tso.bin
[   80.864032] tg3 :00:02.0: eth0: No firmware running
[   82.524222] tg3 :00:02.0: eth0: Link is up at 100 Mbps, full duplex
[   82.611142] tg3 :00:02.0: eth0: Flow control is off for TX and
off for RX



or
dmesg | grep 0003:00:02


[   30.442338] pci 0003:00:02.0: PME# supported from D3hot
[   30.442354] pci 0003:00:02.0: PME# disabled
[   30.442432] pci 0003:00:02.1: PME# supported from D3hot
[   30.442445] pci 0003:00:02.1: PME# disabled
[   41.808816] PCI: Enabling device: (0003:00:02.0), cmd 2
[   42.014260] tg3 0003:00:02.0: eth1: Tigon3 [partno(none) rev 2100]
(PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:80
[   42.151574] tg3 0003:00:02.0: eth1: attached PHY is 5704
(10/100/1000Base-T Ethernet) (WireSpeed[1])
[   42.271747] tg3 0003:00:02.0: eth1: RXcsums[1] LinkChgREG[0] MIirq[0]
ASF[0] TSOcap[1]
[   42.375821] tg3 0003:00:02.0: eth1: dma_rwctrl[763f]
dma_mask[32-bit]
[   42.465505] PCI: Enabling device: (0003:00:02.1), cmd 2
[   42.465517] tg3 0003:00:02.1: BAR 2: can't reserve mem region
[0x7c7-0x7c7]
[   42.575366] tg3 0003:00:02.1: Cannot obtain PCI resources, aborting
[   42.658141] tg3: probe of 0003:00:02.1 failed with error -16



produce anything relating to the other ports?

Regards

Richard


loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:114 errors:0 dropped:0 overruns:0 frame:0
  TX packets:114 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:9542 (9.3 KiB)  TX bytes:9542 (9.3 KiB)



I have attached the prtconf file:


Regards,


Kaya






Regards,


Kaya



--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas..

Re: Sun Fire V210 NIC's don't work

[Kaya Saman]

Hi Richard,

sorry for the delay in response. Please see in line output below:

On 11/15/2012 12:19 PM, Richard Mortimer wrote:



On 15/11/2012 08:35, Michael Leicht wrote:

How about looking into OBP Config? Something like "test net" ?
I was going to suggest trying using "watch-net-all". It relies on 
there being traffic on the connected networks but can be useful. See
http://people.ee.ethz.ch/~ballisti/computer_topics/docs/U10svc/HTML/files/c0406.htm 



ok watch-net-all
/pci@1d,70/network@2,1
Timed out waiting for Autonegotiation to complete
Check cable and try again
Link Down

/pci@1d,70/network@2
100 Mbps full duplex  Link up
Looking for Ethernet Packets.
'.' is a Good Packet.  'X' is a Bad Packet.
Type any key to stop.
..
/pci@1f,70/network@2,1
Timed out waiting for Autonegotiation to complete
Check cable and try again
Link Down

/pci@1f,70/network@2
100 Mbps full duplex  Link up
Looking for Ethernet Packets.
'.' is a Good Packet.  'X' is a Bad Packet.
Type any key to stop.

ok



More comments below...


I once had a similar Problem with a "hardcoded IP" (?) in OBP. Have 
you tried resseting your OBP and NVRAM?
My Blade 1500 silver shoudl have the same NIC and works just great, 
the missing Firmware Messages appeared but never had any Problem with 
them so i just ignored them.. ;)


Am 14.11.2012 um 19:38 schrieb Kaya Saman :


On 11/14/2012 06:25 PM, Richard Mortimer wrote:

On 14/11/2012 17:58, Kaya Saman wrote:

On 11/14/2012 05:52 PM, Frans van Berckel wrote:

On Wed, 2012-11-14 at 17:14 +, Kaya Saman wrote:


...snip...


I can't ping anywhere from the eth1 interface :-(

In addition I tried eth2 as the server has 4 NICs... it doesn't 
even get

recognized by the system??


Can you provide a few more bits of information.

1 - output from "prtconf -pv"  That will give an OBP view of the 
system. I checked in DaveM's git tree and there isn't a sample from 
the v210 in there

https://git.kernel.org/?p=linux/kernel/git/davem/prtconfs.git;a=tree

It would be good to push a copy of that to DaveM if you are agreeable.

2 - output from "ifconfig -a"

3 - output from "lspci"

Regards

Richard


Hi Richard,

# lspci
:00:02.0 Ethernet controller: Broadcom Corporation NetXtreme 
BCM5704 Gigabit Ethernet
:00:02.1 Ethernet controller: Broadcom Corporation NetXtreme 
BCM5704 Gigabit Ethernet
0001:00:06.0 Non-VGA unclassified device: ALi Corporation M7101 
Power Management Controller [PMU]
0001:00:07.0 ISA bridge: ALi Corporation M1533/M1535/M1543 PCI to 
ISA Bridge [Aladdin IV/V/V+]
0001:00:0a.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 
03)

0001:00:0d.0 IDE interface: ALi Corporation M5229 IDE (rev c4)
0002:00:02.0 SCSI storage controller: LSI Logic / Symbios Logic 
53c1010 66MHz  Ultra3 SCSI Adapter (rev 01)
0002:00:02.1 SCSI storage controller: LSI Logic / Symbios Logic 
53c1010 66MHz  Ultra3 SCSI Adapter (rev 01)
0003:00:02.0 Ethernet controller: Broadcom Corporation NetXtreme 
BCM5704 Gigabit Ethernet
0003:00:02.1 Ethernet controller: Broadcom Corporation NetXtreme 
BCM5704 Gigabit Ethernet



That is good. All 4 devices show up on the PCI bus.



# ifconfig -a
eth0  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:7e
  inet addr:192.168.1.116  Bcast:192.168.1.255 
Mask:255.255.255.0

  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:11450 errors:0 dropped:0 overruns:0 frame:0
  TX packets:6220 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:1000502 (977.0 KiB)  TX bytes:516835 (504.7 KiB)
  Interrupt:6
Matching HWaddr to the local-mac-address properties in the prtconf 
output that is the device listed at node 0xf00bea74
I think that you have previously confirmed that this is connected to 
net0 (known as "net" in the OBP aliases)


net: '/pci@1f,70/network@2'

and from your dmesg output you posted earlier that matches too

[   83.749175] tg3 :00:02.0: eth0: No firmware running




eth1  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:80
  BROADCAST MULTICAST  MTU:1500  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:1000
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
  Interrupt:31


This HWaddr matches node 0xf00b0d34 which is net2.

net2: '/pci@1d,70/network@2'

So I think you need to do your tests connected to the net2 port.

[   45.499671] tg3 0003:00:02.0: eth1: dma_rwctrl[763f] 
dma_mask[32-bit]



Additionally it looks like the 2nd network device on each PCI bus is 
not getting

attached properly.

Does

dmesg | grep tg3


[   39.625716] tg3.c:v3.116 (December 3, 2010)
[   40.264438] tg3 :00:02.0: eth0: Tigon3 [partno

Re: Sun Fire V210 NIC's don't work

[Richard Mortimer]

On 15/11/2012 08:35, Michael Leicht wrote:

How about looking into OBP Config? Something like "test net" ?
I was going to suggest trying using "watch-net-all". It relies on there 
being traffic on the connected networks but can be useful. See

http://people.ee.ethz.ch/~ballisti/computer_topics/docs/U10svc/HTML/files/c0406.htm

More comments below...



I once had a similar Problem with a "hardcoded IP" (?) in OBP. Have you tried 
resseting your OBP and NVRAM?
My Blade 1500 silver shoudl have the same NIC and works just great, the missing 
Firmware Messages appeared but never had any Problem with them so i just 
ignored them.. ;)

Am 14.11.2012 um 19:38 schrieb Kaya Saman :


On 11/14/2012 06:25 PM, Richard Mortimer wrote:

On 14/11/2012 17:58, Kaya Saman wrote:

On 11/14/2012 05:52 PM, Frans van Berckel wrote:

On Wed, 2012-11-14 at 17:14 +, Kaya Saman wrote:


...snip...


I can't ping anywhere from the eth1 interface :-(

In addition I tried eth2 as the server has 4 NICs... it doesn't even get
recognized by the system??


Can you provide a few more bits of information.

1 - output from "prtconf -pv"  That will give an OBP view of the system. I 
checked in DaveM's git tree and there isn't a sample from the v210 in there
https://git.kernel.org/?p=linux/kernel/git/davem/prtconfs.git;a=tree

It would be good to push a copy of that to DaveM if you are agreeable.

2 - output from "ifconfig -a"

3 - output from "lspci"

Regards

Richard


Hi Richard,

# lspci
:00:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 
Gigabit Ethernet
:00:02.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 
Gigabit Ethernet
0001:00:06.0 Non-VGA unclassified device: ALi Corporation M7101 Power 
Management Controller [PMU]
0001:00:07.0 ISA bridge: ALi Corporation M1533/M1535/M1543 PCI to ISA Bridge 
[Aladdin IV/V/V+]
0001:00:0a.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03)
0001:00:0d.0 IDE interface: ALi Corporation M5229 IDE (rev c4)
0002:00:02.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 66MHz  
Ultra3 SCSI Adapter (rev 01)
0002:00:02.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 66MHz  
Ultra3 SCSI Adapter (rev 01)
0003:00:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 
Gigabit Ethernet
0003:00:02.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 
Gigabit Ethernet


That is good. All 4 devices show up on the PCI bus.



# ifconfig -a
eth0  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:7e
  inet addr:192.168.1.116  Bcast:192.168.1.255 Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:11450 errors:0 dropped:0 overruns:0 frame:0
  TX packets:6220 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:1000502 (977.0 KiB)  TX bytes:516835 (504.7 KiB)
  Interrupt:6
Matching HWaddr to the local-mac-address properties in the prtconf 
output that is the device listed at node 0xf00bea74
I think that you have previously confirmed that this is connected to 
net0 (known as "net" in the OBP aliases)


net: '/pci@1f,70/network@2'

and from your dmesg output you posted earlier that matches too

[   83.749175] tg3 :00:02.0: eth0: No firmware running




eth1  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:80
  BROADCAST MULTICAST  MTU:1500  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:1000
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
  Interrupt:31


This HWaddr matches node 0xf00b0d34 which is net2.

net2: '/pci@1d,70/network@2'

So I think you need to do your tests connected to the net2 port.

[   45.499671] tg3 0003:00:02.0: eth1: dma_rwctrl[763f] dma_mask[32-bit]


Additionally it looks like the 2nd network device on each PCI bus is not 
getting

attached properly.

Does

dmesg | grep tg3
or
dmesg | grep 0003:00:02

produce anything relating to the other ports?

Regards

Richard


loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:114 errors:0 dropped:0 overruns:0 frame:0
  TX packets:114 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:9542 (9.3 KiB)  TX bytes:9542 (9.3 KiB)



I have attached the prtconf file:


Regards,


Kaya







--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50a4ddd6.2050...@oldelvet.org.uk

Re: Sun Fire V210 NIC's don't work

[Michael Leicht]

How about looking into OBP Config? Something like "test net" ?
I once had a similar Problem with a "hardcoded IP" (?) in OBP. Have you tried 
resseting your OBP and NVRAM? 
My Blade 1500 silver shoudl have the same NIC and works just great, the missing 
Firmware Messages appeared but never had any Problem with them so i just 
ignored them.. ;)
Am 14.11.2012 um 21:16 schrieb Anonymous :

> 
> I have 1 word for you
> 
> SOLARIS!!!
> 
> 
> You wrote:
> 
>> On 11/14/2012 05:52 PM, Frans van Berckel wrote:
>>> On Wed, 2012-11-14 at 17:14 +, Kaya Saman wrote:
 For a subnet which is /30 CIDR or 255.255.255.252 you should get 4 IP's:
 network, broadcast, + 2 usable - this is a kind of pseudo point-to-point
 interface.
>>> 
>>> 
>>> A-ha, that sounds as a clear case.
>>> 
 All reloaded, sorry for the confusion but I rearranged things to test
 and see if eth1 became primary. Again no link :-( I will also try with
 eth2 and eth3 but I have my doubts; I even changed the cable and no joy.
 Something is definitely hinky!
>>> 
>>> 
>>> I am almost sure there's no problem with eth1. Check with ifconfig, the
>>> ip config is set okay now. Did you test already  pinging ping
>>> 192.168.140.2 from ping 192.168.140.1?
>> 
>> I can't ping anywhere from the eth1 interface :-(
>> 
>> In addition I tried eth2 as the server has 4 NICs... it doesn't even get 
>> recognized by the system??
>> 
>>> 
 I'm sure it's the driver or kernel bug though I could be wrong.
>>> Convince me?
>> 
>> I stuck my laptop into the same port using the same cable and hey-presto 
>> I got an IP address via DHCP.
>> 
>> If I set Debian to do the same I get nothing, and static also doesn't 
>> work meaning the network fabric is fully functional however, something 
>> is wrong with the NIC - either physically or a driver.
>> 
>> I could try it using port eth0 and I'm sure it will work fine as it's up 
>> and running on a different subnet now.
>> 
>> Hmm. I'm at a loss :-(
>> 
>>> 
>>> Thanks,
>>> 
>>> 
>>> Frans van Berckel
>>> 
>>> 
>> 
>> Thanks for the support
>> 
>> Regards,
>> 
>> 
>> Kaya
>> 
>> 
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: 
> http://lists.debian.org/ca793e62b9c440c7895d46460e0c6...@mail.hoi-polloi.org
> 


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8b492e5e-6617-4ceb-8d07-bdaa47ff4...@gmx.net

Re: Sun Fire V210 NIC's don't work

[Michael Leicht]

How about looking into OBP Config? Something like "test net" ?
I once had a similar Problem with a "hardcoded IP" (?) in OBP. Have you tried 
resseting your OBP and NVRAM? 
My Blade 1500 silver shoudl have the same NIC and works just great, the missing 
Firmware Messages appeared but never had any Problem with them so i just 
ignored them.. ;)

Am 14.11.2012 um 19:38 schrieb Kaya Saman :

> On 11/14/2012 06:25 PM, Richard Mortimer wrote:
>> On 14/11/2012 17:58, Kaya Saman wrote:
>>> On 11/14/2012 05:52 PM, Frans van Berckel wrote:
 On Wed, 2012-11-14 at 17:14 +, Kaya Saman wrote:
>> 
>> ...snip...
>> 
>>> I can't ping anywhere from the eth1 interface :-(
>>> 
>>> In addition I tried eth2 as the server has 4 NICs... it doesn't even get
>>> recognized by the system??
>> 
>> Can you provide a few more bits of information.
>> 
>> 1 - output from "prtconf -pv"  That will give an OBP view of the system. I 
>> checked in DaveM's git tree and there isn't a sample from the v210 in there
>> https://git.kernel.org/?p=linux/kernel/git/davem/prtconfs.git;a=tree
>> 
>> It would be good to push a copy of that to DaveM if you are agreeable.
>> 
>> 2 - output from "ifconfig -a"
>> 
>> 3 - output from "lspci"
>> 
>> Regards
>> 
>> Richard
> 
> Hi Richard,
> 
> # lspci
> :00:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 
> Gigabit Ethernet
> :00:02.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 
> Gigabit Ethernet
> 0001:00:06.0 Non-VGA unclassified device: ALi Corporation M7101 Power 
> Management Controller [PMU]
> 0001:00:07.0 ISA bridge: ALi Corporation M1533/M1535/M1543 PCI to ISA Bridge 
> [Aladdin IV/V/V+]
> 0001:00:0a.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03)
> 0001:00:0d.0 IDE interface: ALi Corporation M5229 IDE (rev c4)
> 0002:00:02.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 66MHz 
>  Ultra3 SCSI Adapter (rev 01)
> 0002:00:02.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 66MHz 
>  Ultra3 SCSI Adapter (rev 01)
> 0003:00:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 
> Gigabit Ethernet
> 0003:00:02.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 
> Gigabit Ethernet
> 
> 
> # ifconfig -a
> eth0  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:7e
>  inet addr:192.168.1.116  Bcast:192.168.1.255 Mask:255.255.255.0
>  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>  RX packets:11450 errors:0 dropped:0 overruns:0 frame:0
>  TX packets:6220 errors:0 dropped:0 overruns:0 carrier:0
>  collisions:0 txqueuelen:1000
>  RX bytes:1000502 (977.0 KiB)  TX bytes:516835 (504.7 KiB)
>  Interrupt:6
> 
> eth1  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:80
>  BROADCAST MULTICAST  MTU:1500  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:1000
>  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>  Interrupt:31
> 
> loLink encap:Local Loopback
>  inet addr:127.0.0.1  Mask:255.0.0.0
>  UP LOOPBACK RUNNING  MTU:16436  Metric:1
>  RX packets:114 errors:0 dropped:0 overruns:0 frame:0
>  TX packets:114 errors:0 dropped:0 overruns:0 carrier:0
>  collisions:0 txqueuelen:0
>  RX bytes:9542 (9.3 KiB)  TX bytes:9542 (9.3 KiB)
> 
> 
> 
> I have attached the prtconf file:
> 
> 
> Regards,
> 
> 
> Kaya
> 


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/f3680cbd-9f43-4e49-ac6e-4a2eb0c97...@gmx.net

Re: Sun Fire V210 NIC's don't work

[Anonymous]

I have 1 word for you

SOLARIS!!!


You wrote:

> On 11/14/2012 05:52 PM, Frans van Berckel wrote:
> > On Wed, 2012-11-14 at 17:14 +, Kaya Saman wrote:
> >> For a subnet which is /30 CIDR or 255.255.255.252 you should get 4 IP's:
> >> network, broadcast, + 2 usable - this is a kind of pseudo point-to-point
> >> interface.
> > 
> >
> > A-ha, that sounds as a clear case.
> >
> >> All reloaded, sorry for the confusion but I rearranged things to test
> >> and see if eth1 became primary. Again no link :-( I will also try with
> >> eth2 and eth3 but I have my doubts; I even changed the cable and no joy.
> >> Something is definitely hinky!
> > 
> >
> > I am almost sure there's no problem with eth1. Check with ifconfig, the
> > ip config is set okay now. Did you test already  pinging ping
> > 192.168.140.2 from ping 192.168.140.1?
> 
> I can't ping anywhere from the eth1 interface :-(
> 
> In addition I tried eth2 as the server has 4 NICs... it doesn't even get 
> recognized by the system??
> 
> >
> >> I'm sure it's the driver or kernel bug though I could be wrong.
> > Convince me?
> 
> I stuck my laptop into the same port using the same cable and hey-presto 
> I got an IP address via DHCP.
> 
> If I set Debian to do the same I get nothing, and static also doesn't 
> work meaning the network fabric is fully functional however, something 
> is wrong with the NIC - either physically or a driver.
> 
> I could try it using port eth0 and I'm sure it will work fine as it's up 
> and running on a different subnet now.
> 
> Hmm. I'm at a loss :-(
> 
> >
> > Thanks,
> >
> >
> > Frans van Berckel
> >
> >
> 
> Thanks for the support
> 
> Regards,
> 
> 
> Kaya
> 
> 


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca793e62b9c440c7895d46460e0c6...@mail.hoi-polloi.org

Re: Sun Fire V210 NIC's don't work

[Kaya Saman]

On 11/14/2012 06:25 PM, Richard Mortimer wrote:

On 14/11/2012 17:58, Kaya Saman wrote:

On 11/14/2012 05:52 PM, Frans van Berckel wrote:

On Wed, 2012-11-14 at 17:14 +, Kaya Saman wrote:


...snip...


I can't ping anywhere from the eth1 interface :-(

In addition I tried eth2 as the server has 4 NICs... it doesn't even get
recognized by the system??


Can you provide a few more bits of information.

1 - output from "prtconf -pv"  That will give an OBP view of the 
system. I checked in DaveM's git tree and there isn't a sample from 
the v210 in there

https://git.kernel.org/?p=linux/kernel/git/davem/prtconfs.git;a=tree

It would be good to push a copy of that to DaveM if you are agreeable.

2 - output from "ifconfig -a"

3 - output from "lspci"

Regards

Richard


Hi Richard,

# lspci
:00:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 
Gigabit Ethernet
:00:02.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 
Gigabit Ethernet
0001:00:06.0 Non-VGA unclassified device: ALi Corporation M7101 Power 
Management Controller [PMU]
0001:00:07.0 ISA bridge: ALi Corporation M1533/M1535/M1543 PCI to ISA 
Bridge [Aladdin IV/V/V+]

0001:00:0a.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03)
0001:00:0d.0 IDE interface: ALi Corporation M5229 IDE (rev c4)
0002:00:02.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 
66MHz  Ultra3 SCSI Adapter (rev 01)
0002:00:02.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 
66MHz  Ultra3 SCSI Adapter (rev 01)
0003:00:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 
Gigabit Ethernet
0003:00:02.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 
Gigabit Ethernet



# ifconfig -a
eth0  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:7e
  inet addr:192.168.1.116  Bcast:192.168.1.255 Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:11450 errors:0 dropped:0 overruns:0 frame:0
  TX packets:6220 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:1000502 (977.0 KiB)  TX bytes:516835 (504.7 KiB)
  Interrupt:6

eth1  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:80
  BROADCAST MULTICAST  MTU:1500  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:1000
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
  Interrupt:31

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:114 errors:0 dropped:0 overruns:0 frame:0
  TX packets:114 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:9542 (9.3 KiB)  TX bytes:9542 (9.3 KiB)



I have attached the prtconf file:


Regards,


Kaya
System Configuration:  Sun Microsystems  sun4u
Memory size: 2048 Megabytes
System Peripherals (PROM Nodes):

Node 0xf002a25c
    .node:  f002a25c
    banner-name: 'Sun Fire V210'
name: 'SUNW,Sun-Fire-V210'
model: 'SUNW,375-3344'
idprom:  
01840014.4f5d1e7e..5d1e7ede.f1010a00...00fa
scsi-initiator-id:  0007
stick-frequency:  00b71b00
clock-frequency:  09f437c0
breakpoint-trap:  007f
#size-cells:  0002
device_type: 'jbus'

Node 0xf002d444
.node:  f002d444
name: 'packages'

Node 0xf004aa38
.node:  f004aa38
name: 'SUNW,builtin-drivers'

Node 0xf005ae9c
.node:  f005ae9c
lba64:  
disk-write-fix:  
name: 'deblocker'

Node 0xf005b598
.node:  f005b598
name: 'disk-label'

Node 0xf005bef4
.node:  f005bef4
iso6429-1983-colors:  
name: 'terminal-emulator'

Node 0xf0063c14
.node:  f0063c14
source: '/flashprom@2,0:'
name: 'dropins'

Node 0xf008e8ac
.node:  f008e8ac
name: 'kbd-translator'

Node 0xf008fbc0
.node:  f008fbc0
name: 'obp-tftp'

Node 0xf009f564
.node:  f009f564
name: 'SUNW,i2c-ram-device'

Node 0xf009fda8
.node:  f009fda8
name: 'SUNW,fru-device'

Node 0xf00a05b0
.node:  f00a05b0
maximum-reason-length:  00fa
name: 'SUNW,asr'

Node 0xf002d4bc
.node:  f002d4bc
bootargs:  00
bootpath: '/pci@1c,60/scsi@2/disk@0,0:a'
mmu:  fff74080
memory:  fff74290
stdout:  fedbd918
stdi

Re: Sun Fire V210 NIC's don't work

[Richard Mortimer]

On 14/11/2012 17:58, Kaya Saman wrote:

On 11/14/2012 05:52 PM, Frans van Berckel wrote:

On Wed, 2012-11-14 at 17:14 +, Kaya Saman wrote:


...snip...


I can't ping anywhere from the eth1 interface :-(

In addition I tried eth2 as the server has 4 NICs... it doesn't even get
recognized by the system??


Can you provide a few more bits of information.

1 - output from "prtconf -pv"  That will give an OBP view of the system. 
I checked in DaveM's git tree and there isn't a sample from the v210 in 
there

https://git.kernel.org/?p=linux/kernel/git/davem/prtconfs.git;a=tree

It would be good to push a copy of that to DaveM if you are agreeable.

2 - output from "ifconfig -a"

3 - output from "lspci"

Regards

Richard


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50a3e208.2090...@oldelvet.org.uk

Re: Sun Fire V210 NIC's don't work

[Kaya Saman]

On 11/14/2012 05:52 PM, Frans van Berckel wrote:

On Wed, 2012-11-14 at 17:14 +, Kaya Saman wrote:

For a subnet which is /30 CIDR or 255.255.255.252 you should get 4 IP's:
network, broadcast, + 2 usable - this is a kind of pseudo point-to-point
interface.



A-ha, that sounds as a clear case.


All reloaded, sorry for the confusion but I rearranged things to test
and see if eth1 became primary. Again no link :-( I will also try with
eth2 and eth3 but I have my doubts; I even changed the cable and no joy.
Something is definitely hinky!



I am almost sure there's no problem with eth1. Check with ifconfig, the
ip config is set okay now. Did you test already  pinging ping
192.168.140.2 from ping 192.168.140.1?


I can't ping anywhere from the eth1 interface :-(

In addition I tried eth2 as the server has 4 NICs... it doesn't even get 
recognized by the system??





I'm sure it's the driver or kernel bug though I could be wrong.

Convince me?


I stuck my laptop into the same port using the same cable and hey-presto 
I got an IP address via DHCP.


If I set Debian to do the same I get nothing, and static also doesn't 
work meaning the network fabric is fully functional however, something 
is wrong with the NIC - either physically or a driver.


I could try it using port eth0 and I'm sure it will work fine as it's up 
and running on a different subnet now.


Hmm. I'm at a loss :-(



Thanks,


Frans van Berckel




Thanks for the support

Regards,


Kaya


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50a3dbe1.2000...@gmail.com

Re: Sun Fire V210 NIC's don't work

[Frans van Berckel]

On Wed, 2012-11-14 at 17:14 +, Kaya Saman wrote:
> For a subnet which is /30 CIDR or 255.255.255.252 you should get 4 IP's: 
> network, broadcast, + 2 usable - this is a kind of pseudo point-to-point 
> interface.



A-ha, that sounds as a clear case.

> All reloaded, sorry for the confusion but I rearranged things to test 
> and see if eth1 became primary. Again no link :-( I will also try with 
> eth2 and eth3 but I have my doubts; I even changed the cable and no joy. 
> Something is definitely hinky!



I am almost sure there's no problem with eth1. Check with ifconfig, the
ip config is set okay now. Did you test already  pinging ping
192.168.140.2 from ping 192.168.140.1? 

> I'm sure it's the driver or kernel bug though I could be wrong.

Convince me?

Thanks,


Frans van Berckel


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1352915550.1888.76.ca...@deblnxsrv224.osnetwork.nl

Re: Sun Fire V210 NIC's don't work

[Kaya Saman]

On 11/14/2012 03:32 PM, Frans van Berckel wrote:

On Wed, 2012-11-14 at 15:04 +, Kaya Saman wrote:

Actually the gateway for eth0 is: 192.168.1.1/24 and the gateway for
eth1 is 192.168.140.1/30; two completely different subnets.

Interfaces file:

auto eth0
iface eth0 inet static
address 192.168.1.116
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1

Looks okay to me.


auto eth1
#iface eth1 inet dhcp
iface eth1 inet static
address 192.168.140.2
netmask 255.255.255.252
network 192.168.140.0
broadcast 192.168.140.3
gateway 192.168.140.1

Why is broadcast set to 192.168.140.3? With a gateway set to 140.1
you've got to be able to ping 192.168.140.1, true.


For a subnet which is /30 CIDR or 255.255.255.252 you should get 4 IP's: 
network, broadcast, + 2 usable - this is a kind of pseudo point-to-point 
interface.





# netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags   MSS Window irtt
Iface
192.168.140.0   *   255.255.255.252 U 0 0  0
eth1
192.168.1.0 *   255.255.255.0   U 0 0  0
eth0
default 192.168.140.1   0.0.0.0 UG0 0  0
eth1
default cisco857w.optip 0.0.0.0 UG0 0  0
eth0


If however I run ping -I eth1 192.168.140.1 nothing happens and hence
dmesg is claiming the link isn't ready... the green lights on the back
of the system are on and so are the ones on the switch.

I think the eth1 link is up, because ifconfig show it is.


Also just now I reconfigured eth1 and took out the config from the eth0
in the interfaces file. However, after setting my switch to the proper
vlan on eth1 port I am still not getting any connectivity?

eth1  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:80
inet addr:192.168.1.116  Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST MULTICAST  MTU:1500  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:1000
RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
Interrupt:31

Now eth1 is set for 1.116 instead of 140.2? ... please reload networking
or reboot to get the settings okay.


All reloaded, sorry for the confusion but I rearranged things to test 
and see if eth1 became primary. Again no link :-( I will also try with 
eth2 and eth3 but I have my doubts; I even changed the cable and no joy. 
Something is definitely hinky!




# service networking reload


ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
  From 192.168.1.116 icmp_seq=1 Destination Host Unreachable
  From 192.168.1.116 icmp_seq=2 Destination Host Unreachable

Read up above ...

If reloading the settings doesn't help, maybe someone els with more vlan
experiences, will step in here.


I'm sure it's the driver or kernel bug though I could be wrong.



Thanks,


Frans van Berckel




Regards,


Kaya


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50a3d190.6050...@gmail.com

Re: Sun Fire V210 NIC's don't work

[Frans van Berckel]

On Wed, 2012-11-14 at 15:04 +, Kaya Saman wrote:
> Actually the gateway for eth0 is: 192.168.1.1/24 and the gateway for 
> eth1 is 192.168.140.1/30; two completely different subnets.
> 
> Interfaces file:
> 
> auto eth0
> iface eth0 inet static
> address 192.168.1.116
> netmask 255.255.255.0
> network 192.168.1.0
> broadcast 192.168.1.255
> gateway 192.168.1.1

Looks okay to me.

> auto eth1
> #iface eth1 inet dhcp
> iface eth1 inet static
> address 192.168.140.2
> netmask 255.255.255.252
> network 192.168.140.0
> broadcast 192.168.140.3
> gateway 192.168.140.1

Why is broadcast set to 192.168.140.3? With a gateway set to 140.1
you've got to be able to ping 192.168.140.1, true.

> # netstat -r
> Kernel IP routing table
> Destination Gateway Genmask Flags   MSS Window irtt 
> Iface
> 192.168.140.0   *   255.255.255.252 U 0 0  0 
> eth1
> 192.168.1.0 *   255.255.255.0   U 0 0  0 
> eth0
> default 192.168.140.1   0.0.0.0 UG0 0  0 
> eth1
> default cisco857w.optip 0.0.0.0 UG0 0  0 
> eth0
> 
> 
> If however I run ping -I eth1 192.168.140.1 nothing happens and hence 
> dmesg is claiming the link isn't ready... the green lights on the back 
> of the system are on and so are the ones on the switch.

I think the eth1 link is up, because ifconfig show it is.

> Also just now I reconfigured eth1 and took out the config from the eth0 
> in the interfaces file. However, after setting my switch to the proper 
> vlan on eth1 port I am still not getting any connectivity?
> 
> eth1  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:80
>inet addr:192.168.1.116  Bcast:192.168.1.255 Mask:255.255.255.0
>UP BROADCAST MULTICAST  MTU:1500  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:1000
>RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>Interrupt:31

Now eth1 is set for 1.116 instead of 140.2? ... please reload networking
or reboot to get the settings okay.

# service networking reload

> ping 192.168.1.1
> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
>  From 192.168.1.116 icmp_seq=1 Destination Host Unreachable
>  From 192.168.1.116 icmp_seq=2 Destination Host Unreachable

Read up above ...

If reloading the settings doesn't help, maybe someone els with more vlan
experiences, will step in here.

Thanks,


Frans van Berckel


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1352907171.1888.67.ca...@deblnxsrv224.osnetwork.nl

Re: Sun Fire V210 NIC's don't work

[Kaya Saman]

On 11/14/2012 02:39 PM, Frans van Berckel wrote:

On Wed, 2012-11-14 at 14:05 +, Kaya Saman wrote:

I am getting icmp echo responses.

I rejigged the interface to sit inside a new vlan:

eth1  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:80
inet addr:192.168.140.2  Bcast:192.168.140.3 Mask:255.255.255.252
UP BROADCAST MULTICAST  MTU:1500  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:1000
RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
Interrupt:31

ping 192.168.140.2
PING 192.168.140.2 (192.168.140.2) 56(84) bytes of data.
64 bytes from 192.168.140.2: icmp_req=1 ttl=64 time=0.057 ms
64 bytes from 192.168.140.2: icmp_req=2 ttl=64 time=0.036 ms
64 bytes from 192.168.140.2: icmp_req=3 ttl=64 time=0.040 ms

ping 192.168.140.1
PING 192.168.140.1 (192.168.140.1) 56(84) bytes of data.
  From 192.168.140.2 icmp_seq=1 Destination Host Unreachable
  From 192.168.140.2 icmp_seq=2 Destination Host Unreachable


while similar config on eth0 works fine.

In the example is 192.168.140.3 your vlan gateway? If so, please do ...

# route add default gw 192.168.140.3
# ping 192.168.140.3
# ping 192.168.140.2

The eth0 has the same gateway. So this will break your default eth0
communication. Now it's all set by hand. Later on you want this all well
in interfaces, true.


Actually the gateway for eth0 is: 192.168.1.1/24 and the gateway for 
eth1 is 192.168.140.1/30; two completely different subnets.


Interfaces file:

auto eth0
iface eth0 inet static
address 192.168.1.116
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1

auto eth1
#iface eth1 inet dhcp
iface eth1 inet static
address 192.168.140.2
netmask 255.255.255.252
network 192.168.140.0
broadcast 192.168.140.3
gateway 192.168.140.1


# netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags   MSS Window irtt 
Iface
192.168.140.0   *   255.255.255.252 U 0 0  0 
eth1
192.168.1.0 *   255.255.255.0   U 0 0  0 
eth0
default 192.168.140.1   0.0.0.0 UG0 0  0 
eth1
default cisco857w.optip 0.0.0.0 UG0 0  0 
eth0



If however I run ping -I eth1 192.168.140.1 nothing happens and hence 
dmesg is claiming the link isn't ready... the green lights on the back 
of the system are on and so are the ones on the switch.


Also just now I reconfigured eth1 and took out the config from the eth0 
in the interfaces file. However, after setting my switch to the proper 
vlan on eth1 port I am still not getting any connectivity?


eth1  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:80
  inet addr:192.168.1.116  Bcast:192.168.1.255 Mask:255.255.255.0
  UP BROADCAST MULTICAST  MTU:1500  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:1000
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
  Interrupt:31

ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
From 192.168.1.116 icmp_seq=1 Destination Host Unreachable
From 192.168.1.116 icmp_seq=2 Destination Host Unreachable







Check your settings with # ifconfig again. And does # update-initramfs
also complains about the missing firmware files, as asked?

update-initramfs -u
update-initramfs: Generating /boot/initrd.img-2.6.32-5-sparc64

That all, looks good to me.

Thanks,


Frans van Berckel




Outside of driver issue I really don't understand what's going on.


Regards,


Kaya


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50a3b306.40...@gmail.com

Re: Sun Fire V210 NIC's don't work

[Frans van Berckel]

On Wed, 2012-11-14 at 14:05 +, Kaya Saman wrote:
> 
> I am getting icmp echo responses.
> 
> I rejigged the interface to sit inside a new vlan:
> 
> eth1  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:80
>inet addr:192.168.140.2  Bcast:192.168.140.3 Mask:255.255.255.252
>UP BROADCAST MULTICAST  MTU:1500  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:1000
>RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>Interrupt:31
> 
> ping 192.168.140.2
> PING 192.168.140.2 (192.168.140.2) 56(84) bytes of data.
> 64 bytes from 192.168.140.2: icmp_req=1 ttl=64 time=0.057 ms
> 64 bytes from 192.168.140.2: icmp_req=2 ttl=64 time=0.036 ms
> 64 bytes from 192.168.140.2: icmp_req=3 ttl=64 time=0.040 ms
> 
> ping 192.168.140.1
> PING 192.168.140.1 (192.168.140.1) 56(84) bytes of data.
>  From 192.168.140.2 icmp_seq=1 Destination Host Unreachable
>  From 192.168.140.2 icmp_seq=2 Destination Host Unreachable
> 
> 
> while similar config on eth0 works fine.

In the example is 192.168.140.3 your vlan gateway? If so, please do ...

# route add default gw 192.168.140.3
# ping 192.168.140.3
# ping 192.168.140.2

The eth0 has the same gateway. So this will break your default eth0
communication. Now it's all set by hand. Later on you want this all well
in interfaces, true.

> > Check your settings with # ifconfig again. And does # update-initramfs
> > also complains about the missing firmware files, as asked?
> 
> update-initramfs -u
> update-initramfs: Generating /boot/initrd.img-2.6.32-5-sparc64

That all, looks good to me.

Thanks,


Frans van Berckel


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1352903995.1888.47.ca...@deblnxsrv224.osnetwork.nl

Re: Sun Fire V210 NIC's don't work

[Kaya Saman]

On 11/14/2012 01:24 PM, Frans van Berckel wrote:

On Wed, 2012-11-14 at 12:47 +, Kaya Saman wrote:

Hi Frans,

previously I got the firmware directly from the site above and simply
did a wget to put it into the /lib/firmware directory.

As of now I did what Patrick suggested and ran: apt-get install
firmware-linux-nonfree

It still didn't work :-(

[   43.836916] tg3 :00:02.0: eth0: Tigon3 [partno(none) rev 2100]
(PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:7e
[   43.974266] tg3 :00:02.0: eth0: attached PHY is 5704
(10/100/1000Base-T Ethernet) (WireSpeed[1])
[   44.094448] tg3 :00:02.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0]
ASF[0] TSOcap[1]
[   44.198525] tg3 :00:02.0: eth0: dma_rwctrl[763f] dma_mask[32-bit]
[   45.138092] tg3 0003:00:02.0: eth1: Tigon3 [partno(none) rev 2100]
(PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:80
[   45.275418] tg3 0003:00:02.0: eth1: attached PHY is 5704
(10/100/1000Base-T Ethernet) (WireSpeed[1])
[   45.395593] tg3 0003:00:02.0: eth1: RXcsums[1] LinkChgREG[0] MIirq[0]
ASF[0] TSOcap[1]
[   45.499671] tg3 0003:00:02.0: eth1: dma_rwctrl[763f] dma_mask[32-bit]
[   83.749175] tg3 :00:02.0: eth0: No firmware running
[   83.866559] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   85.411107] tg3 :00:02.0: eth0: Link is up at 100 Mbps, full duplex
[   85.498042] tg3 :00:02.0: eth0: Flow control is off for TX and
off for RX
[   85.593597] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   91.991628] tg3 0003:00:02.0: eth1: No firmware running
[   92.102114] ADDRCONF(NETDEV_UP): eth1: link is not ready

Here is requested output:

# ls -l /lib/firmware/tigon
total 16
-rw-r--r-- 1 root root 2668 Sep 19  2011 tg3.bin
-rw-r--r-- 1 root root 3884 Sep 19  2011 tg3_tso5.bin
-rw-r--r-- 1 root root 7004 Sep 19  2011 tg3_tso.bin

# ifconfig
eth0  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:7e
inet addr:192.168.1.116  Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:6504 errors:0 dropped:0 overruns:0 frame:0
TX packets:3567 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:461831 (451.0 KiB)  TX bytes:274816 (268.3 KiB)
Interrupt:6

eth1  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:80
UP BROADCAST MULTICAST  MTU:1500  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:1000
RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
Interrupt:31

loLink encap:Local Loopback
inet addr:127.0.0.1  Mask:255.0.0.0
UP LOOPBACK RUNNING  MTU:16436  Metric:1
RX packets:124 errors:0 dropped:0 overruns:0 frame:0
TX packets:124 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:10162 (9.9 KiB)  TX bytes:10162 (9.9 KiB)


uname -a shows:

2.6.32-5-sparc64 #1 Sun Sep 23 10:01:20 UTC 2012 sparc64 GNU/Linux

Hi Kaya,

That's clear. For me, just to be sure, what does these two do?

# ifconfig eth1 192.168.2.116 up
# ping 192.168.2.116


I am getting icmp echo responses.

I rejigged the interface to sit inside a new vlan:

eth1  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:80
  inet addr:192.168.140.2  Bcast:192.168.140.3 Mask:255.255.255.252
  UP BROADCAST MULTICAST  MTU:1500  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:1000
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
  Interrupt:31


ping 192.168.140.2
PING 192.168.140.2 (192.168.140.2) 56(84) bytes of data.
64 bytes from 192.168.140.2: icmp_req=1 ttl=64 time=0.057 ms
64 bytes from 192.168.140.2: icmp_req=2 ttl=64 time=0.036 ms
64 bytes from 192.168.140.2: icmp_req=3 ttl=64 time=0.040 ms

ping 192.168.140.1
PING 192.168.140.1 (192.168.140.1) 56(84) bytes of data.
From 192.168.140.2 icmp_seq=1 Destination Host Unreachable
From 192.168.140.2 icmp_seq=2 Destination Host Unreachable


while similar config on eth0 works fine.



Check your settings with # ifconfig again. And does # update-initramfs
also complains about the missing firmware files, as asked?


update-initramfs -u
update-initramfs: Generating /boot/initrd.img-2.6.32-5-sparc64


Thanks,


Frans van Berckel




Regards,


Kaya


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50a3a510.70...@gmail.com

Re: Sun Fire V210 NIC's don't work

[Frans van Berckel]

On Wed, 2012-11-14 at 12:47 +, Kaya Saman wrote:
> Hi Frans,
> 
> previously I got the firmware directly from the site above and simply 
> did a wget to put it into the /lib/firmware directory.
> 
> As of now I did what Patrick suggested and ran: apt-get install 
> firmware-linux-nonfree
> 
> It still didn't work :-(
> 
> [   43.836916] tg3 :00:02.0: eth0: Tigon3 [partno(none) rev 2100] 
> (PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:7e
> [   43.974266] tg3 :00:02.0: eth0: attached PHY is 5704 
> (10/100/1000Base-T Ethernet) (WireSpeed[1])
> [   44.094448] tg3 :00:02.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] 
> ASF[0] TSOcap[1]
> [   44.198525] tg3 :00:02.0: eth0: dma_rwctrl[763f] dma_mask[32-bit]
> [   45.138092] tg3 0003:00:02.0: eth1: Tigon3 [partno(none) rev 2100] 
> (PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:80
> [   45.275418] tg3 0003:00:02.0: eth1: attached PHY is 5704 
> (10/100/1000Base-T Ethernet) (WireSpeed[1])
> [   45.395593] tg3 0003:00:02.0: eth1: RXcsums[1] LinkChgREG[0] MIirq[0] 
> ASF[0] TSOcap[1]
> [   45.499671] tg3 0003:00:02.0: eth1: dma_rwctrl[763f] dma_mask[32-bit]
> [   83.749175] tg3 :00:02.0: eth0: No firmware running
> [   83.866559] ADDRCONF(NETDEV_UP): eth0: link is not ready
> [   85.411107] tg3 :00:02.0: eth0: Link is up at 100 Mbps, full duplex
> [   85.498042] tg3 :00:02.0: eth0: Flow control is off for TX and 
> off for RX
> [   85.593597] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [   91.991628] tg3 0003:00:02.0: eth1: No firmware running
> [   92.102114] ADDRCONF(NETDEV_UP): eth1: link is not ready
> 
> Here is requested output:
> 
> # ls -l /lib/firmware/tigon
> total 16
> -rw-r--r-- 1 root root 2668 Sep 19  2011 tg3.bin
> -rw-r--r-- 1 root root 3884 Sep 19  2011 tg3_tso5.bin
> -rw-r--r-- 1 root root 7004 Sep 19  2011 tg3_tso.bin
> 
> # ifconfig
> eth0  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:7e
>inet addr:192.168.1.116  Bcast:192.168.1.255 Mask:255.255.255.0
>UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>RX packets:6504 errors:0 dropped:0 overruns:0 frame:0
>TX packets:3567 errors:0 dropped:0 overruns:0 carrier:0
>collisions:0 txqueuelen:1000
>RX bytes:461831 (451.0 KiB)  TX bytes:274816 (268.3 KiB)
>Interrupt:6
> 
> eth1  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:80
>UP BROADCAST MULTICAST  MTU:1500  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:1000
>RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>Interrupt:31
> 
> loLink encap:Local Loopback
>inet addr:127.0.0.1  Mask:255.0.0.0
>UP LOOPBACK RUNNING  MTU:16436  Metric:1
>RX packets:124 errors:0 dropped:0 overruns:0 frame:0
>TX packets:124 errors:0 dropped:0 overruns:0 carrier:0
>collisions:0 txqueuelen:0
>RX bytes:10162 (9.9 KiB)  TX bytes:10162 (9.9 KiB)
> 
> 
> uname -a shows:
> 
> 2.6.32-5-sparc64 #1 Sun Sep 23 10:01:20 UTC 2012 sparc64 GNU/Linux

Hi Kaya,

That's clear. For me, just to be sure, what does these two do?

# ifconfig eth1 192.168.2.116 up
# ping 192.168.2.116

Check your settings with # ifconfig again. And does # update-initramfs
also complains about the missing firmware files, as asked?

Thanks,


Frans van Berckel


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1352899455.1888.33.ca...@deblnxsrv224.osnetwork.nl

Re: Sun Fire V210 NIC's don't work

[Kaya Saman]

On 11/14/2012 09:30 AM, Frans van Berckel wrote:

On Wed, 2012-11-14 at 00:13 +, Kaya Saman wrote:

Hi,

I attempted to configure a second nic on my server and added the new
config to the /etc/network/interfaces file however I am left with dmesg
errors:


[   91.472697] tg3 0003:00:02.0: eth1: Failed to load firmware
"tigon/tg3_tso.bin"


The switch which the port is connected to shows physical link and is
provisioned properly for the correct vlan, the first NIC eth0 is also
connected to the same switch and is working fine but still producing errors:


[   81.804867] tg3 :00:02.0: eth0: Failed to load firmware
"tigon/tg3_tso.bin"


I have tried loading the firmware from:

http://wiki.debian.org/Firmware

and putting it into /lib/firmware/tigon however then both NICs fail??

Could anyone suggest anything? With any other OS the system is fine so
I'm guessing it's a kernel bug or so.

Quick overview: What kernel version are you running? Is update-initramfs
complaining about the missing firmware as well? From where did you
download the firmware. What tg3_tso firmware version did you? Are you
saving as root? How does ls -l /lib/firmware/tigon looks like now? What
does ifconfig list.

Thanks,


Frans van Berckel




Hi Frans,

previously I got the firmware directly from the site above and simply 
did a wget to put it into the /lib/firmware directory.


As of now I did what Patrick suggested and ran: apt-get install 
firmware-linux-nonfree


It still didn't work :-(

[   43.836916] tg3 :00:02.0: eth0: Tigon3 [partno(none) rev 2100] 
(PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:7e
[   43.974266] tg3 :00:02.0: eth0: attached PHY is 5704 
(10/100/1000Base-T Ethernet) (WireSpeed[1])
[   44.094448] tg3 :00:02.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] 
ASF[0] TSOcap[1]

[   44.198525] tg3 :00:02.0: eth0: dma_rwctrl[763f] dma_mask[32-bit]
[   45.138092] tg3 0003:00:02.0: eth1: Tigon3 [partno(none) rev 2100] 
(PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:80
[   45.275418] tg3 0003:00:02.0: eth1: attached PHY is 5704 
(10/100/1000Base-T Ethernet) (WireSpeed[1])
[   45.395593] tg3 0003:00:02.0: eth1: RXcsums[1] LinkChgREG[0] MIirq[0] 
ASF[0] TSOcap[1]

[   45.499671] tg3 0003:00:02.0: eth1: dma_rwctrl[763f] dma_mask[32-bit]
[   83.749175] tg3 :00:02.0: eth0: No firmware running
[   83.866559] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   85.411107] tg3 :00:02.0: eth0: Link is up at 100 Mbps, full duplex
[   85.498042] tg3 :00:02.0: eth0: Flow control is off for TX and 
off for RX

[   85.593597] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   91.991628] tg3 0003:00:02.0: eth1: No firmware running
[   92.102114] ADDRCONF(NETDEV_UP): eth1: link is not ready


Here is requested output:


# ls -l /lib/firmware/tigon
total 16
-rw-r--r-- 1 root root 2668 Sep 19  2011 tg3.bin
-rw-r--r-- 1 root root 3884 Sep 19  2011 tg3_tso5.bin
-rw-r--r-- 1 root root 7004 Sep 19  2011 tg3_tso.bin

# ifconfig
eth0  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:7e
  inet addr:192.168.1.116  Bcast:192.168.1.255 Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:6504 errors:0 dropped:0 overruns:0 frame:0
  TX packets:3567 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:461831 (451.0 KiB)  TX bytes:274816 (268.3 KiB)
  Interrupt:6

eth1  Link encap:Ethernet  HWaddr 00:14:4f:5d:1e:80
  UP BROADCAST MULTICAST  MTU:1500  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:1000
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
  Interrupt:31

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:124 errors:0 dropped:0 overruns:0 frame:0
  TX packets:124 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:10162 (9.9 KiB)  TX bytes:10162 (9.9 KiB)


uname -a shows:

2.6.32-5-sparc64 #1 Sun Sep 23 10:01:20 UTC 2012 sparc64 GNU/Linux


Regards,


Kaya


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50a392ff.3020...@gmail.com

Re: Sun Fire V210 NIC's don't work

[Frans van Berckel]

On Wed, 2012-11-14 at 00:13 +, Kaya Saman wrote:
> Hi,
> 
> I attempted to configure a second nic on my server and added the new 
> config to the /etc/network/interfaces file however I am left with dmesg 
> errors:

> 
[   91.472697] tg3 0003:00:02.0: eth1: Failed to load firmware 
"tigon/tg3_tso.bin"

> The switch which the port is connected to shows physical link and is 
> provisioned properly for the correct vlan, the first NIC eth0 is also 
> connected to the same switch and is working fine but still producing errors:

> 
[   81.804867] tg3 :00:02.0: eth0: Failed to load firmware 
"tigon/tg3_tso.bin"

> I have tried loading the firmware from:
> 
> http://wiki.debian.org/Firmware
> 
> and putting it into /lib/firmware/tigon however then both NICs fail??
> 
> Could anyone suggest anything? With any other OS the system is fine so 
> I'm guessing it's a kernel bug or so.

Quick overview: What kernel version are you running? Is update-initramfs
complaining about the missing firmware as well? From where did you
download the firmware. What tg3_tso firmware version did you? Are you
saving as root? How does ls -l /lib/firmware/tigon looks like now? What
does ifconfig list.

Thanks,


Frans van Berckel


-- 
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1352885411.1888.21.ca...@deblnxsrv224.osnetwork.nl

Re: Sun Fire V210 NIC's don't work

[Patrick Baggett]

So you did apt-get install firmware-linux-nonfree and still no go? I didn't
seem to have any problems with this, though it was on an ia64 machine.

Patrick

On Tue, Nov 13, 2012 at 6:13 PM, Kaya Saman  wrote:

> Hi,
>
> I attempted to configure a second nic on my server and added the new
> config to the /etc/network/interfaces file however I am left with dmesg
> errors:
>
> [   44.418128] tg3 0003:00:02.0: eth1: Tigon3 [partno(none) rev 2100]
> (PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:80
> [   44.555470] tg3 0003:00:02.0: eth1: attached PHY is 5704
> (10/100/1000Base-T Ethernet) (WireSpeed[1])
> [   44.675644] tg3 0003:00:02.0: eth1: RXcsums[1] LinkChgREG[0] MIirq[0]
> ASF[0] TSOcap[1]
> [   44.779719] tg3 0003:00:02.0: eth1: dma_rwctrl[763f]
> dma_mask[32-bit]
> [   91.472697] tg3 0003:00:02.0: eth1: Failed to load firmware
> "tigon/tg3_tso.bin"
> [   91.568824] tg3 0003:00:02.0: eth1: TSO capability disabled
> [   92.927145] tg3 0003:00:02.0: eth1: No firmware running
> [   93.034647] ADDRCONF(NETDEV_UP): eth1: link is not ready
> [31557.037820] tg3 0003:00:02.0: eth1: Failed to load firmware
> "tigon/tg3_tso.bin"
> [31557.134305] tg3 0003:00:02.0: eth1: TSO capability disabled
> [31558.558344] ADDRCONF(NETDEV_UP): eth1: link is not ready
> [31734.774354] tg3 0003:00:02.0: eth1: Failed to load firmware
> "tigon/tg3_tso.bin"
> [31734.870823] tg3 0003:00:02.0: eth1: TSO capability disabled
> [31736.351600] ADDRCONF(NETDEV_UP): eth1: link is not ready
>
>
>
> The switch which the port is connected to shows physical link and is
> provisioned properly for the correct vlan, the first NIC eth0 is also
> connected to the same switch and is working fine but still producing errors:
>
> [   42.672840] tg3 :00:02.0: eth0: Tigon3 [partno(none) rev 2100]
> (PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:7e
> [   42.810136] tg3 :00:02.0: eth0: attached PHY is 5704
> (10/100/1000Base-T Ethernet) (WireSpeed[1])
> [   42.930317] tg3 :00:02.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0]
> ASF[0] TSOcap[1]
> [   43.034393] tg3 :00:02.0: eth0: dma_rwctrl[763f]
> dma_mask[32-bit]
> [   81.804867] tg3 :00:02.0: eth0: Failed to load firmware
> "tigon/tg3_tso.bin"
> [   81.901028] tg3 :00:02.0: eth0: TSO capability disabled
> [   83.261266] tg3 :00:02.0: eth0: No firmware running
> [   84.321904] ADDRCONF(NETDEV_UP): eth0: link is not ready
> [   84.921250] tg3 :00:02.0: eth0: Link is up at 100 Mbps, full duplex
> [   85.008173] tg3 :00:02.0: eth0: Flow control is off for TX and off
> for RX
> [   85.103732] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>
>
> I have tried loading the firmware from:
>
> http://wiki.debian.org/**Firmware 
>
> and putting it into /lib/firmware/tigon however then both NICs fail??
>
>
> Could anyone suggest anything? With any other OS the system is fine so I'm
> guessing it's a kernel bug or so.
>
>
>
> Regards,
>
>
> Kaya
>
>
> --
> To UNSUBSCRIBE, email to 
> debian-sparc-REQUEST@lists.**debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: 
> http://lists.debian.org/**50a2e22b.1050...@gmail.com
>
>

Sun Fire V210 NIC's don't work

[Kaya Saman]

Hi,

I attempted to configure a second nic on my server and added the new 
config to the /etc/network/interfaces file however I am left with dmesg 
errors:


[   44.418128] tg3 0003:00:02.0: eth1: Tigon3 [partno(none) rev 2100] 
(PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:80
[   44.555470] tg3 0003:00:02.0: eth1: attached PHY is 5704 
(10/100/1000Base-T Ethernet) (WireSpeed[1])
[   44.675644] tg3 0003:00:02.0: eth1: RXcsums[1] LinkChgREG[0] MIirq[0] 
ASF[0] TSOcap[1]

[   44.779719] tg3 0003:00:02.0: eth1: dma_rwctrl[763f] dma_mask[32-bit]
[   91.472697] tg3 0003:00:02.0: eth1: Failed to load firmware 
"tigon/tg3_tso.bin"

[   91.568824] tg3 0003:00:02.0: eth1: TSO capability disabled
[   92.927145] tg3 0003:00:02.0: eth1: No firmware running
[   93.034647] ADDRCONF(NETDEV_UP): eth1: link is not ready
[31557.037820] tg3 0003:00:02.0: eth1: Failed to load firmware 
"tigon/tg3_tso.bin"

[31557.134305] tg3 0003:00:02.0: eth1: TSO capability disabled
[31558.558344] ADDRCONF(NETDEV_UP): eth1: link is not ready
[31734.774354] tg3 0003:00:02.0: eth1: Failed to load firmware 
"tigon/tg3_tso.bin"

[31734.870823] tg3 0003:00:02.0: eth1: TSO capability disabled
[31736.351600] ADDRCONF(NETDEV_UP): eth1: link is not ready



The switch which the port is connected to shows physical link and is 
provisioned properly for the correct vlan, the first NIC eth0 is also 
connected to the same switch and is working fine but still producing errors:


[   42.672840] tg3 :00:02.0: eth0: Tigon3 [partno(none) rev 2100] 
(PCI:66MHz:64-bit) MAC address 00:14:4f:5d:1e:7e
[   42.810136] tg3 :00:02.0: eth0: attached PHY is 5704 
(10/100/1000Base-T Ethernet) (WireSpeed[1])
[   42.930317] tg3 :00:02.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] 
ASF[0] TSOcap[1]

[   43.034393] tg3 :00:02.0: eth0: dma_rwctrl[763f] dma_mask[32-bit]
[   81.804867] tg3 :00:02.0: eth0: Failed to load firmware 
"tigon/tg3_tso.bin"

[   81.901028] tg3 :00:02.0: eth0: TSO capability disabled
[   83.261266] tg3 :00:02.0: eth0: No firmware running
[   84.321904] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   84.921250] tg3 :00:02.0: eth0: Link is up at 100 Mbps, full duplex
[   85.008173] tg3 :00:02.0: eth0: Flow control is off for TX and 
off for RX

[   85.103732] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready


I have tried loading the firmware from:

http://wiki.debian.org/Firmware

and putting it into /lib/firmware/tigon however then both NICs fail??


Could anyone suggest anything? With any other OS the system is fine so 
I'm guessing it's a kernel bug or so.




Regards,


Kaya


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50a2e22b.1050...@gmail.com

Re: sun fire v210

[Patrick Dos Santos]

Hello

Test with this file
http://ftp.us.debian.org/debian/dists/stable/main/installer-sparc/current/images/sparc64/netboot/boot.img

It netinstall for sparc64 V210 is a sparc64 isn't it !!!
If you pass the file in " boot net "it's must work
Can you do a screenshot ??
To see the error message


Martin Rodriguez wrote:
> Hi Patrick,
>
> Thanx for requesting.
>
> Since I am new on sparc systems, I was learning how to get the tftpbppt.
> Now
> I got it but... a new problem, the system give to me the next msg:
>
> "The file just loaded does not appear to be an executable".
>
> So, any help U could give me I will apreciate.
>
> Thanx again.
>
>
>
> On 9/9/05, Patrick Dos Santos <[EMAIL PROTECTED]> wrote:
>>
>> Hi
>>
>> It works with this netboot on sparc64
>>
>> http://ftp.us.debian.org/debian/dists/stable/main/installer-sparc/current/images/sparc64/netboot/2.6/boot.img
>> It a net installations
>> Use a tfptboot wtih bootp or rarp and then in openboot tip " boot net
>> bootp boot.img" or "boot net boot.img"
>>
>> Good luck
>>
>> > I'm trying to install debian in a sun fire v210 with no luck.
>> >
>> > It fails when "Remapping the kernel" and hagns on there.
>> >
>> > Is there any option or comand that I'm missing? Is like the installer
>> > program can't find the image.
>> >
>> > I will apreciate any help. Thanx.
>> >
>>
>>
>>
>



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: sun fire v210

[Patrick Dos Santos]

Hi

It works with this netboot on sparc64
http://ftp.us.debian.org/debian/dists/stable/main/installer-sparc/current/images/sparc64/netboot/2.6/boot.img
It a net installations
Use a tfptboot wtih bootp or rarp and then in openboot tip " boot net
bootp boot.img" or "boot net boot.img"

Good luck

> I'm trying to install debian in a sun fire v210 with no luck.
>
> It fails when "Remapping the kernel" and hagns on there.
>
> Is there any option or comand that I'm missing? Is like the installer
> program can't find the image.
>
> I will apreciate any help. Thanx.
>



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

sun fire v210

[Martin Rodriguez]

I'm trying to install debian in a sun fire v210 with no luck.

It fails when "Remapping the kernel" and hagns on there.

Is there any option or comand that I'm missing? Is like the installer program can't find the image.

I will apreciate any help. Thanx.

CD images for Sun Fire v210

[Jama Poulsen]

Hi,

Both Sarge (sarge-sparc-netinst.iso of 2004-6-7) and Woody
(debian-30r2-sparc-binary-1.iso) fail to bootstrap the kernel
on a Sun Fire v210.

The Sarge netinst CD stops with:

  [ ENTER - Boot install ]   [ Type "expert" - Boot into expert mode ]
  boot: expert
  Allocated 8 Megs of memory at 0x4000 for kernel
  Uncompressing image...
  Loaded kernel version 2.4.26
  Loading initial ramdisk (1530032 bytes at 0x21F80 phys, 0x40C0 
virt)...
  Remapping the kernel... done.
  
and the Woody binary-1 CD stops with:

  [ ENTER - Boot install ]   [ Type "rescue" - Boot into rescue mode ]
  boot:
  Loading initial ramdisk
  SC Alert: Host System has Reset
  Fatal Error Reset
  CPU ... AFSR 0210.8000.. AFAR .07ff.ffc0.4420

Then I turned to this ML and found:
http://lists.debian.org/debian-sparc/2004/03/msg00314.html
http://lists.debian.org/debian-sparc/2003/11/msg3.html

There is talk about an image repository
(http://auric.debian.org/~bcollins/disks-sparc/current/) which seems
dead, and a patch which is probably applied by now.

I've tried to contact Krassimir Tzvetanov, but have gotten no reply yet.

Anyway, any ideas what Debian ISO image to try on the Sun Fire v210,
or should I file a bug report and perhaps try building better images?

Thanks,

Jama Poulsen
http://debianlinux.net
http://vemail.org