Hi Linus,
Please consider pulling from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
or
master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus
to receive updates for input subsystem. Note that the bulk of changes to
input.h are just
On Thu, 28 Jun 2007 22:37:34 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Thu, 28 Jun 2007 22:24:24 -0700
>
> > So what happens when two quite different threads of control are doing
> > IO against two hunks of kmalloced memory which happen
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Thu, 28 Jun 2007 22:24:24 -0700
> So what happens when two quite different threads of control are doing
> IO against two hunks of kmalloced memory which happen to come from the same
> page? Either some (kernel-wide) locking is needed, or that
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);
>
Paul Mackerras wrote:
No, it's because the bootwrapper is not part of the kernel and does
not use kernel headers. The aim is that the bootwrapper can be built
and used outside the kernel source tree, so it needs its own copies of
any headers that aren't in /usr/include.
Hm, I see. But is
Paul Mackerras wrote:
===
--- a/arch/powerpc/platforms/cell/io-workarounds.c
+++ b/arch/powerpc/platforms/cell/io-workarounds.c
@@ -9,6 +9,7 @@
#undef DEBUG
#include
+#include
Why is this needed? You've added #include
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Casey Schaufler wrote:
>> Would there be a difference between that and setting either fI or fP
>> (depending on your intent) to those caps, and setting fE=1 in Andrew's
>> scheme?
>
> Arg, you're making me think. The POSIX group went through this,
>
On Thu, 28 Jun 2007 22:06:06 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote:
> From: Christoph Lameter <[EMAIL PROTECTED]>
> Date: Thu, 28 Jun 2007 21:39:01 -0700 (PDT)
>
> > H... Maybe we are creating more of a mess with this. Isnt there some
> > other way to handle these object.
>
>
On 6/28/07, DervishD <[EMAIL PROTECTED]> wrote:
I have a new card reader (internal) but I've tested with my old one
too: the same happens. I have a do-it-yourself linux box, self compiled
kernel 2.6.19.5 (by now).
When I insert a card in the reader, it is not detected, no udev
event is
On Thu, 28 Jun 2007, Kyle Moffett wrote:
> On Jun 28, 2007, at 14:49:24, Davide Libenzi wrote:
> > I was using oprofile to sample some userspace code I am working on, and I
> > was continuosly noticing clear_page in the top three entries of the
> > oprofile logs.
> >
> > Also, a simple kernel
Please pull from 'for_linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for_linus
to receive the following updates:
drivers/net/gianfar.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Kumar Gala (1):
gianfar: Fix typo bug introduced by
On 6/28/07, Rik van Riel <[EMAIL PROTECTED]> wrote:
That wants MAP_PRIVATE so that the kernel can also decide to not
swap these pages out to an unencrypted swap area.
That's not what MAP_PRIVATE means. MAP_PRIVATE is the opposite of
MAP_SHARED. It's meaningless for anonymous memory (which is
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Thu, 28 Jun 2007 21:39:01 -0700 (PDT)
> H... Maybe we are creating more of a mess with this. Isnt there some
> other way to handle these object.
That's where I was going with the silly idea to use another
allocator :)
Really, it would be
Hi Henrique,
On Wednesday 06 June 2007 12:55, Henrique de Moraes Holschuh wrote:
> We have most of the pieces needed to have sane, generic userland keyboard
> handling in place for a while now, but it is not sufficiently documented.
>
> This patch documents the requirements and best practices
I found there are codes like following in elf_core_dump
for (addr = vma->vm_start;
addr < vma->vm_end;
addr += PAGE_SIZE) {
struct page *page;
struct vm_area_struct *vma;
On Fri, Jun 29, 2007 at 12:16:44AM +0200, Rafael J. Wysocki wrote:
> There are two solutions possible, IMO. One would be to make these workqueues
> freezable, which is possible, but hacky and Oleg didn't like that very much.
> The second would be to freeze XFS from within the hibernation code
On Wed, Jun 27, 2007 at 08:49:24PM +, Pavel Machek wrote:
> Hi!
>
> > FWIW, I'm on record stating that "sync" is not sufficient to quiesce an XFS
> > filesystem for a suspend/resume to work safely and have argued that the only
>
> Hmm, so XFS writes to disk even when its threads are frozen?
Jeremy Fitzhardinge writes:
> ===
> --- a/arch/powerpc/platforms/cell/io-workarounds.c
> +++ b/arch/powerpc/platforms/cell/io-workarounds.c
> @@ -9,6 +9,7 @@
> #undef DEBUG
>
> #include
> +#include
Why is this needed? You've
On Thu, 28 Jun 2007, David Miller wrote:
> > You can get such a reference and then the slab page will be in limbo if
> > all objects are freed until that reference is given up. The reference
> > method is also use by kmem_cache_vacate() (but that is slab internal).
>
> What about if someone
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Thu, 28 Jun 2007 21:22:22 -0700 (PDT)
> On Thu, 28 Jun 2007, David Miller wrote:
>
> > > Still a better solution would be to not use the slab allocator at all for
> > > the objects that are used to send commands to the devices. These are not
>
On Thu, 28 Jun 2007, David Miller wrote:
> > Still a better solution would be to not use the slab allocator at all for
> > the objects that are used to send commands to the devices. These are not
> > permanent and grabbing a page from the pcp lists and putting it back is
> > likely as fast as
> Seems that Andi has changed
> ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/cpa-cache-flush so
> hopefully these fixes will not be needed any more..
>
Hrm, actually, something is very wrong with this patch. Please see
comments below.
...
> Index: linux/arch/x86_64/mm/pageattr.c
>
Jeremy Fitzhardinge writes:
> powerpc also appears to have its own duplicate copy of elf.h in
> arch/powerpc/boot/elf.h; presumably because the standard elf.h
> brings in too much. Update it to just linux/elf-defn.h, which
> should be fine.
No, it's because the bootwrapper is not part
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Thu, 28 Jun 2007 21:01:36 -0700 (PDT)
> Modify the functions in the affected arches to check for PageSlab() and
> use a NULL mapping if such a page is encountered. This may only be
> necessary for parisc and arm since sparc64 and xtensa do not
I had a talk with James Bottomley last night and it seems that there is an
established way of using the page structs of slab objects in the block
layer. Drivers may use the DMA interfaces to issue control commands. In
that case they may allocate a short structure via the slab allocator and
put
Hi, Segher,
> > +- #address-cells : Address representation for
> "rapidio" devices.
> > + This field represents the number of cells needed to represent
> > + the RapidIO address of the registers. For
> supporting more than
> > + 32-bits RapidIO address, this field should
On 05/16/2007 09:24 AM, Clemens Schwaighofer wrote:
> Hi,
I had my system running up for about one month without any issues, and
then it happened again, same kernel oops, panic, end.
So I have upgraded to 2.6.22-rc4-mm2 in hope it might fix it, but I just
got another oops (uptime 4d) [see
On Wed, 27 Jun 2007, Roland McGrath wrote:
> I did the first crack at a powerpc port. I'd appreciate your comments on
> this patch. It should not be incorporated, isn't finished, probably breaks
> ptrace, etc. I'm posting it now just to get any thoughts you have raised
> by seeing the second
HI,
As a result of the discussion with Pete Zaitcev([EMAIL PROTECTED]),
I re-create a patch. This attached patch is revised version.
He pointed out that the former patch may violate the assumptions and
was not safe. Concretely speaking, he concerned that an unexpected
problem may arise somewhere
Adrian Bunk wrote:
Adding a dependency of XEN on X86_CMPXCHG should not be a problem and
not prevent any reasonable real-life usage.
But what worries me is that a seemingly architecture independent
driver uses a function only available in some configurations.
Still present as of
On Jun 28, 2007, at 03:20:24, Dave Young wrote:
And for vim trailing space, there's a tip in vim.org:
http://www.vim.org/tips/tip.php?tip_id=878
I actually prefer this (in .vimrc):
" Show trailing whitespace and spaces before tabs
hi link localWhitespaceError Error
au Syntax * syn match
This patch add a watchdog driver interface to rtc-m41t80 driver. This
is derived from works by Alexander Bigga <[EMAIL PROTECTED]>
Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
Signed-off-by: Alexander Bigga <[EMAIL PROTECTED]>
Acked-by: Alessandro Zummo <[EMAIL PROTECTED]>
---
Changes from
This is a new-style i2c driver for ST M41T80 series RTC chip, derived
from works by Alexander Bigga <[EMAIL PROTECTED]> who wrote the original
rtc-m41txx.c based on drivers/i2c/chips/m41t00.c driver.
This driver supports M41T8[0-4] and M41ST8[457]. The old m41t00
driver supports M41T00, M41T81
On Mon, 25 Jun 2007 22:21:42 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Oh the variable should not be static!
> > I will send updated patch.
>
> I'll fix it up.
...
> > Are you going back to "take 1" patches? Why?
>
> Stupidity, apparently. Will restore the take2 patches.
Thanks. I
Kyle Moffett wrote:
On Jun 28, 2007, at 14:49:24, Davide Libenzi wrote:
I was using oprofile to sample some userspace code I am working on,
and I was continuosly noticing clear_page in the top three entries
of the oprofile logs.
Also, a simple kernel build, in my Dual Opteron with 8GB of
On Wed, 27 Jun 2007, Roland McGrath wrote:
> > In theory we should get an exception with both DR_STEP and DR_TRAPn
> > set, meaning that neither notifier will return NOTIFY_STOP. But if the
> > kprobes handler clears DR_STEP in the DR6 image passed to the
> > hw_breakpoint handler, it should
On Jun 28, 2007, at 14:49:24, Davide Libenzi wrote:
I was using oprofile to sample some userspace code I am working on,
and I was continuosly noticing clear_page in the top three
entries of the oprofile logs.
Also, a simple kernel build, in my Dual Opteron with 8GB of RAM,
shows
On 06/29/2007 04:47 AM, Surya Prabhakar N wrote:
Hi emoenke,
Can this patch be verified and pulled into your tree.
You (and he) may not particularly care -- these old drivers are going to be
removed for 2.6.23: http://lkml.org/lkml/2007/6/21/34
Rene.
-
To unsubscribe from this list:
Hi emoenke,
Can this patch be verified and pulled into your tree.
thanks.
Surya.
From: Jesper Juhl <[EMAIL PROTECTED]>
To: Surya <[EMAIL PROTECTED]>
Cc: , Linux Kernel ,
[EMAIL PROTECTED]
Subject: Re: [PATCH]: check_region cleanup in sbpcd.c
Date: Tue, 26 Jun 2007 01:07:41 +0200
On
On Thu, Jun 28, 2007 at 08:20:31AM -0400, Chris Mason wrote:
> On Thu, Jun 28, 2007 at 04:44:43AM +0200, Nick Piggin wrote:
> >
> > That's true but I don't think an extent data structure means we can
> > become too far divorced from the pagecache or the native block size
> > -- what will end up
On Thu, 28 Jun 2007, Andrew Morton wrote:
Your email client is doing space-stuffing. It's easy enough to fix at this
end, but even easier if you fix it ;)
Aw darn :( Stupid PINE. I'll fix it for the next patch.
+ atomic_notifier_call_chain(_dumper_list, 0, NULL);
[...]
So... Please
On Thu, Jun 28, 2007 at 08:20:31AM -0400, Chris Mason wrote:
> On Thu, Jun 28, 2007 at 04:44:43AM +0200, Nick Piggin wrote:
> > That's true but I don't think an extent data structure means we can
> > become too far divorced from the pagecache or the native block size
> > -- what will end up
On Wed, Jun 27, 2007 at 11:58:30PM -0700, Josh Triplett wrote:
> Jan Engelhardt wrote:
> > On Jun 28 2007 06:29, dave young wrote:
> >> IMHO, another cause of trailing whitespace is human error, for
> >> example long lines breaking will easy to cause the first line with one
> >> traling
Hi,
2.6.20-1.2962.fc6 #1 SMP
When capturing video, and doing a recompile of a sofware application
(heavy disk load) things go pear shaped:
...
Jun 28 13:17:16 emachine kernel: ivtv0: Cause: the application is not
reading fast enough.
Jun 28 13:17:39 emachine kernel: ivtv0: All encoder MPEG
On Fri, 29 Jun 2007 02:39:33 +0200 (CEST) Jiri Kosina <[EMAIL PROTECTED]> wrote:
> On Thu, 28 Jun 2007, Joshua Wise wrote:
>
> > This patch adds a call chain to be invoked when the system oopses or
> > panics.
>
> That seems really fragile, processing a callchain when the system goes to
>
Configuring a guest with < CONFIG_M586TSC reveals an lguest bug: the
TSC code expects to see the TSC capability bit, but we weren't setting
up the capabilities until much later in check_bugs ->
identify_boot_cpu -> identify_boot_cpu.
Do the same thing as Xen and the head.S native code: populate
Anton Petrusevich wrote:
On Thursday 28 June 2007 17:02:55 you wrote:
Please always use Reply-to-All on this list -- subscribers here like to
also get personal copies.
I am not subscribed to linux-kernel, I am reading it on the web.
I have ICE1724, a very good sound card to my taste, works
>-Original Message-
>From: Robert Hancock [mailto:[EMAIL PROTECTED]
>Sent: Friday, June 29, 2007 8:59 AM
>To: Zan Lynx
>Cc: Andrew Morton; linux-kernel@vger.kernel.org; Raj, Ashok; Li,
Shaohua;
>Keshavamurthy, Anil S
>Subject: Re: 2.6.22-rc6-mm1 Intel DMAR crash on AMD x86_64
>
>Zan Lynx
[ resend, it seems to have been lost in time, lost in space ]
From: Jiri Kosina <[EMAIL PROTECTED]>
X86_64: fix wrong comment regarding set_fixmap()
The function name is set_fixmap(), not fixmap_set() as stated in the comment.
Also fix a typo, punctuation and lower/uppercase a bit.
On Thu, Jun 28, 2007 at 11:49:13PM +0530, Amit K. Arora wrote:
> On Wed, Jun 27, 2007 at 09:18:04AM +1000, David Chinner wrote:
> > On Tue, Jun 26, 2007 at 11:34:13AM -0400, Andreas Dilger wrote:
> > > On Jun 26, 2007 16:02 +0530, Amit K. Arora wrote:
> > > > On Mon, Jun 25, 2007 at 03:46:26PM
On Thu, Jun 28, 2007 at 03:39:04PM +0200, Heiko Carstens wrote:
> From: Heiko Carstens <[EMAIL PROTECTED]>
>
> git-acpi contains a patch that adds 'struct bin_attribute *' to
> the read method of struct bin_attribute. This breaks s390:
>
> CC arch/s390/kernel/ipl.o
>
Zan Lynx wrote:
On Thu, 2007-06-28 at 03:43 -0700, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/
+intel-iommu-dmar-detection-and-parsing-logic.patch
+intel-iommu-pci-generic-helper-function.patch
The sata_nv driver was missing the change_queue_depth hook in the SCSI host
template which the other NCQ-capable libata drivers had. This made it impossible
to change the queue depth by user request. Add this in.
Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>
---
On Thu, 28 Jun 2007, Joshua Wise wrote:
> This patch adds a call chain to be invoked when the system oopses or
> panics.
That seems really fragile, processing a callchain when the system goes to
panic is not guaranteed to work. Wouldn't simple function call have higher
chances of survival?
Joshua Wise <[EMAIL PROTECTED]> writes:
You are aware that oops screen estate is very precious on standard
systems without serial console?
> +/*
> + * Dump out UTS info on oops / panic.
> + */
> + +static int dump_utsname(struct notifier_block *self, unsigned long
> v, void *p)
> +{
> +
I noticed that is not possible ATM to allocate two or more blocks
of userspace memory. Would a compat_alloc_user() like the one below
make sense (patch untested)?
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
include/asm-ia64/compat.h|8
Hi,
On Fri, 29 Jun 2007, Alan Cox wrote:
> > > check_signature is relevant for anything with MMIO space (for example you
> > > can legitimately want to check_signature a MAC68K Nubus ROM).
> >
> > A generic check_signature() is a little difficult if we have separate io
> > functions for every
On Thu, 2007-06-28 at 23:49 +0530, Amit K. Arora wrote:
>
> > Correct, but for swap files that's not an issue - no user should be
> able
> > too read them, and FA_MKSWAP would really need root privileges to
> execute.
>
> Will the FA_MKSWAP mode still be required with your suggested change
> of
On Thursday 28 June 2007 01:40:32 pm you wrote:
> I'll provide more details on request, and when I get the chance. This
> is a heads-up on the BUG in case someone has an "ah ha!" moment.
I believe I have also reproduced this bug. I have an ABIT K9 Ultra
motherboard with NFORCE hardware. My
On Friday 29 June 2007 09:33, Siddha, Suresh B wrote:
> 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.
>
> There are two L2's,
On 6/28/07, Kyle McMartin <[EMAIL PROTECTED]> wrote:
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());
>
> Thanks for the thoughtful reply. _And_ for taking the time to look at
> the code.
>
> I guess my half-assed notion is to have a single file w/"#ifdef-able"
> entries that flag API changes. It at least would give me/us a single
> point of reference, and avoid the rather ugly version checking.
On Thu, 28 Jun 2007 16:12:23 -0700 (PDT)
Joshua Wise <[EMAIL PROTECTED]> wrote:
> Version: 2
>
> Background:
> When managing a large number of servers, as Google does, it's sometimes
> useful to get an "at-a-glance" view of a machine when it crashes. When no
> other post-mortem is
On Thu, Jun 28, 2007 at 03:39:49PM -0700, Andrew Morton wrote:
> On Thu, 28 Jun 2007 15:05:15 -0700
> Randy Dunlap <[EMAIL PROTECTED]> wrote:
>
> > From: Randy Dunlap <[EMAIL PROTECTED]>
> >
> > Fix section mismatch warnings:
> >
> > WARNING: sound/built-in.o(.exit.text+0x3ad): Section
Randy Dunlap wrote:
Is this what you mean?
Yup.
Acked-by: H. Peter Anvin <[EMAIL PROTECTED]>
-
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.org/majordomo-info.html
Please read
The latest serie of r8169 changes is available against 2.6.22-rc6 as:
http://www.fr.zoreil.com/people/francois/misc/20070628-2.6.22-rc6-r8169-test.patch
or (tarball sits one level higher):
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.22-rc6/r8169-20070628/
or (rebase prone branch)
git
On Thu, 28 Jun 2007, Steven Rostedt wrote:
>
> If one has CONFIG_PROVE_LOCKING off but CONFIG_TRACE_IRQFLAGS on, the
> RECURSION_LIMIT definition is not defined. This patch move
> RECURSION_LIMIT up for global use.
Arg, this wasn't good enough.
Here's a better patch (drop the previous one
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 Sat, Jun 02, 2007 at 03:57:12PM +0200, Adrian Bunk wrote:
> I'm getting the following compile error in 2.6.22-rc3-mm1 with
> CONFIG_X86_CMPXCHG=n (with -Werror-implicit-function-declaration -
> otherwise it would be a link error):
>
> <-- snip -->
>
> ...
> CC
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.
There are two L2's, each of 4MB. Each L2 shared by two cores.
thanks,
suresh
>
>
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.
On 2.6.22-rc6:
cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name :
Hi.
On Friday 29 June 2007 00:25:32 Pavel Machek wrote:
> Hi!
>
> > Hi all
> >
> > Here's what I have after today's work.
> >
> > I haven't yet been able to test on x86, but can confirm that it works okay
on x86_64. I'm currently working towards testing it on my old Omnibook. My P4
desktop
On Tue, 26 Jun 2007 21:45:05 -0500 Matt Domsch wrote:
> On Tue, Jun 26, 2007 at 01:26:22PM -0700, Randy Dunlap wrote:
> > Hi,
> >
> > CONFIG_EDD does not depend on PCI, but edd.c uses pci_* interface
> > functions, resulting in:
> >
> > CC [M] drivers/firmware/edd.o
> >
Renato S. Yamane wrote:
Hi,
Is impossible use speedstep in my Laptop with Pentium M 1,86Ghz:
#modprobe speedstep-centrino
FATAL: Error inserting speedstep_centrino
(/lib/modules/2.6.18-3-686/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.ko):
No such device
To do that (speedstep),
Roy Franz wrote:
Hi,
I am unable to change the NCQ settings for a sata drive that
supports it - NCQ is always on. This is due to the sysfs queue_depth
file being read-only. This is on
vanilla 2.6.21.5 running with Debian Etch. (Several earlier versions
of the kernel
had this same issue.)
On Thu, 28 Jun 2007, Kyle McMartin wrote:
woah woah woah. This could push critical bits of the register dump or
stacktrace off the screen... Barring any other problems with the patch,
this should probably be dumped in the oops header, not trailing it where
it could hide critical debugging info.
On 6/26/07, Dhaval Giani <[EMAIL PROTECTED]> wrote:
There are a few questions I had with respect to the current code,
Why is the increment of s_active dependent on the return value of
simple_set_mnt?
I think it's because, as you observed, grab_super() is static and
hence not reachable from
> I was mainly concerned with this being a new issue, and curious if
> Microsoft was calling an O/S bug a "microcode fix," given that the
> average Windows user doesn't know microcode from nanotech anyway. The
> non-answer from Arjan didn't answer either, and started by calling the
> report
> > check_signature is relevant for anything with MMIO space (for example you
> > can legitimately want to check_signature a MAC68K Nubus ROM).
>
> A generic check_signature() is a little difficult if we have separate io
> functions for every bus.
Does M68K implement iomap() and pci_iomap and
On Wed, 27 Jun 2007 14:34:03 -0400 H. Peter Anvin wrote:
> Alan Cox wrote:
> > On Wed, 27 Jun 2007 10:54:30 -0600
> > Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> >
> >> On Wed, Jun 27, 2007 at 12:41:41PM -0400, H. Peter Anvin wrote:
> >>> Note that EDD has no way of referencing anything but the
On Thu, 28 Jun 2007 18:45:11 -0400
Jeff Dike <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 28, 2007 at 11:25:37PM +0100, Alan Cox wrote:
> > This completely bogus. readb() should be present on M68K, fix the
> > platform to implement readb() for MMIO, even if your MMIO readb is a
> > moveb instruction.
Chuck Ebbert wrote:
On 06/28/2007 11:27 AM, Andi Kleen wrote:
But the problem is very obscure and you can likely ignore it too. If your
machine crashes it's very likely something else.
What about deliberate exploits of these bugs from userspace? Theo thinks
they are possible...
Do you have
By the way, there are three or four versions of a pxa27x UDC
driver floating around; which one is this? One you updated?
It looks like it forked from the pxa2xx driver several years ago
but never got cleaned up ... e.g. it's a different controller,
so none of the comments relevant to earlier
Ingo,
If one has CONFIG_PROVE_LOCKING off but CONFIG_TRACE_IRQFLAGS on, the
RECURSION_LIMIT definition is not defined. This patch move
RECURSION_LIMIT up for global use.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Index: linux-2.6.21.5-rt18/kernel/lockdep.c
Hi,
On Thu, 28 Jun 2007, Alan Cox wrote:
> > check_signature() needs readb() but with some setups (s390, m68k
> > allmodconfig)
> > there is no implementation of readb. This causes build errors with
> > -Werror-implicit-function-declaration.
>
> This completely bogus. readb() should be
Michael Kerrisk wrote:
Alexander,
I just released man-pages-2.59 and man-pages-2.60.
These releases are now available for download at:
http://www.kernel.org/pub/linux/docs/manpages
Yes, just this morning I decided to tidy away some of the old
tarballs into a newly created "old"
Ingo,
I think this was sent before, and it did cause problems before. Would
there be *any* reason to have non-threaded softirqs but threaded hardirqs.
I can see lots of issues with that.
This patch has selecting hardirqs also select softirqs as threads.
Signed-off-by: Steven Rostedt <[EMAIL
On 06/29/2007 12:48 AM, Alan Cox wrote:
On Fri, 29 Jun 2007 00:00:27 +0200
Rene Herman <[EMAIL PROTECTED]> wrote:
On 06/28/2007 06:30 PM, Alan Cox wrote:
Public domain is GPL compatible.
Would you happen to have an opinion on the attached? I don't so much need it
The answer is "NO"
On Thu, Jun 28, 2007 at 11:25:37PM +0100, Alan Cox wrote:
> This completely bogus. readb() should be present on M68K, fix the
> platform to implement readb() for MMIO, even if your MMIO readb is a
> moveb instruction.
>
> check_signature is relevant for anything with MMIO space (for example you
>
On Fri, 29 Jun 2007 00:00:27 +0200
Rene Herman <[EMAIL PROTECTED]> wrote:
> On 06/28/2007 06:30 PM, Alan Cox wrote:
>
> > Public domain is GPL compatible.
>
> Would you happen to have an opinion on the attached? I don't so much need it
The answer is "NO"
Public domain also means "I don't
On Thu, 28 Jun 2007 15:05:15 -0700
Randy Dunlap <[EMAIL PROTECTED]> wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Fix section mismatch warnings:
>
> WARNING: sound/built-in.o(.exit.text+0x3ad): Section mismatch: reference to
> .init.text: (between 'sb_exit' and 'unload_uart6850')
>
> I was mainly concerned with this being a new issue, and curious if
> Microsoft was calling an O/S bug a "microcode fix," given that the
> average Windows user doesn't know microcode from nanotech anyway. The
> non-answer from Arjan didn't answer either, and started by calling the
then ask
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,
On 28 Jun 2007, Adrian Bunk outgrape:
> Linux software not supporting ALSA has becoming quite esoteric.
Indeed. This is why I haven't moaned much (or at all): aoss is ugly,
sure, but you only need it for those rare apps which run for a long time
or while other sounds are playing, on
Andi Kleen wrote:
Slashdot carried an article this morning saying that an error in Intel
microcode was being fixed. However, it listed only Windows related sites
That's a little misleading. Always dangerous getting your information
from slashdot. Let's say Intel clarified some corner
> check_signature() needs readb() but with some setups (s390, m68k allmodconfig)
> there is no implementation of readb. This causes build errors with
> -Werror-implicit-function-declaration.
This completely bogus. readb() should be present on M68K, fix the
platform to implement readb() for MMIO,
[Update is needed because of pm-introduce-set_target-method-in-pm_ops.patch]
---
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
The SNAPSHOT_S2RAM ioctl code is outdated and it should not duplicate the
suspend code in kernel/power/main.c. Fix that.
Signed-off-by: Rafael J. Wysocki <[EMAIL
On Thu, 28 Jun 2007 18:09:21 +0400
Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
> ---
>
> include/asm-frv/pgtable.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/include/asm-frv/pgtable.h
> +++
On Friday, 29 June 2007 00:00, Pavel Machek wrote:
> On Thu 2007-06-28 17:27:34, Rafael J. Wysocki wrote:
> > On Wednesday, 27 June 2007 22:49, Pavel Machek wrote:
> > > Hi!
> > >
> > > > FWIW, I'm on record stating that "sync" is not sufficient to quiesce an
> > > > XFS
> > > > filesystem for a
From: Joshua Wise <[EMAIL PROTECTED]>
Background:
When managing a large number of servers, as Google does, it's sometimes
useful to get an "at-a-glance" view of a machine when it crashes. When no
other post-mortem is possible, it's often useful to know how long the
machine has been powered
1 - 100 of 764 matches
Mail list logo
