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 [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
