When I asked if you had tried the system with smp off, I meant, did you
try
it with it off and did the system stop crashing? It was just an idea for
narrowing down the problem (like it might not necessarily be an smp
issue).
Sorry for not being mnore clear on that.
-Cameron
On Thu, 31 May 2001,
On Fri, 1 Jun 2001, Anton Blanchard wrote:
> Hopefully we can get something into the boot-floppies libc to handle
> this (alternatively just get rid of the dcbf in memset(, 0, 0))
A bit off-topic, but you must not use memset() on a mapped frame buffer
(non-cached) because of the dcbf.
Gr{oetje,ee
On Thu, May 31, 2001 at 09:51:17PM -0400, Rahul Jain wrote:
> I don't know if it's an issue of debian not supporting IBM or IBM not
> supporting debian. For all I know, debian's installer could work find on the
> box I'll be testing, but unless IBM gives the `thumbs up' to debian, it's not
> an op
On Fri, Jun 01, 2001 at 06:42:12AM -0700, Anton Blanchard wrote:
>
>
> Hi,
>
> > even a small start would be helping me get better RS/6000 support in
> > ybin, since the boot-floppies completely rely on ybin to make
> > yaboot systems bootable.
>
> I have debian running on a number of RS600
On Thu, May 31, 2001 at 03:27:11PM -0800, Ethan Benson wrote:
> On Thu, May 31, 2001 at 02:59:43PM -0400, Rahul Jain wrote:
>
> > The PPC users only started complaining a week before that. (Good think, too,
> > since next week I start my job where I'll be playing with Linux 2.4 on an
> > SMP
> >
Hi,
> even a small start would be helping me get better RS/6000 support in
> ybin, since the boot-floppies completely rely on ybin to make
> yaboot systems bootable.
I have debian running on a number of RS6000s. Ignoring the install,
all that is required (on POWER3 machines) is to fix libc to
On Thu, May 31, 2001 at 10:30:56AM -0700, Andrew Sharp wrote:
> Rahul Jain wrote:
> >
> > On Thu, May 31, 2001 at 03:57:52AM -0700, Andrew Sharp wrote:
> > >
> > > I was misquoting someone else when I said it had endian problems.
> > > My bad. I should have said that it has powerpc problems, but
On Thu, May 31, 2001 at 02:59:43PM -0400, Rahul Jain wrote:
> The PPC users only started complaining a week before that. (Good think, too,
> since next week I start my job where I'll be playing with Linux 2.4 on an SMP
> RS/6000. Unfortunately, IBM doesn't have debian as a supported distro...)
th
On Thu, May 31, 2001 at 10:30:56AM -0700, Andrew Sharp wrote:
>
> Rahul Jain wrote:
> >
> > On Thu, May 31, 2001 at 03:57:52AM -0700, Andrew Sharp wrote:
> > >
> > > I was misquoting someone else when I said it had endian problems.
> > > My bad. I should have said that it has powerpc problems,
> I´m from the mac-side of live, i do not like options, i like smart
> software that determinds the fs by its own.
Good luck with that approach.
> I like options to force a program to do what I want, maybe doing stupid
> things.
> So i prefer to let the kernel look at the partition-table (or ano
-On Wed, 30 May 2001, Geert Uytterhoeven wrote:
> On Wed, 30 May 2001, Andrew Sharp wrote:
> > The big endian patches change the code to use little endian ordering
> > for all on-disk structures. IMO this is a mistake, and certainly
> > costs a dear performance penalty, because on big endian proc
Rahul Jain wrote:
>
> On Thu, May 31, 2001 at 03:57:52AM -0700, Andrew Sharp wrote:
> >
> > I was misquoting someone else when I said it had endian problems.
> > My bad. I should have said that it has powerpc problems, but don't
> > take that as gospel, because I'm just parroting someone else.
>
On Thu, May 31, 2001 at 08:55:52AM +0200, Thorsten Kukuk wrote:
>
> Since XFS runs stable on UltraSPARC, I see now reason why it should
> not work on Linux/PPC. I don't know if the on-disk-format is compatible
> between big- and little-endian systems, but this is in the moment no
> major problem
On Thu, May 31, 2001 at 03:57:52AM -0700, Andrew Sharp wrote:
>
> I was misquoting someone else when I said it had endian problems.
> My bad. I should have said that it has powerpc problems, but don't
> take that as gospel, because I'm just parroting someone else.
It used to have ppc problems.
On Wed, May 30, 2001 at 04:50:57PM +, Cameron Berkenpas wrote:
> I thought you might find this info relevant.
>
> I'm running a starmax 4000/200 with 80 megs of ram and a 200 mhz 604e.
> I also run kernel 2.4.4-pre6 and I've been up for 9 days now.
> Before this, I was up for about 25 days. I
Thorsten Kukuk wrote:
>
> On Thu, May 31, Steven Hanley wrote:
>
> > On Wed, May 30, 2001 at 05:39:09PM -0700, Mike Fedyk wrote:
> > > On Wed, May 30, 2001 at 02:09:16PM -0700, Andrew Sharp wrote:
> > > > Cameron Berkenpas wrote:
> > > > >
> > > > > I thought I read somewhere that XFS is working
On Thu, May 31, 2001 at 10:00:43AM +0200, Geert Uytterhoeven wrote:
> Hmm, I thought we had convinced them to keep on using big-endian for the
> metadata at Linux Kongress in Augsburg.
I dont know what the on disk format is, they may have kept the big endian
format, after all one would assume they
On Thu, 31 May 2001, Steven Hanley wrote:
> On Wed, May 30, 2001 at 05:39:09PM -0700, Mike Fedyk wrote:
> > On Wed, May 30, 2001 at 02:09:16PM -0700, Andrew Sharp wrote:
> > > Cameron Berkenpas wrote:
> > > >
> > > > I thought I read somewhere that XFS is working on PPC..
> > > > I take it that in
On Thu, May 31, Steven Hanley wrote:
> On Wed, May 30, 2001 at 05:39:09PM -0700, Mike Fedyk wrote:
> > On Wed, May 30, 2001 at 02:09:16PM -0700, Andrew Sharp wrote:
> > > Cameron Berkenpas wrote:
> > > >
> > > > I thought I read somewhere that XFS is working on PPC..
> > > > I take it that info w
On Wed, May 30, 2001 at 05:39:09PM -0700, Mike Fedyk wrote:
> On Wed, May 30, 2001 at 02:09:16PM -0700, Andrew Sharp wrote:
> > Cameron Berkenpas wrote:
> > >
> > > I thought I read somewhere that XFS is working on PPC..
> > > I take it that info was incorrect?
> >
> > I think what you read is th
On Wed, May 30, 2001 at 02:09:16PM -0700, Andrew Sharp wrote:
> Cameron Berkenpas wrote:
> >
> > I thought I read somewhere that XFS is working on PPC..
> > I take it that info was incorrect?
>
> I think what you read is that "...they are working on it for PPC."
> Supposedly an endian-fixed vers
> > Sane architectures (sparc64, ppc) have load/store with byte swap
> > instructions and if reiserfs is using them you shouldnt see a
> > performance penalty.
> >
> > cpu_to_le* etc make use of them.
>
> It does use them, but are these functions inlines with just one
> instruction? If not, then
Cameron Berkenpas wrote:
>
> I thought I read somewhere that XFS is working on PPC..
> I take it that info was incorrect?
I think what you read is that "...they are working on it for PPC."
Supposedly an endian-fixed version should be available soonish.
a
I thought you might find this info relevant.
I'm running a starmax 4000/200 with 80 megs of ram and a 200 mhz 604e.
I also run kernel 2.4.4-pre6 and I've been up for 9 days now.
Before this, I was up for about 25 days. I rebooted when I rebuilt my
kernel to upgrade as well as to add in a feature I
I thought I read somewhere that XFS is working on PPC..
I take it that info was incorrect?
-Cameron
On Wed, 30 May 2001, Andrew Sharp wrote:
> Anton Blanchard wrote:
> >
> > Me wrote:
> > > The big endian patches change the code to use little endian ordering
> > > for all on-disk structures. I
Anton Blanchard wrote:
>
> Me wrote:
> > The big endian patches change the code to use little endian ordering
> > for all on-disk structures. IMO this is a mistake, and certainly
> > costs a dear performance penalty, because on big endian processors,
> > this method requires converting endianness
Michel Dänzer wrote:
>
> Andrew Sharp wrote:
> > I would actually like to hear more about these discussions. Are
> > there any archives? Are they too old? Geez, if some silly person
> > wants to take a disk from one machine to another, well, that is what
> > vfat is for, no? ~:^)
>
> You ar
Christoph Ewering wrote:
[...]
> So i can mark partitions as ext2fs-big or ext2fs-little and the kernel
> supports both methods or by a recompile only one of both methods. So
> every architecture can read with maximum performance from the filesystem.
That's a really bad idea because on the one h
Andrew Sharp wrote:
>
> Geert Uytterhoeven wrote:
> >
> > On Wed, 30 May 2001, Andrew Sharp wrote:
> > > The big endian patches change the code to use little endian ordering
> > > for all on-disk structures. IMO this is a mistake, and certainly
> > > costs a dear performance penalty, because on b
On Wed, May 30, 2001 at 02:45:41PM +0200, Christoph Ewering wrote:
>
> I´m from the mac-side of live, i do not like options, i like smart
> software that determinds the fs by its own.
> I like options to force a program to do what I want, maybe doing stupid
> things.
> So i prefer to let the kern
> The big endian patches change the code to use little endian ordering
> for all on-disk structures. IMO this is a mistake, and certainly
> costs a dear performance penalty, because on big endian processors,
> this method requires converting endianness both ways (reading and
> writing) for all m
Hello!
Ethan Benson schrieb:
> yeah well life sucks, deal with it.
Done :-)
> > > If the system disk of my PPC box dies, I'll be happy to restore it from
> > > backup
> > > on some other machine...
> >
> > That´s no problem with the idea above. For restore speed is no need, so
> > it does not
Hiya
> I think it is absolutly stupid that x86 rules. They are slower than
> Alphas, use more power than PPCs.
...but cheaper than both 8^) 99% of the time I don't care what
CPU I've got, just as long as it runs my programs.
> A lot of work at the big-endian front has to be done again, becaus
On Wed, May 30, 2001 at 01:28:31PM +0200, Christoph Ewering wrote:
>
> I can not understand what´s so difficult to put information about the
> filesystem in the partition-table?
the partition table is the wrong place for such data, its stupid how
overloaded some disklabels *cough apple's *cough*
Geert Uytterhoeven schrieb:
>
> On Wed, 30 May 2001, Andrew Sharp wrote:
> > Geert Uytterhoeven wrote:
> > > On Wed, 30 May 2001, Andrew Sharp wrote:
> > > > The big endian patches change the code to use little endian ordering
> > > > for all on-disk structures. IMO this is a mistake, and certain
On Wed, 30 May 2001, Andrew Sharp wrote:
> Geert Uytterhoeven wrote:
> > On Wed, 30 May 2001, Andrew Sharp wrote:
> > > The big endian patches change the code to use little endian ordering
> > > for all on-disk structures. IMO this is a mistake, and certainly
> > > costs a dear performance penalty
On Wed, 30 May 2001, Ethan Benson wrote:
> ill ignore the possiblity of some coverter program to change the on
> disk endianess, that would be 1) slow and 2) dangerous and 3)
> inconvenient.
The convertor for ext2fs proved to be quite safe (man e2fsck). Note that only
metadata had to be swapped,
On Wed, May 30, 2001 at 02:57:03AM -0700, Andrew Sharp wrote:
>
> I would actually like to hear more about these discussions. Are
> there any archives? Are they too old? Geez, if some silly person
> wants to take a disk from one machine to another, well, that is what
> vfat is for, no? ~:^)
n
* on the Wed, May 30, 2001 at 02:05:38AM -0700, Andrew Sharp was blubbering:
> If you find yourself in a situation where the normal recovery mechanisms
> of reiserfs don't work, the file system is most likely so fubared that
> reiserfsck won't be able to do much. But it might.
I've got plenty o
Geert Uytterhoeven wrote:
>
> On Wed, 30 May 2001, Andrew Sharp wrote:
> > The big endian patches change the code to use little endian ordering
> > for all on-disk structures. IMO this is a mistake, and certainly
> > costs a dear performance penalty, because on big endian processors,
> > this met
On Wed, 30 May 2001, Andrew Sharp wrote:
> The big endian patches change the code to use little endian ordering
> for all on-disk structures. IMO this is a mistake, and certainly
> costs a dear performance penalty, because on big endian processors,
> this method requires converting endianness both
41 matches
Mail list logo
