On Tue, Nov 27, 2012 at 12:16:31PM +, Mark Rutland wrote:
> Signed-off-by: Mark Rutland
> Cc: Arnaldo Carvalho de Melo
> Cc: David Howells
> Cc: Deng-Cheng Zhu
> Cc: Ingo Molnar
> Cc: Kyle McMartin
Looks obviously right.
Acked-by: Kyle McMartin
> Cc: Martin Sc
the other cases.
Checking in crypto_check_alg and crypto_register_template seems to hit
the callpoints as far as I can see.
Signed-off-by: Kyle McMartin
---
rusty,
How about something like this? It keeps the FIPS mess in the
crypto/fips.c file (aside from something that goes away entirely in
On Wed, Feb 06, 2013 at 09:02:46AM +0100, Stephan Mueller wrote:
> On 05.02.2013 23:58:30, +0100, Kyle McMartin wrote:
>
> Hi Kyle,
>
Thanks for the review, Stephan.
> Just reading this paragraph, there is one missing puzzle piece: the
> *entire* kernel crypto API must shut
On Wed, Feb 06, 2013 at 06:45:45PM +0100, Stephan Mueller wrote:
> Unfortunately there has already something terrible happened: an
> additional piece of code loaded into the FIPS 140-2 module could not be
> loaded because a self test failed. This is a terrible accident in FIPS
> 140-2 speak. :-)
>
On Wed, Jan 23, 2013 at 04:18:32PM +0100, Stephan Mueller wrote:
> 3. in the cipher initialization code of the crypto API (i.e. the one
> behind crypto_register_alg()), you check the signature check flag --
> panic the kernel when the flag shows that the signature check failed
>
> This way you lim
e they exist in-tree...
Seems to build and work with both values of CONFIG_CRYPTO_FIPS.
Thoughts?
Signed-off-by: Kyle McMartin
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2459,8 +2459,10 @@ static int module_sig_check(struct load_info *info)
return 0;
}
-
On Thu, Jan 24, 2013 at 02:06:10PM -0500, Kyle McMartin wrote:
> + if (err < 0 && fips_enabled && !get_modinfo(info, "crypto_fips"))
Sigh, that should be get_modinfo(...)
if (err < 0 && fips_enabled && get_modinfo(info, "crypto
CONFIG_EXPERT doesn't really make sense, and hides it unintentionally.
Remove superfluous "default n" pointed out by Ingo as well.
Signed-off-by: Kyle McMartin
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -243,8 +243,7 @@ config BOOTPARAM_SOFTLOCKUP_PANIC_VALUE
On Fri, Jan 25, 2013 at 10:06:01AM +1030, Rusty Russell wrote:
> Kyle McMartin writes:
> > After thinking about it a while, this seems like the best way to solve
> > the problem, although it does still kind of offend my delicate
> > sensibilities...
>
> You're
On Mon, Feb 11, 2008 at 05:23:33PM +0100, Roel Kluin wrote:
>
How about just doing something like this:
diff --git a/arch/parisc/kernel/pci-dma.c b/arch/parisc/kernel/pci-dma.c
index 9448d4e..63f9b7f 100644
--- a/arch/parisc/kernel/pci-dma.c
+++ b/arch/parisc/kernel/pci-dma.c
@@ -409,7 +409,7 @@
On Mon, Feb 11, 2008 at 07:56:10PM +0100, Roel Kluin wrote:
> +/*
> + * dma_alloc_noncoherent is a fallback for boxes PA7200 and below which
> + * cannot allocate coherent memory.
> + */
> static void *pa11_dma_alloc_noncoherent(struct device *dev, size_t size,
>
On Wed, Feb 13, 2008 at 07:49:12AM +0100, rubisher wrote:
> --- include/asm-parisc/pgtable.h.Orig 2007-10-22 08:19:20.0 +
> +++ include/asm-parisc/pgtable.h 2008-02-12 16:28:36.0 +
> +extern void *vmalloc_start;
> +#define PCXL_DMA_MAP_SIZE (8*1024*1024)
> +#define V
On Wed, Feb 13, 2008 at 01:42:10PM +0100, rubisher wrote:
> - some lake of changes of kset to kobj:
thanks, i don't build this driver, somehow it made its way out of my
configs. patch looks correct though. applied.
> --- ./drivers/parisc/pdc_stable.c.Orig2008-01-28 07:09:26.0
From: Kyle McMartin
MAP_32BIT is defined only on x86... this means perf fails to build on
all other platforms.
Signed-off-by: Kyle McMartin
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -100,7 +100,9 @@ static size_t syscall_arg__scnprintf_mmap_flags(char *bf,
size_t
On Thu, Sep 05, 2013 at 09:01:59AM -0700, James Bottomley wrote:
> > +EXPORT_SYMBOL_GPL(flush_cache_page);
>
> This is an internal API: no architecture exports this. Whoever is
> trying to use it needs to use the correct API, so this is the wrong
> patch.
>
I suspect it's copy_{to,from}_user_pa
On Fri, Sep 06, 2013 at 10:24:13AM -0400, Steven Rostedt wrote:
>
> Is it really safe to load modules that were compiled with different
> options?
Certainly not, offsets can change based on config options.
> Sounds like a failure in the install scripts to me.
>
Definitely a bug in those script
On Fri, Sep 06, 2013 at 07:51:18PM +0200, Frantisek Hrbata wrote:
> > > v2: - reuse mod->ctors for .init_array section for modules, because gcc
> > > uses
> > > .ctors or .init_array, but not both at the same time
> > >
> > > Signed-off-by: Frantisek Hrbata
> >
> > Might be nice to documen
On Mon, Sep 09, 2013 at 06:28:14PM +0200, Frantisek Hrbata wrote:
> I'm not sure if coexistence of .ctors and .init_array sections should result
> in
> denial of module, but I for sure know nothing about this :). Could you maybe
> privide one example of the "weird thing"?
>
They shouldn't exist
Provide a vdso_install target in the arm64 Makefile, as other architectures
with a vdso do.
Signed-off-by: Kyle McMartin
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -60,6 +60,10 @@ zinstall install: vmlinux
dtbs: scripts
$(Q)$(MAKE) $(build)=$(boot)/dts dtbs
+PHONY
/sh: Argument list too long
make[2]: ***
[/home/kyle/A(lots of times)/linux/usr/include/linux/.install]
Error 127
make[1]: *** [linux] Error 2
make: *** [headers_install] Error 2
Signed-off-by: Kyle McMartin
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -59,6 +59,8
On Thu, Jun 06, 2013 at 07:41:57PM +0200, Michal Marek wrote:
> Dne 6.6.2013 19:05, Kyle McMartin napsal(a):
> > While using make V=1 to test some things, I noticed on our builders that
> > headers_install was failing because the argument list to /bin/sh was too
> > long.
fixed in size by palo,
initialized to zero, and length checked in the bootloader. It's also
only 256+4 bytes compared to the 1024 bytes set aside for
boot_command_line.
That said, it's harmless to use strlcpy here, and obviously (more)
correct. Thanks!
Acked-by: Kyle McMartin
--
in order to bisect across it.
Please revert, we can work on solving this for ARM platforms in a less
disruptive way.
Signed-off-by: Kyle McMartin
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -2755,7 +2755,7 @@ static void __init serial8250_isa_init_ports
On Mon, Jun 03, 2013 at 09:55:31AM -0700, Greg KH wrote:
> On Mon, Jun 03, 2013 at 09:38:26AM -0400, Kyle McMartin wrote:
> > This reverts commit cfcec52e9781f08948c6eb98198d65c45be75a70.
> >
> > This regresses a longstanding behaviour on X86 systems, which end up with
> &
kcore_vmalloc is in fs/proc/kcore.c and kcore_mem is unused across
the tree. Noticed while grepping the tree for some other kcore stuff.
(score looks pretty unmaintained to me.)
Signed-off-by: Kyle McMartin
--- a/arch/score/mm/init.c
+++ b/arch/score/mm/init.c
@@ -41,8 +41,6 @@
unsigned long
check_unmap+0x407/0x8a0()
Signed-off-by: Kyle McMartin
--- a/drivers/dma/ioat/dma.c
+++ b/drivers/dma/ioat/dma.c
@@ -832,7 +832,17 @@ int ioat_dma_self_test(struct ioatdma_device *device)
}
dma_src = dma_map_single(dev, src, IOAT_TEST_SIZE, DMA_TO_DEVICE);
+ if
On Wed, Mar 27, 2013 at 11:03:26AM -0400, Josh Boyer wrote:
> On Mon, Mar 18, 2013 at 5:32 PM, Matthew Garrett
> wrote:
> > Any hardware that can potentially generate DMA has to be locked down from
> > userspace in order to avoid it being possible for an attacker to cause
> > arbitrary kernel beha
htmldocs will fail, because device-drivers.tmpl references the
non-existant file 8250.c (which got renamed to 8250_core.c)
Signed-off-by: Kyle McMartin
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -227,7 +227,7 @@ X!Isound/sound_firmware.c
On Wed, Feb 13, 2008 at 01:42:10PM +0100, rubisher wrote:
>
Can I get your Signed-off-by for this, Joel? (I assume you are Joel :)
cheers, Kyle
> - some lake of changes of kset to kobj:
> --- ./drivers/parisc/pdc_stable.c.Orig2008-01-28 07:09:26.0
> +
> +++ ./drivers/par
On Mon, Feb 18, 2008 at 11:32:58AM +0100, rubisher wrote:
> > On Wed, Feb 13, 2008 at 01:42:10PM +0100, rubisher wrote:
> > >
> >
> > Can I get your Signed-off-by for this, Joel? (I assume you are Joel :)
> >
> Yes the previous account seems to be a bit old and look more and more like a
> gc; I s
lguest uses asm-offsets to generate ... offsets, obviously, for use
in the lguest switcher code. When the hypervisor code is built as a
module though, the asm offsets it needs won't be generated since
CONFIG_LGUEST will be undefined.
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
On Wed, Feb 20, 2008 at 02:25:02PM -0800, [EMAIL PROTECTED] wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> Subject: PCI: remove parisc consumer of the pci global_list
>
Thanks for finding this, both of you. Probably saves me some heartaches
for 2.6.26-r
On Fri, Feb 08, 2008 at 01:12:32AM +0200, Adrian Bunk wrote:
> Commit 9e2779fa281cfda13ac060753d674bbcaa23367e broke parisc:
>
> <-- snip -->
>
> ...
> CC arch/parisc/kernel/asm-offsets.s
> In file included from include/asm/pgtable.h:13,
> from arch/parisc/kernel/asm-off
On Thu, Feb 07, 2008 at 03:33:07PM -0800, Christoph Lameter wrote:
> On Thu, 7 Feb 2008, Kyle McMartin wrote:
>
> > yes, it's in my batch of fixes.
>
> So I do not have to worry about it?
>
haha no. i don't expect people to have to untangle the mess of includes
n fips mode. (This also
matches the behaviour by Red Hat Enterprise Linux 6.)
Things which need to deny module loading such as secure boot already set
sig_enforce, so there's no issue here.
Reported-by: Jan Stancek
Signed-off-by: Kyle McMartin
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -24
CONFIG_EXPERT is a bit silly a place for this, and hides it
unnecessarily. CONFIG_DEBUG_KERNEL makes much more sense.
Signed-off-by: Kyle McMartin
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -243,7 +243,7 @@ config BOOTPARAM_SOFTLOCKUP_PANIC_VALUE
default 1 if
[1] for oss/ad1889.c
which is in our cvs, and will go upstream shortly. oss/ad1889.c
doesn't (and hasn't ever) worked, so it should probably be removed.
Stuart, Randolph, comments?
1. http://cvs.parisc-linux.org/linux-2.6/sound/pci/ad1889.c?rev=1.30&view=markup
Cheers,
--
Kyle McMar
rq-trigger ]
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 = {
On Tue, Jan 08, 2008 at 10:28:04PM +1100, Rusty Russell wrote:
> De-mutex more symbol lookup paths in the module code
>
> Kyle McMartin reports sysrq_timer_list_show() can hit the module
> mutex; these paths don't need to though, since we long ago changed all
> the module
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 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
/conf.c:502: error: (Each undeclared identifier is
reported only once
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
--- a/scripts/kconfig/conf.c2008-01-17 15:45:59.0 -0800
+++ b/scripts/kconfig/conf.c2008-01-18 10:01:54.0 -0800
@@ -3,6 +3,8 @@
* Re
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 mi
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
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-a
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 2.6.2
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 p
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 instruction
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
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 i
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
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 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_COM
ld 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
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 yo
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
b/drive
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 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 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 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 upda
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 t
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 http://vger.kern
fails to check if it actually received a
dev argument though, so if you don't pass a device, we get a nice
segfault.
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
diff -Nur btrfs-progs-0.10/btrfsck.c btrfs-progs-0.10-kyle/btrfsck.c
--- btrfs-progs-0.10/btrfsck.c 2008-01-1
On Tue, Jan 15, 2008 at 06:48:35PM -0800, Harvey Harrison wrote:
> +#ifdef CONFIG_X86_F00F_BUG
> +void do_invalid_op(struct pt_regs *, unsigned long);
> +#endif
> +
> +static int is_f00f_bug(struct pt_regs *regs, unsigned long address)
> +{
> +#ifdef CONFIG_X86_F00F_BUG
> + unsigned long nr;
Y
On Wed, Jan 16, 2008 at 10:15:39PM +0100, Jan Engelhardt wrote:
> parent a9f7faa5fd229a65747f02ab0f2d45ee35856760
> commit
^- did you just make that up? ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Wed, Jan 16, 2008 at 11:57:54PM +0100, Jan Engelhardt wrote:
>
> On Jan 16 2008 17:20, Kyle McMartin wrote:
> >On Wed, Jan 16, 2008 at 10:15:39PM +0100, Jan Engelhardt wrote:
> >> parent a9f7faa5fd229a65747f02ab0f2d45ee35856760
> >> commit
i915_flush_ttm was unconditionally executing a clflush instruction
to (obviously) flush the cache. Instead, check if the cpu supports
clflush, and if not, fall back to calling wbinvd to flush the entire
cache.
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
--- a/drivers/char/drm/i915_bu
On Thu, Jan 17, 2008 at 09:03:17PM -0500, H. Peter Anvin wrote:
> The #ifdef is bogus. If it's required, it should go into
> asm-x86/required_features.h and then cpu_has_clflush is static; otherwise
> it's just plain wrong.
>
I have no objection to making cpu_has_clflush constant on x86_64. The
Hopefully nobody will be stupid enough to implement a cpu without
it. Frankly, it seems safe enough given we already require SSE2.
This means the compiler can optimise away "if (!cpu_has_clflush)"
blocks.
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
include/asm-x86
th lguest & xen paravirt enabled, and
x86_64. Boot tested on x86_64.
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
include/asm-x86/alternative.h| 169 +-
include/asm-x86/alternative_32.h | 154 --
include/asm-x8
On Fri, Jan 18, 2008 at 12:02:05AM -0500, H. Peter Anvin wrote:
>
Meh. Waste of my time, you've already done it, but the patch wasn't on
linux-kernel, so I didn't notice.
--Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED
as constants via the
> REQUIRED_MASK macros.
>
PSE, PGE, XMM, XMM2, and FXSR are defined as required features, and
will be optimized to a constant at compile time. Remove their redundant
definitions.
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
--- a/include/asm-x86/cpufeature
On Fri, Jan 18, 2008 at 06:53:53AM +0100, Andi Kleen wrote:
> One problem that we had in the past is that some simulators
> only implement the absolutely minimum feature set and you
> might have well broken one of these with this.
Yeah, true. Please ignore the patch folks.
cheers, Kyle
--
To unsu
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 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 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 Sat, Mar 05, 2005 at 10:48:00AM -0500, Gene Heskett wrote:
> Greetings;
>
> What are the options normally used to generate a diff for public
> consumption on this list?
>
> The - stuffs is what I'm looking for.
>
linux/Documentation/SubmittingPatches
-
To unsubscribe from this list: s
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.
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.kernel.
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
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
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... Anywa
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 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 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 http:/
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 PROTE
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 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, 20
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 me
On Tue, Jan 23, 2007 at 10:15:33PM +0800, Yu-Chen Wu wrote:
> printk(KERN_INFO "vmalloc_to_page tpage :%x\n",tpage);
> //===info of dmesg==
> [ 1561.768492] page allocated:60ea9000
> [ 1561.768497] vmalloc_to_page tpage :7fcf7e18
>
> Why the page address get from vmalloc_t
On Thu, Jan 25, 2007 at 12:56:30PM +, Seetharam Dharmosoth wrote:
> Hi,
>
> Want to remove DMA zone the from the Linux Kernel.
> (Don't want to use DMA Zone, because i am not
> using ISA bus, am using PCI bus. So, I don't need
> this)
>
Just because you don't need ISA, doesn't mean you don't
er/set_register
[PARISC] fix section mismatch warnings in harmony sound driver
Kyle McMartin (20):
[PARISC] Unbreak discontigmem mem_init()
[PARISC] Reserve 1GB of space for vmalloc/tmpalias space on parisc64
[PARISC] bloody printf fmt string warnings
[PARISC] Rem
On Fri, Feb 23, 2007 at 07:13:32AM +0100, Heiko Carstens wrote:
> How about this for telling that an architecture doesn't support DMA?
> At least we could get rid of dma-mapping-broken.h and don't need to
> compile some afterwards dead code.
>
> Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
T
On Sat, Feb 24, 2007 at 05:34:15AM -0500, Robert P. J. Day wrote:
>
> just noticed that parisc's ioctl.h file, rather than simply
> including asm-generic/ioctl.h, has its own copy whose sole
> (meaningful) difference from the generic one is:
>
> $ diff include/{asm-generic,asm-parisc}/ioctl.h
>
On Mon, Feb 26, 2007 at 06:36:05PM +0300, Alexey Zaytsev wrote:
> Hello.
>
> May I ask you, guys, if ioread32 and his friends should treat the data
> as host-endian or bus-endian? E.g, should the data read from PCI on a
> big-endian host be byte swapped or not?
>
It should be in bus-endian. This
perhaps gcc can be extended such that a string of allowable qualifiers
can be passed along in kernel.h, that would just be super...)
This is mostly just to provoke a little bit of further discussion.
Signed-off-by-but-not-really-much-point: Kyle McMartin
<[EMAIL PROTECTED]>
--
On Tue, Feb 27, 2007 at 12:02:50PM +0100, Geert Uytterhoeven wrote:
> But we don't run sparse on every build. We do run gcc (a lot).
>
We probably could, in theory...
> > --- a/lib/vsprintf.c
> > +++ b/lib/vsprintf.c
> > @@ -477,6 +478,8 @@ int vsnprintf(char *buf, size_t size, const char *fmt,
On Tue, Feb 27, 2007 at 03:31:20PM +0300, Alexey Zaytsev wrote:
> Than how should one write a portable endian-independent driver? Should
> I wrap ioread32 with an le32_to_cpu?
>
PCI is always little endian, unless it's not. In which case you're probably
dealing with a graphics card which likely h
On Tue, Feb 27, 2007 at 08:20:21AM -0500, Kyle McMartin wrote:
> PCI is always little endian, unless it's not. In which case you're probably
> dealing with a graphics card which likely has some kind of palindromic
> register which you can read and write to set the end
1 - 100 of 202 matches
Mail list logo
