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 dosetenv auto-boot? false reset-allOnce 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+ 400000 encode-int encode+ 0 encode-int encode+ 200000 encode-int encode+ " assigned-addresses" property device-end cd net3 83001110 encode-int 0 encode-int encode+ 400000 encode-int encode+ 0 encode-int encode+ 200000 encode-int encode+ " assigned-addresses" property device-end Once that is done you can boot using bootBut 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
lo Link 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