Yes, that was not easy to miss. I was simply being clear. The plan9
compiler, thus its take on inline asm, doesn't run on ia64 and alpha as far
as I can see from the latest release.
} NONE of my examples were about the x86.
}
} I gave the alpha as a specific example. The same issues are true
I'm talking about _modern_ processors, not processors that dominate the
modern age. This isn't x86. I don't believe that even aggressive
re-ordering will cause a serious hit in performance on function calls.
Unconditional branches are definitely predictable so icache pre-fetches are
not more
I'm talking about _modern_ processors, not processors that dominate the
modern age. This isn't x86. I don't believe that even aggressive
re-ordering will cause a serious hit in performance on function calls.
Unconditional branches are definitely predictable so icache pre-fetches are
not more
Yes, that was not easy to miss. I was simply being clear. The plan9
compiler, thus its take on inline asm, doesn't run on ia64 and alpha as far
as I can see from the latest release.
} NONE of my examples were about the x86.
}
} I gave the alpha as a specific example. The same issues are true
There isn't such a crippling difference between straight-line and code with
unconditional branches in it with modern processors. In fact, there's very
little measurable difference.
If you're looking for something to blame hurd performance on I'd suggest
the entire design of Mach, not inline asm
There isn't such a crippling difference between straight-line and code with
unconditional branches in it with modern processors. In fact, there's very
little measurable difference.
If you're looking for something to blame hurd performance on I'd suggest
the entire design of Mach, not inline asm
Can we then expect to see all mention of authors in drivers disappear from
the boot? Same with url's, version #'s and the like? The built by
user@host message is a good bit of "drumming ones own drum" while
contributing very little (running 'make' vs. writing the system).
Is the kernel boot
Can we then expect to see all mention of authors in drivers disappear from
the boot? Same with url's, version #'s and the like? The built by
user@host message is a good bit of drumming ones own drum while
contributing very little (running 'make' vs. writing the system).
Is the kernel boot
I like the assurances that the PowerPC is a "capable" processor. Perhaps
even adequate. Perhaps we should note that Dave has yet to take me up on
my challenge to the sparc to sissy-slap the PowerPC...
} +++ /tmp/Configure.help Tue Jun 26 10:36:21 2001
} @@ -171,7 +171,7 @@
} Power PC
I like the assurances that the PowerPC is a capable processor. Perhaps
even adequate. Perhaps we should note that Dave has yet to take me up on
my challenge to the sparc to sissy-slap the PowerPC...
} +++ /tmp/Configure.help Tue Jun 26 10:36:21 2001
} @@ -171,7 +171,7 @@
} Power PC
Don't forget the linux-kernel favorite, "Debuggers are for bad
programmers".
} Here are more from the same basket you obviously got the first quote from:
}
}
} Virtual memory is only for unskilled programmers who don't know how to use
} overlays.
}
Don't forget the linux-kernel favorite, Debuggers are for bad
programmers.
} Here are more from the same basket you obviously got the first quote from:
}
}
} Virtual memory is only for unskilled programmers who don't know how to use
} overlays.
}
Starting today, Paul Mackerras ([EMAIL PROTECTED]) is taking over as
maintainer of the Linux/PPC 32-bit tree and will continue as the Linux/PPC
64-bit tree maintainer.
The stable and development trees (2.2 and 2.4) will be moving away from
the FSMLabs ftp/rsync/BitKeeper repository to the
Starting today, Paul Mackerras ([EMAIL PROTECTED]) is taking over as
maintainer of the Linux/PPC 32-bit tree and will continue as the Linux/PPC
64-bit tree maintainer.
The stable and development trees (2.2 and 2.4) will be moving away from
the FSMLabs ftp/rsync/BitKeeper repository to the
You can get a working tree from www.fsmlabs.com/linuxppcbk.html or just
apply the patches in ftp.kernel.org/pub/linux/kernel/people/cort/
If you have any trouble with that, let me know.
} [1.] One line summary of the problem:
} 2.4.4 fails to compile for G3 ppc
}
} [2.] Full description of
You can get a working tree from www.fsmlabs.com/linuxppcbk.html or just
apply the patches in ftp.kernel.org/pub/linux/kernel/people/cort/
If you have any trouble with that, let me know.
} [1.] One line summary of the problem:
} 2.4.4 fails to compile for G3 ppc
}
} [2.] Full description of
Linux/PPC snapshots and patches against Linus' trees are available from:
ftp://ftp.fsmlabs.com/pub/linuxppc/
ftp://ftp.kernel.org/pub/linux/kernel/people/cort and its mirrors
I'll be keeping the 2.2 and 2.4 snapshots and patches up-to-date on both
sites. Please use the kernel.org (and mirror)
Linux/PPC snapshots and patches against Linus' trees are available from:
ftp://ftp.fsmlabs.com/pub/linuxppc/
ftp://ftp.kernel.org/pub/linux/kernel/people/cort and its mirrors
I'll be keeping the 2.2 and 2.4 snapshots and patches up-to-date on both
sites. Please use the kernel.org (and mirror)
} On 22 Mar 2001 [EMAIL PROTECTED] wrote:
}
} > Hi. I was wondering if there has been any discussion of kernel
} > regression testing. Wouldn't it be great if we didn't have to depend
} > on human testers to verify every change didn't break something?
} >
} > OK, I'll admit I haven't given
We have a start for PPC. It has the title "Regression Tester" but is
actually a "compiles and boots tester". The aim is a automated regression
test.
Take a look at http://altus.drgw.net/
It pulls directly from our BitKeeper archive every time we push a change
and goes through the build
} On 22 Mar 2001 [EMAIL PROTECTED] wrote:
}
} Hi. I was wondering if there has been any discussion of kernel
} regression testing. Wouldn't it be great if we didn't have to depend
} on human testers to verify every change didn't break something?
}
} OK, I'll admit I haven't given this a
We have a start for PPC. It has the title "Regression Tester" but is
actually a "compiles and boots tester". The aim is a automated regression
test.
Take a look at http://altus.drgw.net/
It pulls directly from our BitKeeper archive every time we push a change
and goes through the build
We have about 12 interrupt controllers we end up using on PPC. I'm
suspicious of any effort to base Linux/PPC generic interrupt control code
paths on a software architecture that's been tested with 3. More to the
point, we get ASIC's that roll in a standard interrupt controller and add
some
We have about 12 interrupt controllers we end up using on PPC. I'm
suspicious of any effort to base Linux/PPC generic interrupt control code
paths on a software architecture that's been tested with 3. More to the
point, we get ASIC's that roll in a standard interrupt controller and add
some
I still get huge over-runs with fbdev (much improved, though).
Andrew, are you still working on it? If so, I'm happy to keep you
up-to-date on performance WRT Linux/PPC.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
} Also, we currently don't use the same mecanism as i386, and since Linus
} expressed his desire to have irq.c become generic, I'm trying to make sure
} I fully understand it before merging in PPC the bits that I didn't merge
} them yet.
More generic in terms of using irq_desc[] and some similar
} Also, we currently don't use the same mecanism as i386, and since Linus
} expressed his desire to have irq.c become generic, I'm trying to make sure
} I fully understand it before merging in PPC the bits that I didn't merge
} them yet.
More generic in terms of using irq_desc[] and some similar
I still get huge over-runs with fbdev (much improved, though).
Andrew, are you still working on it? If so, I'm happy to keep you
up-to-date on performance WRT Linux/PPC.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
} > I don't have a simple way on PPC to cause the interrupt to happen again,
} > as you can imagine this is rather controller-specific. However, looking
} > at the code closely, I couldn't figure out a case where having
} > IRQ_PENDING in enable_irq() makes sense.
}
} It only makes sense for
} I don't have a simple way on PPC to cause the interrupt to happen again,
} as you can imagine this is rather controller-specific. However, looking
} at the code closely, I couldn't figure out a case where having
} IRQ_PENDING in enable_irq() makes sense.
}
} It only makes sense for broken
} > } The fbdev console problem is too horrible to pretend to solve by resyncing
} > } on timer interrupts. At least for the x86 the fix is to sort out the fb
} > } locking properly
} >
} > How close is that?
}
} Its not in itself a big problem, but since it doesnt reformat your hard disk,
}
} > We have the same trouble on PPC but we make sure to re-sync on each
} > interrupt. We can see several lost timer interrupts after a ^L in emacs
} > running on the fb console. The resync lets us catch up on those interrupts
} > (and not lose time) but we still spend a lot of time not
We have the same trouble on PPC but we make sure to re-sync on each
interrupt. We can see several lost timer interrupts after a ^L in emacs
running on the fb console. The resync lets us catch up on those interrupts
(and not lose time) but we still spend a lot of time not servicing
interrupts.
We have the same trouble on PPC but we make sure to re-sync on each
interrupt. We can see several lost timer interrupts after a ^L in emacs
running on the fb console. The resync lets us catch up on those interrupts
(and not lose time) but we still spend a lot of time not servicing
interrupts.
} We have the same trouble on PPC but we make sure to re-sync on each
} interrupt. We can see several lost timer interrupts after a ^L in emacs
} running on the fb console. The resync lets us catch up on those interrupts
} (and not lose time) but we still spend a lot of time not servicing
}
} } The fbdev console problem is too horrible to pretend to solve by resyncing
} } on timer interrupts. At least for the x86 the fix is to sort out the fb
} } locking properly
}
} How close is that?
}
} Its not in itself a big problem, but since it doesnt reformat your hard disk,
} explode
} Quick question: has anyone used the lance.c driver for a 100BaseT
} network PCI device? If so, what successes/failures did you run into?
}
} (I'm working with an Am79C973 chip.)
I'd recommend the pcnet32.c driver for that chip, instead. I was running
it for a little over a year at 100Mbps
} Quick question: has anyone used the lance.c driver for a 100BaseT
} network PCI device? If so, what successes/failures did you run into?
}
} (I'm working with an Am79C973 chip.)
I'd recommend the pcnet32.c driver for that chip, instead. I was running
it for a little over a year at 100Mbps
} When will the powerpc tree be merged ? Neither the
} official 2.4 nor the -ac8 work. They don't even compile.
Grab a tree from www.fsmlabs.com/linuxppcbk.html. Those always compile and
are up-to-date.
I send patches, but they don't always make it into the main tree. In the
mean time, you
} When will the powerpc tree be merged ? Neither the
} official 2.4 nor the -ac8 work. They don't even compile.
Grab a tree from www.fsmlabs.com/linuxppcbk.html. Those always compile and
are up-to-date.
I send patches, but they don't always make it into the main tree. In the
mean time, you
} > - If you care about latency, be *very* cautious about upgrading to
} > XFree86 4.x. I'll cover this issue in a separate email, copied
} > to the XFree team.
}
} Did that email pass by me unnoticed? What's the prob with XF86 4.0?
The darn thing disables intrs on its own for quite some
} - If you care about latency, be *very* cautious about upgrading to
}XFree86 4.x. I'll cover this issue in a separate email, copied
}to the XFree team.
}
} Did that email pass by me unnoticed? What's the prob with XF86 4.0?
The darn thing disables intrs on its own for quite some
} User space applications _must_ not include kernel headers. Even
} modutils does not include linux/module.h, it has its own portable
} (kernels 2.0 - 2.4) version.
There are cases where a user-program _must_ include kernel headers. Some
glibc versions have incorrect values for MCL_* and
} User space applications _must_ not include kernel headers. Even
} modutils does not include linux/module.h, it has its own portable
} (kernels 2.0 - 2.4) version.
There are cases where a user-program _must_ include kernel headers. Some
glibc versions have incorrect values for MCL_* and
Grab the version at www.fsmlabs.com/linuxppcbk.html, it's fixed. Linus
hasn't absorbed out updates in a while. I'll feed him a bit more this
evening...
} -o vmlinux
} arch/ppc/mm/mm.o: In function `map_page':
} arch/ppc/mm/mm.o(.text+0xd90): undefined reference to `set_pgdir'
}
} 2.4.0-test10 doesn't compile correctly on a mac.
} Only 2 changes are necessary to make it work.
} Or are there any bigger problems with the ppc arch?
}
} the 2 changes:
} in ./include/asm-ppc/param.h the following lines have to be added
} right before the last #endif:
}
} #ifdef __KERNEL__
}
} 2.4.0-test10 doesn't compile correctly on a mac.
} Only 2 changes are necessary to make it work.
} Or are there any bigger problems with the ppc arch?
}
} the 2 changes:
} in ./include/asm-ppc/param.h the following lines have to be added
} right before the last #endif:
}
} #ifdef __KERNEL__
}
} Hi,
}
} > How? If you compile with egcs-2.91.66 without frame pointers on ix86 then
} > __builtin_return_address() yields garbage. Does anybody have a generic
} > solution to this problem, other than "compile with frame pointers"? Or is
} > it fixed in newer versions of gcc?
}
} Are you
} Hi,
}
} How? If you compile with egcs-2.91.66 without frame pointers on ix86 then
} __builtin_return_address() yields garbage. Does anybody have a generic
} solution to this problem, other than "compile with frame pointers"? Or is
} it fixed in newer versions of gcc?
}
} Are you sure?
}Date: Thu, 12 Oct 2000 00:03:31 -0400 (EDT)
}From: "Benjamin C.R. LaHaise" <[EMAIL PROTECTED]>
}
}It's safe because of how x86s hardware works
}
} What about other platforms?
On the PPC's that don't do a hardware walk we do a normal write to the
hash table (with a spinlock).
} Andrea Arcangeli <[EMAIL PROTECTED]> said:
} > On Wed, Oct 11, 2000 at 06:19:23PM -0700, David S. Miller wrote:
} > > I honestly see nothing wrong with it. There are different parts of
} > > the compiler stressed by the kernel build as opposed to most userland
} > > compilation, and
}Date: Wed, 11 Oct 2000 19:36:15 -0600
}From: Cort Dougan <[EMAIL PROTECTED]>
}
}I don't think "it's been done in UNIX before" is a
}strong argument for something being done now :)
}
} True, but I think that "different things have different requirements&qu
}Date: Wed, 11 Oct 2000 19:15:24 -0600
}From: Cort Dougan <[EMAIL PROTECTED]>
}
}It's not a new idea but that doesn't make it a good one. The idea
}of distributing the _same_ compiler but different versions is
}nutty.
}
} Actually, this is common practic
> Hardly. In fact the idea of distributing a different compiler for kernels
> comes from debian and the kgcc naming convention from Conectiva.
It's not a new idea but that doesn't make it a good one. The idea of
distributing the _same_ compiler but different versions is nutty.
-
To unsubscribe
Hardly. In fact the idea of distributing a different compiler for kernels
comes from debian and the kgcc naming convention from Conectiva.
It's not a new idea but that doesn't make it a good one. The idea of
distributing the _same_ compiler but different versions is nutty.
-
To unsubscribe
}Date: Wed, 11 Oct 2000 19:15:24 -0600
}From: Cort Dougan [EMAIL PROTECTED]
}
}It's not a new idea but that doesn't make it a good one. The idea
}of distributing the _same_ compiler but different versions is
}nutty.
}
} Actually, this is common practice even
}Date: Wed, 11 Oct 2000 19:36:15 -0600
}From: Cort Dougan [EMAIL PROTECTED]
}
}I don't think "it's been done in UNIX before" is a
}strong argument for something being done now :)
}
} True, but I think that "different things have different requirements"
} is a
} Andrea Arcangeli [EMAIL PROTECTED] said:
} On Wed, Oct 11, 2000 at 06:19:23PM -0700, David S. Miller wrote:
} I honestly see nothing wrong with it. There are different parts of
} the compiler stressed by the kernel build as opposed to most userland
} compilation, and furthermore the
}Date: Thu, 12 Oct 2000 00:03:31 -0400 (EDT)
}From: "Benjamin C.R. LaHaise" [EMAIL PROTECTED]
}
}It's safe because of how x86s hardware works
}
} What about other platforms?
On the PPC's that don't do a hardware walk we do a normal write to the
hash table (with a spinlock).
} The only thing I'm not sure is that I believe the SPARC people uses
} ttyS* for Zilog 8530-based serial ports. I don't know if we want to
} define this as NS8250-family serial ports in light of that; I more
} tended to think of it as the "default" serial port for the
} architecture.
}
} It's
} The only thing I'm not sure is that I believe the SPARC people uses
} ttyS* for Zilog 8530-based serial ports. I don't know if we want to
} define this as NS8250-family serial ports in light of that; I more
} tended to think of it as the "default" serial port for the
} architecture.
}
} It's
} On Wed, 20 Sep 2000, Adrian Cox wrote:
} > cPCI is PCI + hotswap. Most people seem to ignore the hotswap, except at
} > tradeshows.
}
} ISPs certainly don't ignore hotswap. Unfortunately, Linux does. :) :(
PowerPC has hotswap for Motorola boards thanks to Johnnie Peters and Matt
Porter.
-
To
}Date: Tue, 19 Sep 2000 16:49:00 -0600
}From: Cort Dougan <[EMAIL PROTECTED]>
}
}If anyone else wants access to the 2.5 tree we have as a place to
}keep experimental changes I'm happy to open it up to the outside.
}
} Well, let's first step back for a second and
} Cort Dougan writes:
} > I've had to create a 2.5 for the PPC tree so we aren't stuck with either no
} > experimentation or experimentation in the stable trees.
}
} Well, you're not alone. There's a lot going on in the ARM side of Linux
} which looks very promising; yes it is true th
} On Tue, Sep 19, 2000 at 09:53:41PM +0200, [EMAIL PROTECTED] wrote:
} >
} >
} > >> Linus,
} > >
} > >> Where do architecture maintainers stand when they don't submit their
} > >> problems to linux-kernel or the great Ted Bug List(tm)?
} > >
} > >Up against the wall so we can shoot them?
} > >
} On Tue, Sep 19, 2000 at 09:53:41PM +0200, [EMAIL PROTECTED] wrote:
}
}
}Linus,
}
} Where do architecture maintainers stand when they don't submit their
} problems to linux-kernel or the great Ted Bug List(tm)?
}
} Up against the wall so we can shoot them?
}
} :)
}
} So I
}Date: Tue, 19 Sep 2000 16:49:00 -0600
}From: Cort Dougan [EMAIL PROTECTED]
}
}If anyone else wants access to the 2.5 tree we have as a place to
}keep experimental changes I'm happy to open it up to the outside.
}
} Well, let's first step back for a second and really think
I trimmed the CC list a bit, it was getting large. I just left
linux-kernel since I believe everyone is on that list.
} It's this critical mass which is missing; otherwise, my custom scripts
} which use RCS and where I only check in those files which I modify are
} quite frankly, more
} Second, I doubt very much that Linus would require BitKeeper only. It's
} trivial for BK to export patches which are bit for bit identical to the
} traditional "diff -Nur" output. BKweb does that on the fly, go look at
}
} http://www.bitmover.com:[EMAIL PROTECTED]
In fact, we do
I trimmed the CC list a bit, it was getting large. I just left
linux-kernel since I believe everyone is on that list.
} It's this critical mass which is missing; otherwise, my custom scripts
} which use RCS and where I only check in those files which I modify are
} quite frankly, more
} Second, I doubt very much that Linus would require BitKeeper only. It's
} trivial for BK to export patches which are bit for bit identical to the
} traditional "diff -Nur" output. BKweb does that on the fly, go look at
}
} http://www.bitmover.com:[EMAIL PROTECTED]
In fact, we do
} > Cort Dougan recently announced he was no longer going to be maintaining
} > the PowerPC Linux tree.
What I'd said was I'm taking a vacation from maintaining the PPC-tree for a
while so I can do some of my real job. I'm not abandoning it in any way -
just spending less time on it for a
} Can somebody please tell me, who is currently maintaining
} arch/ppc?
}
} The link
}
} http://www.ppc.kernel.org/
}
} in the MAINTAINERS file is dead.
}
} Regards, Till
It's unmaintained right now. The www.ppc.kernel.org site is gone.
Take a look at www.fsmlabs.com/linuxppcbk.html for the
} Can somebody please tell me, who is currently maintaining
} arch/ppc?
}
} The link
}
} http://www.ppc.kernel.org/
}
} in the MAINTAINERS file is dead.
}
} Regards, Till
It's unmaintained right now. The www.ppc.kernel.org site is gone.
Take a look at www.fsmlabs.com/linuxppcbk.html for the
74 matches
Mail list logo
