linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Michael Lundkvist <ml@epact.se>
To: linuxppc-dev@lists.linuxppc.org
Subject: Re: Going from 2.2.12 to 2.2.17pre10
Date: 07 Jul 2000 11:47:51 +0200	[thread overview]
Message-ID: <qpg0pmgtko.fsf@erbium.epact.se> (raw)
In-Reply-To: Gabriel Paubert's message of "Fri, 7 Jul 2000 11:21:33 +0200 (METDST)"


Gabriel Paubert <paubert@iram.es> writes:

> On 7 Jul 2000, Michael Lundkvist wrote:
>
> > 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.

> > 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/

  reply	other threads:[~2000-07-07  9:47 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-07-06 13:27 Going from 2.2.12 to 2.2.17pre10 Michael Lundkvist
2000-07-06 13:54 ` Hollis Blanchard
2000-07-06 17:17 ` Gabriel Paubert
2000-07-06 17:32   ` Michael Lundkvist
2000-07-06 17:55     ` Gabriel Paubert
2000-07-06 22:23       ` Michael Lundkvist
2000-07-07  8:22         ` Gabriel Paubert
2000-07-07  8:55           ` Michael Lundkvist
2000-07-07  9:21             ` Gabriel Paubert
2000-07-07  9:47               ` Michael Lundkvist [this message]
2000-07-07 10:19                 ` Gabriel Paubert
2000-07-08  0:08                   ` Problem with de4x5 on an MVME-2400 Michael Lundkvist
2000-07-10 11:58                     ` Gabriel Paubert
2000-07-12 13:01                       ` Michael Lundkvist
2000-07-08 23:29     ` Going from 2.2.12 to 2.2.17pre10 Matt Porter
2000-07-09  6:12       ` Michael Lundkvist
2000-07-10  5:29         ` Matt Porter
2000-07-10 12:25           ` Gabriel Paubert
2000-07-11  5:57             ` Matt Porter
2000-07-11  9:37               ` Adrian Cox
2000-07-11 10:17                 ` Benjamin Herrenschmidt
2000-07-11 12:57                   ` Adrian Cox
2000-07-11 14:10                     ` Claus
2000-07-11 19:15                     ` Geert Uytterhoeven
2000-07-12 13:31                       ` Benjamin Herrenschmidt
2000-07-13 11:17                         ` Geert Uytterhoeven
2000-07-12  9:11                     ` Timothy A. Seufert
2000-07-12 14:16                 ` Matt Porter
2000-07-13 11:43                   ` Gabriel Paubert
2000-07-13 14:12                     ` Matt Porter
2000-07-12 12:52           ` Michael Lundkvist
2000-07-12 14:17             ` Matt Porter
2000-07-10 12:12       ` Gabriel Paubert
2000-07-11  6:12         ` Matt Porter
2000-07-11 10:48           ` Gabriel Paubert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=qpg0pmgtko.fsf@erbium.epact.se \
    --to=ml@epact.se \
    --cc=linuxppc-dev@lists.linuxppc.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).