Re: Going from 2.2.12 to 2.2.17pre10

Gabriel Paubert [off-list ref] writes:

On 7 Jul 2000, Michael Lundkvist wrote:

quoted

I have to be able to create a standalone system so network boot is not
an option.

Sigh, and falshing the kernel neither I suppose...

If I can find a stable version it is an option. And I actually have
plenty of time to look. I need a rock-stable system by the end of this
year.

Fine, but 2.2.16 is claimed to have other problems (look at Alan's release
notes for each 2.2.17-pre).

I'll try 2.2.17pre10 tonight and see if I have more luck with that.

quoted

I have tried two MVME-2400 boards but I haven't had time to do any
systematic testing. It always crashes in find_buffer in fs/buffer.c
during moderate to heavy disk activity. I'm starting to suspect that
the CMD646 isn't being setup correctly since it feels like the system
was more stable after a cold reboot. I'll have to test it a bit more.

Ok, that's likely the cause. SCSI (NCR) disk access is rock solid here on
MVME2600.

I guess I should talk to Ramix. They have been helpful before.
I'll also try to go back to an older version of the
CMD646-driver. There are a few timing related setup changes in the
newer versions.

No, it's not the backplane, it's the implementation in the MVME boards:


PCI bus <-> Universe <-> Layer of buffers <-> VME connectors

The PCI bus is probably largely buried inside the PCB layers.
The Universe is a BGA.
The VME bus has only one (bidirectional) reset signal.

However there are 2 VME reset signal buffer, one inwards and one outwards
for 2 pins of the Universe (VME reset in and VME reset out).

	Universe       Buffers       VME connector

	VXSYSRST-------|>o--+
                            |--------SYSRST*
	VRSYSRST#------<|---+

The only accessible place (with adequate lab equipment) are the buffers:
cut the input or the output of the receive buffer and connect it to the
power supply (safer on the input since it can directly be connected to
the buffer power supply while I'm not sure that some versions of the
Universe are not 3.3V only)   .

OK. Then it looks quite possible. Thanks for the info.

/Micke

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On 7 Jul 2000, Michael Lundkvist wrote:

If I can find a stable version it is an option. And I actually have
plenty of time to look. I need a rock-stable system by the end of this
year.

Ok, I hoppe 2.4 will be out then...

I'll try 2.2.17pre10 tonight and see if I have more luck with that.

Well, I'm going to put my patches for 2.2.16 in an untested directory
then...

I guess I should talk to Ramix. They have been helpful before.
I'll also try to go back to an older version of the
CMD646-driver. There are a few timing related setup changes in the
newer versions.

This might indeed be the problem. My 2400 are not heavily stressed but
nevertheless they are stable: one has 52 days and the other 39 days
uptime. The second one had a strange behaviour when a lightning struck the
telescope however and had to be powered down before rebooting, hard reset
through front panel push button would not work (not even reaching PPCBUG
boot messages).

quoted

The only accessible place (with adequate lab equipment) are the buffers:
cut the input or the output of the receive buffer and connect it to the
power supply (safer on the input since it can directly be connected to
the buffer power supply while I'm not sure that some versions of the
Universe are not 3.3V only)   .

OK. Then it looks quite possible. Thanks for the info.

Thee only problem is to locate this damned buffer (just find which one is
connected to the VME bus SYSRST but there are so many).

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/