All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.