]
Signed-off-by: Kyle McMartin [EMAIL PROTECTED]
---
diff --git a/drivers/char/sysrq.c b/drivers/char/sysrq.c
index de60e1e..09bb030 100644
--- a/drivers/char/sysrq.c
+++ b/drivers/char/sysrq.c
@@ -159,10 +159,16 @@ static struct sysrq_key_op sysrq_sync_op = {
.enable_mask= SYSRQ_ENABLE_SYNC
On Fri, Dec 21, 2007 at 12:56:09AM -0800, Roland McGrath wrote:
> > On Thu, Dec 20, 2007 at 03:58:16AM -0800, Roland McGrath wrote:
> > > +obj-$(CONFIG_PPC64) += ../../../fs/compat_binfmt_elf.o
> >
> > Building files from another directory is nasty. Please add a
> >
On Fri, Dec 21, 2007 at 12:56:09AM -0800, Roland McGrath wrote:
On Thu, Dec 20, 2007 at 03:58:16AM -0800, Roland McGrath wrote:
+obj-$(CONFIG_PPC64) += ../../../fs/compat_binfmt_elf.o
Building files from another directory is nasty. Please add a
CONFIG_BINFMT_COMPAT_ELF so
On Thu, Dec 20, 2007 at 08:40:54PM -0800, Linus Torvalds wrote:
> That was a rather long-winded explanation of what happened, mainly because
> it was all very unexpected to me, and I had personally mistakenly thought
> the git optimization was perfectly valid and actually had to go through
>
On Thu, Dec 20, 2007 at 07:49:05PM -0800, Linus Torvalds wrote:
>
>
> On Thu, 20 Dec 2007, Kyle McMartin wrote:
> >
> > I think I see the problem, it's lack of context in the diff,
>
> No, the problem is that "git diff" is apparently broken by a recen
Otherwise patch gets horribly confused and falls over applying
the diff. Not sure why these were being defined twice.
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
Well, we can get it fixed for -git1, I respun the patch-2.6.24-rc6 diff
with git diff -p v2.6.23..HEAD and a
On Thu, Dec 20, 2007 at 09:48:05PM -0500, Kyle McMartin wrote:
> 1 out of 3 hunks FAILED -- saving rejects to file
> drivers/video/mbx/reg_bits.h.rej
> error: Bad exit status from /var/tmp/rpm-tmp.22316 (%prep)
>
I think I see the problem, it's lack of context in the d
On Thu, Dec 20, 2007 at 05:41:09PM -0800, Linus Torvalds wrote:
> The regression list keeps shrinking, so we're still on track for a full
> 2.6.24 release in early January. Assuming we don't all overeat during the
> holidays and nobody gets any work done. But we all know that the holidays
> are
On Thu, Dec 20, 2007 at 05:41:09PM -0800, Linus Torvalds wrote:
The regression list keeps shrinking, so we're still on track for a full
2.6.24 release in early January. Assuming we don't all overeat during the
holidays and nobody gets any work done. But we all know that the holidays
are
On Thu, Dec 20, 2007 at 09:48:05PM -0500, Kyle McMartin wrote:
1 out of 3 hunks FAILED -- saving rejects to file
drivers/video/mbx/reg_bits.h.rej
error: Bad exit status from /var/tmp/rpm-tmp.22316 (%prep)
I think I see the problem, it's lack of context in the diff,
commit
Otherwise patch gets horribly confused and falls over applying
the diff. Not sure why these were being defined twice.
Signed-off-by: Kyle McMartin [EMAIL PROTECTED]
---
Well, we can get it fixed for -git1, I respun the patch-2.6.24-rc6 diff
with git diff -p v2.6.23..HEAD and applied
On Thu, Dec 20, 2007 at 07:49:05PM -0800, Linus Torvalds wrote:
On Thu, 20 Dec 2007, Kyle McMartin wrote:
I think I see the problem, it's lack of context in the diff,
No, the problem is that git diff is apparently broken by a recent
optimization. The diff is simply broken
On Thu, Dec 20, 2007 at 08:40:54PM -0800, Linus Torvalds wrote:
That was a rather long-winded explanation of what happened, mainly because
it was all very unexpected to me, and I had personally mistakenly thought
the git optimization was perfectly valid and actually had to go through
the
On Wed, Dec 19, 2007 at 04:54:30PM +1100, David Chinner wrote:
> [ 5667.086055] BUG: sleeping function called from invalid context at
> kernel/fork.c:401
>
The problem is that mmput is called under the read_lock by
find_thread_for_addr... The comment above seems to indicate that gdb
needs to be
On Wed, Dec 19, 2007 at 04:54:30PM +1100, David Chinner wrote:
[ 5667.086055] BUG: sleeping function called from invalid context at
kernel/fork.c:401
The problem is that mmput is called under the read_lock by
find_thread_for_addr... The comment above seems to indicate that gdb
needs to be
On Tue, Dec 18, 2007 at 10:05:45AM +0900, KAMEZAWA Hiroyuki wrote:
> On Thu, 13 Dec 2007 15:03:07 +
>
> > + if (mm != active_mm) {
> > + /* Restore region IDs for mm */
> > + if (mm && active_mm) {
> > + activate_context(mm);
> > +
On Tue, Dec 18, 2007 at 10:05:45AM +0900, KAMEZAWA Hiroyuki wrote:
On Thu, 13 Dec 2007 15:03:07 +
+ if (mm != active_mm) {
+ /* Restore region IDs for mm */
+ if (mm active_mm) {
+ activate_context(mm);
+ }
On Fri, Dec 14, 2007 at 02:56:46PM -0400, Francisco Alecrim wrote:
> Remove duplicated headers in drivers/parisc/ccio-dma.c:
> drivers/parisc/ccio-dma.c: linux/proc_fs.h is included more than once.
>
Seems kind of pointless, but I'll apply it.
cheers, Kyle
--
To unsubscribe from this list: send
On Fri, Dec 14, 2007 at 02:56:46PM -0400, Francisco Alecrim wrote:
Remove duplicated headers in drivers/parisc/ccio-dma.c:
drivers/parisc/ccio-dma.c: linux/proc_fs.h is included more than once.
Seems kind of pointless, but I'll apply it.
cheers, Kyle
--
To unsubscribe from this list: send
On Thu, Dec 13, 2007 at 11:20:44PM +0100, Adrian Bunk wrote:
> Is there anywhere in the kernel a case where __read_mostly brings a
> measurable improvement or can it be removed?
>
Yes, definitely[1]... the problem is, and this is also true of other
annotations[2], that people go absolutely nuts
On Thu, Dec 13, 2007 at 11:20:44PM +0100, Adrian Bunk wrote:
Is there anywhere in the kernel a case where __read_mostly brings a
measurable improvement or can it be removed?
Yes, definitely[1]... the problem is, and this is also true of other
annotations[2], that people go absolutely nuts
On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote:
> asm volatile ("rdtsc": "=A" (tsc));
rdtsc returns a 64-bit value in two 32-bit regs, you need to do
inline unsigned long long rdtsc(void)
{
unsigned int lo, hi;
asm volatile ("rdtsc": "=a" (lo), "=d" (hi));
On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote:
asm volatile (rdtsc: =A (tsc));
rdtsc returns a 64-bit value in two 32-bit regs, you need to do
inline unsigned long long rdtsc(void)
{
unsigned int lo, hi;
asm volatile (rdtsc: =a (lo), =d (hi));
return
On Wed, Nov 28, 2007 at 09:41:24PM +0100, Kai Ruhnau wrote:
> Kyle McMartin wrote:
> > On Sun, Nov 25, 2007 at 01:36:19PM +0100, Kai Ruhnau wrote:
> >
> >> If this is the same like the kernel option 'pci=conf1', that fixes the
> >> vendor IDs.
> >>
On Wed, Nov 28, 2007 at 09:41:24PM +0100, Kai Ruhnau wrote:
Kyle McMartin wrote:
On Sun, Nov 25, 2007 at 01:36:19PM +0100, Kai Ruhnau wrote:
If this is the same like the kernel option 'pci=conf1', that fixes the
vendor IDs.
Same effect. Ubuntu and many other distros
On Thu, Nov 29, 2007 at 12:35:33AM -0800, Andrew Morton wrote:
> ten million is close enough to infinity for me to assume that we broke the
> driver and that's never going to terminate.
>
how about this? doesn't break things on my pa8800:
diff --git a/drivers/scsi/sym53c8xx_2/sym_hipd.c
On Thu, Nov 29, 2007 at 07:09:51PM +0200, Vitaliy Ivanov wrote:
> Hi all,
>
> Can anyone advice whether there is something similar to inotify in 2.4 kernel?
>
> Need efficient way to track file system changes.
>
> Maybe some other tools, approaches under 2.4?
>
dnotify[1]? but it might make
would be accessing on a non-integer multiple
boundary.
Ok, that kind of sucked too. But you get the idea.
>
> Why unaligned access is bad
> ===
>
The rest of this looks good.
Acked-by: Kyle McMartin <[EMAIL PROTECTED]>
cheers,
Kyle
-
To unsub
-integer multiple
boundary.
Ok, that kind of sucked too. But you get the idea.
Why unaligned access is bad
===
The rest of this looks good.
Acked-by: Kyle McMartin [EMAIL PROTECTED]
cheers,
Kyle
-
To unsubscribe from this list: send the line unsubscribe
On Thu, Nov 29, 2007 at 07:09:51PM +0200, Vitaliy Ivanov wrote:
Hi all,
Can anyone advice whether there is something similar to inotify in 2.4 kernel?
Need efficient way to track file system changes.
Maybe some other tools, approaches under 2.4?
dnotify[1]? but it might make you cry.
On Thu, Nov 29, 2007 at 12:35:33AM -0800, Andrew Morton wrote:
ten million is close enough to infinity for me to assume that we broke the
driver and that's never going to terminate.
how about this? doesn't break things on my pa8800:
diff --git a/drivers/scsi/sym53c8xx_2/sym_hipd.c
On Tue, Nov 27, 2007 at 03:02:52PM -0800, Greg KH wrote:
> Last updated November 27, 2008
>
The future is now! ;-)
cheers,
Kyle
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Tue, Nov 27, 2007 at 10:26:34AM +0100, Frans Pop wrote:
> v2.6.24-rc3-19-g2ffbb83 fails very early in the boot procedure.
> 2.6.23 compiled with similar config boots fine.
>
> System is running Debian unstable; kernel was compiled using gcc 4.1.2.
>
Ah, I diagnosed this last week. Will post
On Tue, Nov 27, 2007 at 10:26:34AM +0100, Frans Pop wrote:
v2.6.24-rc3-19-g2ffbb83 fails very early in the boot procedure.
2.6.23 compiled with similar config boots fine.
System is running Debian unstable; kernel was compiled using gcc 4.1.2.
Ah, I diagnosed this last week. Will post the
On Tue, Nov 27, 2007 at 03:02:52PM -0800, Greg KH wrote:
Last updated November 27, 2008
The future is now! ;-)
cheers,
Kyle
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Sun, Nov 25, 2007 at 01:36:19PM +0100, Kai Ruhnau wrote:
> If this is the same like the kernel option 'pci=conf1', that fixes the
> vendor IDs.
>
Same effect. Ubuntu and many other distros are shipping kernels with
MMCONFIG off by default for reasons like this. Check to see if you have
an
On Sun, Nov 25, 2007 at 01:36:19PM +0100, Kai Ruhnau wrote:
If this is the same like the kernel option 'pci=conf1', that fixes the
vendor IDs.
Same effect. Ubuntu and many other distros are shipping kernels with
MMCONFIG off by default for reasons like this. Check to see if you have
an
On Wed, Nov 21, 2007 at 05:08:30PM -0800, Al Niessner wrote:
> On with the detailed technical information. I developed a kernel module
> for an PCI card back in 2.4, moved it to 2.6.3, then 2.6.11 or so and
> now I am trying to move it to 2.6.22. When I began the to move to
> 2.6.22, I changed all
On Thu, Nov 22, 2007 at 01:56:25AM +, Alan Cox wrote:
> > status = request_irq (apcsi[i].board_irq,
> > apc8620_handler,
> > IRQF_DISABLED,
>
> You set IRQF_DISABLED
>
> Do you then enable the interrupt anywhere
On Thu, Nov 22, 2007 at 01:56:25AM +, Alan Cox wrote:
status = request_irq (apcsi[i].board_irq,
apc8620_handler,
IRQF_DISABLED,
You set IRQF_DISABLED
Do you then enable the interrupt anywhere later on ?
On Wed, Nov 21, 2007 at 05:08:30PM -0800, Al Niessner wrote:
On with the detailed technical information. I developed a kernel module
for an PCI card back in 2.4, moved it to 2.6.3, then 2.6.11 or so and
now I am trying to move it to 2.6.22. When I began the to move to
2.6.22, I changed all of
On Tue, Nov 13, 2007 at 07:23:46PM -0500, Kyle McMartin wrote:
> On Wed, Nov 14, 2007 at 12:18:42AM +, David Howells wrote:
> > Mark arches that support A.OUT format by including the following in their
> > master Kconfig files:
> >
> > config ARCH_SUPPORTS_AOUT
PROTECTED]>
>
big Acked-by: Kyle McMartin <[EMAIL PROTECTED]> to the whole set
arch-dependant set...
Thanks, Kyle
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kern
On Wed, Nov 14, 2007 at 12:18:42AM +, David Howells wrote:
Mark arches that support A.OUT format by including the following in their
master Kconfig files:
config ARCH_SUPPORTS_AOUT
def_bool y
...
Signed-off-by: David Howells [EMAIL PROTECTED]
big Acked-by: Kyle
On Tue, Nov 13, 2007 at 07:23:46PM -0500, Kyle McMartin wrote:
On Wed, Nov 14, 2007 at 12:18:42AM +, David Howells wrote:
Mark arches that support A.OUT format by including the following in their
master Kconfig files:
config ARCH_SUPPORTS_AOUT
def_bool y
On Mon, Nov 12, 2007 at 05:58:08PM +0200, Yoav Artzi wrote:
> Looking at the source, I see:
>
> #ifdef CONFIG_4KSTACKS
> #define THREAD_SIZE(4096)
> #else
> #define THREAD_SIZE(8192)
> #endif
>
>
> So if I configure the option CONFIG_4KSTACK, I will get a 4KB kernel
>
On Mon, Nov 12, 2007 at 05:58:08PM +0200, Yoav Artzi wrote:
Looking at the source, I see:
#ifdef CONFIG_4KSTACKS
#define THREAD_SIZE(4096)
#else
#define THREAD_SIZE(8192)
#endif
So if I configure the option CONFIG_4KSTACK, I will get a 4KB kernel
stack. Am I
On Mon, Oct 29, 2007 at 08:10:10AM +, Russell King wrote:
> On Sun, Oct 28, 2007 at 04:15:49PM -0400, Kyle McMartin wrote:
> > To quote lolcats: CONFIG_RESOURCES_64BIT DO NOT WANT!
> >
> > I *think* I have the logic of this right... Anyway, I was annoyed by
> > h
On Sun, Oct 28, 2007 at 06:09:49PM -0700, David Miller wrote:
> From: Kyle McMartin <[EMAIL PROTECTED]>
> Date: Sun, 28 Oct 2007 16:15:49 -0400
>
> > To quote lolcats: CONFIG_RESOURCES_64BIT DO NOT WANT!
> >
> > I *think* I have the logic of this right... An
On Sun, Oct 28, 2007 at 06:09:49PM -0700, David Miller wrote:
From: Kyle McMartin [EMAIL PROTECTED]
Date: Sun, 28 Oct 2007 16:15:49 -0400
To quote lolcats: CONFIG_RESOURCES_64BIT DO NOT WANT!
I *think* I have the logic of this right... Anyway, I was annoyed by
having to do the bloody
On Mon, Oct 29, 2007 at 08:10:10AM +, Russell King wrote:
On Sun, Oct 28, 2007 at 04:15:49PM -0400, Kyle McMartin wrote:
To quote lolcats: CONFIG_RESOURCES_64BIT DO NOT WANT!
I *think* I have the logic of this right... Anyway, I was annoyed by
having to do the bloody ugly casts
PPC and MIPS embedded boards.
For everyone else, it should be whatever the value of 64BIT is.
And I can be happy and continue using unsigned long and going about my
merry business.
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
diff --git a/mm/Kconfig b/mm/Kconfig
index c070ec0..c
PPC and MIPS embedded boards.
For everyone else, it should be whatever the value of 64BIT is.
And I can be happy and continue using unsigned long and going about my
merry business.
Signed-off-by: Kyle McMartin [EMAIL PROTECTED]
---
diff --git a/mm/Kconfig b/mm/Kconfig
index c070ec0..c25a838
On Tue, Oct 23, 2007 at 09:30:35AM +0200, Jens Axboe wrote:
> > arch/parisc/kernel/pci-dma.c:545: error: 'struct scatterlist' has no member
> > named 'page'
>
> Applied.
>
Thanks!
Cheers,
Kyle
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Tue, Oct 23, 2007 at 09:30:35AM +0200, Jens Axboe wrote:
arch/parisc/kernel/pci-dma.c:545: error: 'struct scatterlist' has no member
named 'page'
Applied.
Thanks!
Cheers,
Kyle
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Fri, Oct 12, 2007 at 11:23:39AM +1000, Paul Mackerras wrote:
> Olof Johansson writes:
>
> > Not using the ppc-specific WARN_ON/BUG_ON constructs actually saves about
> > 4K text on a ppc64_defconfig. The main reason seems to be that prepping
> > the arguments to the conditional trap
On Thu, Oct 11, 2007 at 12:12:11PM -0500, Olof Johansson wrote:
> HAVE_ARCH_WARN is used to determine if an arch already has a __WARN()
> macro, or if a generic one is needed.
>
> With this, some of the arch-specific WARN_ON() implementations can be
> made common instead (see follow-up patch for
On Thu, Oct 11, 2007 at 12:12:11PM -0500, Olof Johansson wrote:
HAVE_ARCH_WARN is used to determine if an arch already has a __WARN()
macro, or if a generic one is needed.
With this, some of the arch-specific WARN_ON() implementations can be
made common instead (see follow-up patch for
On Fri, Oct 12, 2007 at 11:23:39AM +1000, Paul Mackerras wrote:
Olof Johansson writes:
Not using the ppc-specific WARN_ON/BUG_ON constructs actually saves about
4K text on a ppc64_defconfig. The main reason seems to be that prepping
the arguments to the conditional trap instructions is
On Wed, Oct 10, 2007 at 08:38:58PM +0200, Sam Ravnborg wrote:
> parisc arch Makefile needs some love and care...
>
It basically hasn't been touched since 2.4, I already have a patch to
clean up a lot of things when Randy pointed it out a while ago. Thanks
for the reminder, I'll queue it for
On Wed, Oct 10, 2007 at 08:38:58PM +0200, Sam Ravnborg wrote:
parisc arch Makefile needs some love and care...
It basically hasn't been touched since 2.4, I already have a patch to
clean up a lot of things when Randy pointed it out a while ago. Thanks
for the reminder, I'll queue it for
This reverts commit f443675affe3f16dd428e46f0f7fd3f4d703eeab, which
breaks horribly if you aren't running an unreleased xf86-video-intel
driver out of git.
Conflicts:
drivers/char/agp/intel-agp.c
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
drivers/char/agp/intel-agp.c
On Sat, Oct 06, 2007 at 12:42:21AM -0400, Kyle McMartin wrote:
> commit f443675affe3f16dd428e46f0f7fd3f4d703eeab
> intel_agp: fix stolen mem range on G33
> G33 GTT stolen memory is below graphics data stolen memory and be
> seperate,
> so don't subtract it in stol
On Fri, Oct 05, 2007 at 08:20:01PM -0400, Matthew Reppert wrote:
> It works fine in the Ubuntu kernels (pre 2.6.22-13) and in mainline through
> 2.6.23-rc6; since 2.6.23-rc7 (and Ubuntu 2.6.22-13), the X server won't
> start up, and I get this at the end of my Xorg.log:
>
AOL. And I was in the
On Fri, Oct 05, 2007 at 08:20:01PM -0400, Matthew Reppert wrote:
It works fine in the Ubuntu kernels (pre 2.6.22-13) and in mainline through
2.6.23-rc6; since 2.6.23-rc7 (and Ubuntu 2.6.22-13), the X server won't
start up, and I get this at the end of my Xorg.log:
AOL. And I was in the
On Sat, Oct 06, 2007 at 12:42:21AM -0400, Kyle McMartin wrote:
commit f443675affe3f16dd428e46f0f7fd3f4d703eeab
intel_agp: fix stolen mem range on G33
G33 GTT stolen memory is below graphics data stolen memory and be
seperate,
so don't subtract it in stolen mem counting
This reverts commit f443675affe3f16dd428e46f0f7fd3f4d703eeab, which
breaks horribly if you aren't running an unreleased xf86-video-intel
driver out of git.
Conflicts:
drivers/char/agp/intel-agp.c
Signed-off-by: Kyle McMartin [EMAIL PROTECTED]
---
drivers/char/agp/intel-agp.c |5
On Fri, Sep 28, 2007 at 08:01:31PM -0400, Kyle McMartin wrote:
> I checked powerpc, sparc, and mips, which are (besides parisc) the only
> 64-bit with 32-bit userspace big endian architectures that I could think
> of offhand. A quick grep shows sh64 too... Paul?
>
Ah, no CONFIG_CO
On Sat, Sep 29, 2007 at 01:38:23AM +0200, Arnd Bergmann wrote:
> 1. Byte order matches the order in which 64 bit arguments are split
>in system call conventions on all platforms.
I checked powerpc, sparc, and mips, which are (besides parisc) the only
64-bit with 32-bit userspace big endian
Basically everyone is using the same sys32_fallocate. Delete a whole bunch of
archdep code and move the compat wrapper to fs/compat.c
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
arch/mips/kernel/linux32.c|7 ---
arch/mips/kernel/scall64-o32.S|2 +-
arch/p
To be used when endianness matters for argument ordering when reassembling
a 64-bit value out of two register halves.
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
include/linux/compat.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/include
On Sat, Sep 29, 2007 at 07:06:10AM +0200, Heiko Carstens wrote:
>
> These are not identical... the least and most significant parts seem to get
> passed in a different way on little and big endian machines.
> Maybe it would be worth to have something like compat_merge_64() which does
> the right
On Fri, Sep 28, 2007 at 09:01:37PM +0200, Arnd Bergmann wrote:
>
> This code assumes little-endian register ordering for 64 bit
> arguments. AFAICS, this is wrong at aleast on mipseb and powerpc.
>
Yeah, you're right. I've an idea for how to fix this, will update patch
soon.
Cheers,
Basically everyone is using the same sys32_fallocate. Delete a whole bunch of
archdep code and move the compat wrapper to fs/compat.c
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
NOTE: Patch hunk in scall64-o32.S depends on a patch going in through
Ralf's linux-mips tree.
---
arc
Basically everyone is using the same sys32_fallocate. Delete a whole bunch of
archdep code and move the compat wrapper to fs/compat.c
Signed-off-by: Kyle McMartin [EMAIL PROTECTED]
---
NOTE: Patch hunk in scall64-o32.S depends on a patch going in through
Ralf's linux-mips tree.
---
arch/mips
On Fri, Sep 28, 2007 at 09:01:37PM +0200, Arnd Bergmann wrote:
This code assumes little-endian register ordering for 64 bit
arguments. AFAICS, this is wrong at aleast on mipseb and powerpc.
Yeah, you're right. I've an idea for how to fix this, will update patch
soon.
Cheers,
Kyle
-
On Sat, Sep 29, 2007 at 07:06:10AM +0200, Heiko Carstens wrote:
These are not identical... the least and most significant parts seem to get
passed in a different way on little and big endian machines.
Maybe it would be worth to have something like compat_merge_64() which does
the right
To be used when endianness matters for argument ordering when reassembling
a 64-bit value out of two register halves.
Signed-off-by: Kyle McMartin [EMAIL PROTECTED]
---
include/linux/compat.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/include/linux/compat.h
Basically everyone is using the same sys32_fallocate. Delete a whole bunch of
archdep code and move the compat wrapper to fs/compat.c
Signed-off-by: Kyle McMartin [EMAIL PROTECTED]
---
arch/mips/kernel/linux32.c|7 ---
arch/mips/kernel/scall64-o32.S|2 +-
arch/powerpc
On Sat, Sep 29, 2007 at 01:38:23AM +0200, Arnd Bergmann wrote:
1. Byte order matches the order in which 64 bit arguments are split
in system call conventions on all platforms.
I checked powerpc, sparc, and mips, which are (besides parisc) the only
64-bit with 32-bit userspace big endian
On Fri, Sep 28, 2007 at 08:01:31PM -0400, Kyle McMartin wrote:
I checked powerpc, sparc, and mips, which are (besides parisc) the only
64-bit with 32-bit userspace big endian architectures that I could think
of offhand. A quick grep shows sh64 too... Paul?
Ah, no CONFIG_COMPAT on sh64
On Thu, Sep 13, 2007 at 02:03:46AM -0700, Andrew Morton wrote:
> I suspect the fix we want is:
>
ack. The trend seems to be to avoid this redundant check in the
interrupt handler.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Thu, Sep 13, 2007 at 02:03:46AM -0700, Andrew Morton wrote:
I suspect the fix we want is:
ack. The trend seems to be to avoid this redundant check in the
interrupt handler.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
On Tue, Aug 21, 2007 at 06:54:53PM +0100, Russell King wrote:
> I want to keep support for gcc 3.4.3 for ARM for the forseeable future.
> From my point of view, gcc 4 compilers have been something of a development
> thing as far as the ARM architecture goes. Also, gcc 3.4.3 is faster and
>
On Tue, Aug 21, 2007 at 06:54:53PM +0100, Russell King wrote:
I want to keep support for gcc 3.4.3 for ARM for the forseeable future.
From my point of view, gcc 4 compilers have been something of a development
thing as far as the ARM architecture goes. Also, gcc 3.4.3 is faster and
On Thu, Aug 09, 2007 at 10:01:54AM -0400, Chris Snook wrote:
> From: Chris Snook <[EMAIL PROTECTED]>
>
> Purify volatile use for atomic[64]_t on parisc.
>
> Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
>
Sure, why not.
ACKed-by: Kyle McMartin <[EMAIL
On Thu, Aug 09, 2007 at 10:01:54AM -0400, Chris Snook wrote:
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic[64]_t on parisc.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
Sure, why not.
ACKed-by: Kyle McMartin [EMAIL PROTECTED]
-
To unsubscribe from this list: send
On Mon, Aug 06, 2007 at 12:52:36PM +0200, Jan Engelhardt wrote:
>CPU0
> 0:282 IO-APIC-edge timer
Look at the LOC line.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Mon, Aug 06, 2007 at 12:52:36PM +0200, Jan Engelhardt wrote:
CPU0
0:282 IO-APIC-edge timer
Look at the LOC line.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Sat, Aug 04, 2007 at 08:32:12PM +0200, Jesper Juhl wrote:
> I don't think dev_id can ever actually be NULL, so the whole block
> inside "if (!dev) {" could probably just go away. But I guess
> there's a good reason someone put that ULI526X_DBUG() in there - and
> if 'dev_id' /can/ actually be
On Sat, Aug 04, 2007 at 08:32:12PM +0200, Jesper Juhl wrote:
I don't think dev_id can ever actually be NULL, so the whole block
inside if (!dev) { could probably just go away. But I guess
there's a good reason someone put that ULI526X_DBUG() in there - and
if 'dev_id' /can/ actually be NULL
On Mon, Jul 30, 2007 at 10:40:59PM -0500, Joseph Pingenot wrote:
> From Al Viro on Tuesday, 31 July, 2007:
> >On Mon, Jul 30, 2007 at 10:31:13PM -0500, Joseph Pingenot wrote:
> >> >From Joseph Pingenot on Monday, 30 July, 2007:
> >> >From Al Viro on Tuesday, 31 July, 2007:
> >> >>On Mon, Jul 30,
On Mon, Jul 30, 2007 at 01:04:13PM -0600, Valerie Henson wrote:
> The Tulip network driver needs a new maintainer! I no longer have
> time to maintain the Tulip network driver and I'm stepping down. Jeff
> Garzik would be happy to get volunteers.
>
Since I already take care of a major consumer
On Mon, Jul 30, 2007 at 01:04:13PM -0600, Valerie Henson wrote:
The Tulip network driver needs a new maintainer! I no longer have
time to maintain the Tulip network driver and I'm stepping down. Jeff
Garzik would be happy to get volunteers.
Since I already take care of a major consumer of
On Mon, Jul 30, 2007 at 10:40:59PM -0500, Joseph Pingenot wrote:
From Al Viro on Tuesday, 31 July, 2007:
On Mon, Jul 30, 2007 at 10:31:13PM -0500, Joseph Pingenot wrote:
From Joseph Pingenot on Monday, 30 July, 2007:
From Al Viro on Tuesday, 31 July, 2007:
On Mon, Jul 30, 2007 at
On Fri, Jun 29, 2007 at 02:19:59PM +0200, Heiko Carstens wrote:
> - tt = report_bug(regs->iaoq[0] & ~3);
> + tt = report_bug(regs->iaoq[0] & ~3, regs);
Groovy, I'll try to test this over the weekend.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Fri, Jun 29, 2007 at 02:19:59PM +0200, Heiko Carstens wrote:
- tt = report_bug(regs-iaoq[0] ~3);
+ tt = report_bug(regs-iaoq[0] ~3, regs);
Groovy, I'll try to test this over the weekend.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On Fri, Jun 29, 2007 at 01:03:06PM +0800, ye janboe wrote:
> if (get_user_pages(current, current->mm, addr, 1, 0,
> 1,
> , ) <= 0) {
> DUMP_SEEK(PAGE_SIZE);
>
On Fri, Jun 29, 2007 at 09:31:44AM +1000, Con Kolivas wrote:
> This is a Q6600 which has cache size of 8 MB. Unless it's reporting each
> half's effective L2, I think it should be reporting 8192 instead of 4096.
>
Each pair of cores appears to get 4MB of L2, according to the product
brief PDF
On Thu, Jun 28, 2007 at 03:05:56PM -0700, Joshua Wise wrote:
> --- a/arch/x86_64/kernel/process.c
> +++ b/arch/x86_64/kernel/process.c
> @@ -356,6 +356,7 @@ void show_regs(struct pt_regs *regs)
> printk("CPU %d:", smp_processor_id());
> __show_regs(regs);
> show_trace(NULL, regs,
201 - 300 of 403 matches
Mail list logo
