Arjan van de Ven wrote:
> On Thu, 15 Nov 2007 04:00:47 GMT
> Linux Kernel Mailing List wrote:
>
>
>> Gitweb:
>> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=35d5d08a085c56f153458c3f5d8ce24123617faf
>> Commit: 35d5d08a085c56f153458c3f5d8ce24123617faf Parent
On Fri, November 16, 2007 01:34, Chris Wedgwood wrote:
> I'm not sure what you're doing here, but a viable work-around for now
> might be to use nfsv2 mounts, something like
>
> mount -o vers=2 ...
> or to keep v3 and disable readdirplus doing something like:
> mount -o vers=3,nordirplus ...
OK, I
Just getting back to this now that SC07 is finally over...
On Nov 13, 2007, at 5:52 PM, Andi Kleen wrote:
On Tue, Nov 13, 2007 at 04:28:52PM -0800, Philip Mucci wrote:
I know you don't want to hear this, but we actually use all of the
features of perfmon, because a) we wanted to use the best m
From: "Jonas Danielsson" <[EMAIL PROTECTED]>
Date: Fri, 16 Nov 2007 09:30:11 +0100
> 2007/11/16, David Miller <[EMAIL PROTECTED]>:
> > From: "Jonas Danielsson" <[EMAIL PROTECTED]>
> > Date: Thu, 15 Nov 2007 22:40:13 +0100
> >
> > > Is there a reason that the target hardware address isn't the targe
On Nov 15, 2007 23:02 -0800, Andrew Morton wrote:
> So we have a section of blocks around the middle of the blockgroup which
> are used for indirect blocks.
>
> Presmably it starts around 50% of the way into the blockgroup?
>
> An important question is: how does it stand up over time? Simply la
> I think Jeremy's question was due to trying to reduce the 32/64-bit
> differences. Performance-wise, it might add a small amount to user
> setup time (a typical 32-bit process will need all four, for the main
> binary, libraries, stack and kernel, respectively)
With the new top down mmap l
due to an embarrassing brain fart on my part, my script to find
unused CONFIG variables in the source tree missed a whole whack of
them. (FYI, when checking Kconfig variable FUBAR, the fact that the
corresponding reference to CONFIG_FUBAR is being used in a defconfig
file somewhere does *not* c
On Mittwoch 14 November 2007 19:32:01, you (Frank Seidel) wrote:
> Hi,
>
> this is a small trivial rework of the dcdbas driver so
> HAL can get uevents when platform devices are added or removed.
Sorry for the noise! In the meantime i realized (thanks to a nice
colleague) this isn't really necess
* Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > + prev_cpu = smp_processor_id();
> > rep_nop();
> > + preempt_enable();
>
> Why not have the rep_nop() here between the enable, and disable ?
yes, indeed - fixed.
> > + /*
> > +* If we preempt
On Wed, 2007-11-14 at 03:28 +0100, Andi Kleen wrote:
> On Tue, Nov 13, 2007 at 05:52:08PM -0800, David Miller wrote:
> > Yes, I've run into similar problems with lockdep as well.
> > I had to build an ultra minimalized kernel to get it to
> > boot on my Niagara boxes.
> >
> > I think I even looke
Hello,
Got problems with CFS after a kernel upgrade from 2.6.20 to 2.6.23.
After a certain amount of time since cattach i get:
ios:~$ ls /opt/clear/
ls: /opt/clear/: Not a directory
stracing the command i get stat64() returning ENOTDIR.
Applications won't find the directory.
If i cd into it
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> once that tracer bug was fixed, the best method to generate a trace
> was to do this:
>
>echo 1 > /proc/sys/kernel/stackframe_tracing
>echo 1 > /proc/sys/kernel/syscall_tracing
>./trace-cmd bash -c "echo mem > /sys/power/state" > trace.txt
Am Freitag 16 November 2007 schrieb Maciej W. Rozycki:
> On Thu, 15 Nov 2007, Oliver Neukum wrote:
>
> > On irq 20, there's an UHCI, on irq 19 is an EHCI. For every interrupt on 20
> > there's a spurious interrupt on 19. USB devices on bus of the controller on
> > 20
> > work. So I know all inter
On Fri, Nov 16, 2007 at 10:17:17AM +0100, Christian Kujau wrote:
> OK, I'll try this. I hope this can be fixed somehow before 2.6.24...
Well, one simple nasty idea would be something like:
diff --git a/fs/Kconfig b/fs/Kconfig
index 429a002..da231fd 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -16
On Fri, Nov 16, 2007 at 07:07:00AM +0100, Ingo Molnar wrote:
>
> * Micah Dowty <[EMAIL PROTECTED]> wrote:
>
> > > I am a bit at a loss as to how this could relate to the patch. This
> > > looks like a load balance logic issue that causes the load
> > > calculation to go wrong?
> >
> > My best
* Micah Dowty <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 16, 2007 at 07:07:00AM +0100, Ingo Molnar wrote:
> > > My best guess is that this has something to do with the timing with
> > > which we sample the CPU's instantaneous load when calculating the load
> > > averages.. but I still understand
Nathan Lynch wrote:
Hi-
B. N. Poornima wrote:
On Fri, 2005-06-03 at 14:25 -0500, Nathan Lynch wrote:
Typo in prom_find_machine_type from Ben's recent patch "ppc64: Fix
result code handling in prom_init" prevents pSeries LPAR systems from
booting.
Hello,
Same typo has cre
Hi,
I have just some minor remarks wrt the commit message for
daa93fab824f2b8c35bd11670c7fab2f32b2de5f - 'x86: enable "make
ARCH=x86"'. (Based on my observations when testing the stuff on 64bit
and 32bit hosts with Linus' tree v2.6.24-rc2-640-g8c08634.)
For randconfig we have now the following be
Steven Rostedt wrote:
IIRC, only CALLER_ADDR0 is actually used (I've found that the others are
mostly unreliable).
I seem to recall more use was made of __builtin_return_address(n)
for 0 < n in the past compared to the current code. Likely for
shallow frames the 0 < n calls were potentially re
2007/11/11, Joonwoo Park <[EMAIL PROTECTED]>:
> IMHO even though netdevice is in the promiscuous mode, we should receive all
> of ingress packets.
> This disable the vlan filtering feature when a vlan hw accel configured e1000
> device goes into promiscuous mode.
> This make packets visible to sn
The new ARCH=x86 kernel build causes weired machine strings on 32-bit.
For a cross-compiled kernel I have
$ uname -m
x66_64
For a kernel natively built on a 32 bit machine I have
$ uname -m
x66
Looking at the sources, I think that utsname->machine was initial
>From time to time people begin discussions about how the
namespaces are working/going-to-work together.
Ted T'so proposed to create some document that describes what
problems user may have when he/she creates some new namespace,
but keeps others shared. I liked this idea, so here's the
initial v
On Fri, Nov 16, 2007 at 07:07:00AM +0100, Ingo Molnar wrote:
> > My best guess is that this has something to do with the timing with
> > which we sample the CPU's instantaneous load when calculating the load
> > averages.. but I still understand only the basics of the scheduler and
> > SMP balan
Andreas Herrmann wrote:
The new ARCH=x86 kernel build causes weired machine strings on 32-bit.
For a cross-compiled kernel I have
$ uname -m
x66_64
For a kernel natively built on a 32 bit machine I have
$ uname -m
x66
Looking at the sources, I think that utsname->machin
Philip Mucci <[EMAIL PROTECTED]> writes:
>
> Yes, although this has been done before. You've got the list below in
> the previous
> emails which should be considered the absolute minimum.
I didn't see a clear list.
My impression so far is that you're not quite sure what you want,
otherwise you w
proc_kill_inodes() can clear ->i_fop in the middle of vfs_readdir resulting in
NULL dereference during "file->f_op->readdir(file, buf, filler)".
The solution is to remove proc_kill_inodes() completely:
a) we don't have tricky modules implementing their tricky readdir hooks which
could keeping t
Hi,
On Friday, 16 of November 2007, Franck Bui-Huu wrote:
> Rafael,
>
> Looking at commit:
>
> 831441862956fffa17b9801db37e6ea1650b0f69
> Freezer: make kernel threads nonfreezable by default
>
> it seems that you broke the apm emulation driver.
>
> You removed PF_NOFREEZE flag sett
Andi,
On Fri, Nov 16, 2007 at 04:15:56PM +0100, Andi Kleen wrote:
> My impression so far is that you're not quite sure what you want,
> otherwise you would be more concrete.
>
> > - A feature which was dropped earlier by Stefane (only to satiate
> > LKML), we consider
> > very important. Allowing
Pavel Emelyanov wrote:
From time to time people begin discussions about how the
namespaces are working/going-to-work together.
Ted T'so proposed to create some document that describes what
problems user may have when he/she creates some new namespace,
but keeps others shared. I liked this idea,
On Friday 16 November 2007 16:45:16 H. Peter Anvin wrote:
> Andi Kleen wrote:
> >> I think Jeremy's question was due to trying to reduce the 32/64-bit
> >> differences. Performance-wise, it might add a small amount to user
> >> setup time (a typical 32-bit process will need all four, for the mai
Hello All,
I have a problem with the RT-mutex code and signals. The problem is
very easily reproducible, but I do not have found the root-cause yet.
I hope someone can help me on this one.
This is what I am doing:
* I have a simple character driver with a read call.(called spi_read()
in the loggi
On Thu, Nov 15, 2007 at 11:15:27PM -0800, Greg KH wrote:
> Rob, I'll queue this up for the next cycle, now that you've verified
> that it was not fixed already, thanks for testing.
I wouldn't.
sparc includes swap.h in its pgtable.h. Adding pagemap.h to swap.h
completes an include loop on sparc w
Andi Kleen wrote:
On Friday 16 November 2007 16:45:16 H. Peter Anvin wrote:
Andi Kleen wrote:
I think Jeremy's question was due to trying to reduce the 32/64-bit
differences. Performance-wise, it might add a small amount to user
setup time (a typical 32-bit process will need all four, for the
David Howells <[EMAIL PROTECTED]> wrote:
> Fix MTD JEDEC probe so that the ASB2303 bootprom can be accessed. This is
> presumably required because the bootprom is normally write-protected and so
> the normal flash probes don't work as they require the ability to write to the
> flash to send it co
On Fri, Nov 16, 2007 at 11:33:20AM +0900, Ken'ichi Ohmichi wrote:
>
> This patch fixes the configuration dependencies in the vmcoreinfo data.
>
> i386's "node_data" is defined in arch/x86/mm/discontig_32.c,
> and x86_64's one is defined in arch/x86/mm/numa_64.c.
> They depend on CONFIG_NUMA:
>
On Fri, Nov 16, 2007 at 08:00:56AM -0800, Stephane Eranian wrote:
> No, he is talking about something similar to what was in perfctr.
> The kernel emulates 64-bit counters in software and that is you
> get back when you read the counters. If you read via RDPMC, you
> get 40 bits. To reconstruct the
Daniel Lezcano wrote:
> Pavel Emelyanov wrote:
>> >From time to time people begin discussions about how the
>> namespaces are working/going-to-work together.
>>
>> Ted T'so proposed to create some document that describes what
>> problems user may have when he/she creates some new namespace,
>> but
On Fri, Nov 16, 2007 at 10:12:57AM -0500, Jeff Dike wrote:
>On Fri, Nov 16, 2007 at 11:08:32AM +0800, WANG Cong wrote:
>> Could you please try this patch? Can it fix the error?
>>
>> Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
>>
>> ---
>>
>> diff --git a/Makefile b/Makefile
>> diff --git a/inc
On Fri, Nov 16, 2007 at 04:09:42PM +0100, Bastian Blank wrote:
> On Fri, Nov 16, 2007 at 03:29:45PM +0100, Martin Schwidefsky wrote:
> > #else
> > static inline void acpi_early_init(void) { }
> > #endif
> > +#ifdef CONFIG_S390
> > +extern int sclp_init(void);
> > +#else
> > +static inline int sc
On Fri, Nov 16, 2007 at 11:08:32AM +0800, WANG Cong wrote:
> Could you please try this patch? Can it fix the error?
>
> Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
>
> ---
>
> diff --git a/Makefile b/Makefile
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index 4f3838a..2c3ce4c 10
Rafael,
Looking at commit:
831441862956fffa17b9801db37e6ea1650b0f69
Freezer: make kernel threads nonfreezable by default
it seems that you broke the apm emulation driver.
You removed PF_NOFREEZE flag setting in apm_ioctl(), which is
definitely not part of the apm kernel daemon b
From: Heiko Carstens <[EMAIL PROTECTED]>
Remove binary sysctls that never worked due to missing strategy functions.
Cc: "Eric W. Biederman" <[EMAIL PROTECTED]>
Cc: Christian Borntraeger <[EMAIL PROTECTED]>
Cc: Gerald Schaefer <[EMAIL PROTECTED]>
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
S
From: Peter Oberparleiter <[EMAIL PROTECTED]>
Modify the sense id channel program to allow device sensing of pav
alias devices which belong to a base device with ungrouped paths.
Signed-off-by: Peter Oberparleiter <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
dri
These are the s390 patches in the queue for 2.6.24-rc. I plan to send
a please pull sometime next week. The shortlog:
Christian Borntraeger (2):
[S390] magic sysrq: check for in_atomic before doing an console_unblank
[S390] Optimize storage key handling for anonymous pages
Christoph L
On Fri, 2007-11-16 at 10:27 +0100, Gianluca Alberici wrote:
> Hello,
>
> Got problems with CFS after a kernel upgrade from 2.6.20 to 2.6.23.
> After a certain amount of time since cattach i get:
>
> ios:~$ ls /opt/clear/
> ls: /opt/clear/: Not a directory
>
> stracing the command i get stat64(
* Dave Hansen ([EMAIL PROTECTED]) wrote:
> On Thu, 2007-11-15 at 16:51 -0500, Mathieu Desnoyers wrote:
> > * Dave Hansen ([EMAIL PROTECTED]) wrote:
> > > > On Tue, 2007-11-13 at 14:33 -0500, Mathieu Desnoyers wrote:
> > > > linux-2.6-lttng/mm/page_io.c2007-11-13 09:49:35.0 -0500
>
Herbert Xu wrote:
BTW, how does the VLAN TX acceleration work at all? It's using
skb->cb to carry the tags but then calls dev_queue_xmit. Once
you do that packet schedulers can scribble all over skb->cb.
Also vlan_skb_recv should be moved out-of-line. It's absolutely
humongous. It'll generate
On Fri, Nov 16, 2007 at 08:49:02PM +0900, Joonwoo Park wrote:
>
> Not anymore about just e1000 :)
> I made an another patch with different approach which doesn't fix nic driver.
> In addition, this patch does disable all hw vlan acceleration features (rx,
> tx, filter) for promiscuous netdevice.
From: Heiko Carstens <[EMAIL PROTECTED]>
Use the sclp interface so that also standby cpus can be activated and
deactivated. CPUs that are brought offline will be automatically put
in standby state.
If a logical cpu is brought online the first cpu in stopped state will
be used. If none is available
From: Michael Ernst <[EMAIL PROTECTED]>
Signed-off-by: Michael Ernst <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
drivers/s390/char/Makefile |2
drivers/s390/char/sclp_cpi.c | 246 +---
drivers/s390/char/sclp_cpi_sys.c | 390 +
From: Peter Oberparleiter <[EMAIL PROTECTED]>
From: Cornelia Huck <[EMAIL PROTECTED]>
Change the adapter interrupt interface in order to allow multiple
adapter interrupt handlers to be registered. Indicators are now
allocated by cio instead of the device driver.
The qdio parts have been
Acked-by:
* Dave Hansen ([EMAIL PROTECTED]) wrote:
> On Thu, 2007-11-15 at 16:51 -0500, Mathieu Desnoyers wrote:
> > * Dave Hansen ([EMAIL PROTECTED]) wrote:
> > > > On Tue, 2007-11-13 at 14:33 -0500, Mathieu Desnoyers wrote:
> > > > linux-2.6-lttng/mm/page_io.c2007-11-13 09:49:35.0 -0500
>
Hi Adam,
If this condition check is not included, the root user have to use the
function
setrlimit() to set the lock_limit of a normal user to RLIM_INFINITY. I
think
the /proc interface 'hugetlb_shm_group' is introduced to avoid these
difficulties.
Please correct me, if I am wrong.
Regardin
From: Heiko Carstens <[EMAIL PROTECTED]>
Remove binary sysctls that never worked due to missing strategy functions.
Cc: Christian Borntraeger <[EMAIL PROTECTED]>
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: "Eric W. Biederman" <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <
From: Heiko Carstens <[EMAIL PROTECTED]>
When returning from IRQ handling and TIF_NEED_RESCHED is set we must
call preempt_schedule_irq() instead of schedule().
Otherwise the BKL might be unlocked in schedule() and therfore
everything that relies on the BKL is broken.
Signed-off-by: Heiko Carsten
From: Christian Borntraeger <[EMAIL PROTECTED]>
page_mkclean used to call page_clear_dirty for every given page. This
is different to all other architectures, where the dirty bit in the
PTEs is only resetted, if page_mapping() returns a non-NULL pointer.
We can move the page_test_dirty/page_clear_
On Fri, 2007-11-16 at 13:11 +0100, markus reichelt wrote:
> * Gianluca Alberici <[EMAIL PROTECTED]> wrote:
>
> > If i cd into it and ls it is like doing a refresh: everything works
> > again for a certain amount of time, then, again. It reminds me an
> > old version of CFS which used to claim: 's
Hi Andrew,
The kernel enters the xmon state while running the file system
stress on nfs v4 mounted partition.
0:mon> e
cpu 0x0: Vector: 300 (Data Access) at [c000dbd4f820]
pc: c0065be4: .__wake_up_common+0x44/0xe8
lr: c0069768: .__wake_up+0x54/0x88
sp: c000dbd
> "DM" == David Miller <[EMAIL PROTECTED]> writes:
>> Reply:
>> Opcode: reply (0x0002)
>> Sender HW: 00:AA.00:AA:00:AA
>> Sender IP: 192.168.0.1
>> Target HW: 00:AA:00:AA:00:AA
>> Target IP:192.168.0.1
DM> And this is exactly a sensible response in my opinion.
Why send the reply at al
Greetings,
Ive been following your discussion and documentation efforts concerning pm in
the kernel. This has in the past been a gray area which was hard to find
information about so kudos.
I maintain 2 handheld platforms that would benefit greatly from implementing
proper pm (mainly suspend)
On Thu, Nov 15, Torsten Kaiser wrote:
> While the next bisect proved that these patches are innocent, I'm
> still blaming you for my problems. ;)
:(
> The only thing that looks suspicious to me in that patch is the
> following change in nfs4_atomic_open(), nfs4_open_revalidate() and
> nfs4_proc
Add platform MTD support for the ASB2303 board.
Signed-off-by: David Howells <[EMAIL PROTECTED]>
---
arch/mn10300/configs/asb2303_defconfig |5 +-
arch/mn10300/unit-asb2303/Makefile |2 -
arch/mn10300/unit-asb2303/flash.c | 100
3 files changed,
Am Freitag, 9. November 2007 00:51 Robert Hancock wrote:
> Rainer Koenig wrote:
> >
> > Ok, short description of the problem:
> >
> > I run 64-bit Linux using 2 GB of RAM, no problem at all. Then I turn off
> > the machine, add 2 more GB so that now I have 4 GB of RAM. Turning it on
> > I see the
On 16/11/2007, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Micah Dowty <[EMAIL PROTECTED]> wrote:
>
> > > I am a bit at a loss as to how this could relate to the patch. This
> > > looks like a load balance logic issue that causes the load
> > > calculation to go wrong?
> >
> > My best guess is tha
Here are the results for the latest tests, some notes:
o The machine actually has 8GiB of RAM, so the tests still may end up
using (some) page cache. (But at least it was the same for both kernels!
:-) )
o Sorry the results took so long - the updated tree size caused the
runs to take > 12
On Fri, 2007-11-16 at 11:57 -0500, Alan Stern wrote:
> This patch (as1013) was suggested by David Woodhouse; it fixes a race
> in the driver core. If a device is unregistered at the same time as
> its driver is unloaded, the driver's code pages may be unmapped while
> the remove method is still r
On Fri, 16 Nov 2007 16:52:34 +0100 Daniel Lezcano wrote:
> > +1. Both the IPC and the PID namespaces provide IDs to address
> > + object inside the kernel. E.g. semaphore with ipcid or
> > + process group with pid.
> > +
> > + In both cases, tasks shouldn't try exposing this id to some
> > +
On Wed, Nov 14, 2007 at 10:29:57PM +0100, Miklos Szeredi wrote:
> Config attached.
Thanks - this reproduces it for me.
BTW, you can work around this by enabling NO_HZ.
Jeff
--
Work email - jdike at linux dot intel dot com
-
To unsubscribe from this list: send th
Dear Pete, dear all,
On Mi, 31 Okt 2007, preining wrote:
> On Di, 30 Okt 2007, Pete Zaitcev wrote:
> > The difference with huaweiAktBbo.c seems that kernel uses a nonzero length.
> > Can you try zero length with the kernel? It's the second argument to the
> > last.
>
> I tried with the git patch
This 'patch' did not work.
I tried setting the physical mem to just below the va addresses the
PEX is being assigned (0xea90 (3753M) and everything works...
I set it to just above - and it gets miscellaneous boot problems
like binfmt problems when attempting to insmod a module at boot tim
snd hda suspend latency goes down a second via the patch below.
Ingo
->
Subject: snd hda suspend latency: shorten codec read
From: Ingo Molnar <[EMAIL PROTECTED]>
not sleeping for every codec read/write but doing a short udelay and
a conditional reschedule has cut suspend+re
Hi Andreas.
On Fri, Nov 16, 2007 at 12:14:46PM +0100, Andreas Herrmann wrote:
> Hi,
>
> I have just some minor remarks wrt the commit message for
> daa93fab824f2b8c35bd11670c7fab2f32b2de5f - 'x86: enable "make
> ARCH=x86"'. (Based on my observations when testing the stuff on 64bit
> and 32bit hos
Hi,
On Fri, 16 Nov 2007, Sam Ravnborg wrote:
> 1) make all*config, randconfig, defconfig is broken on 64-bit boxes
With your approach you made it impossible to set 64BIT from all*.config,
which is the proper way to set the defaults.
> 2) A pure code refactoring patch is reverted for no obvious
* Gianluca Alberici <[EMAIL PROTECTED]> wrote:
> If i cd into it and ls it is like doing a refresh: everything works
> again for a certain amount of time, then, again. It reminds me an
> old version of CFS which used to claim: 'stale NFS file handle'.
"there are no fish in my pond"
# CONFIG_NFS
(Cc: trimmed a bit).
On Thu, 2007-11-15 at 11:19 -0500, Daniel Barkalow wrote:
> On Thu, 15 Nov 2007, Theodore Tso wrote:
[...]
> > A full kernel build with everything selected can take good 30 minutes or
> > more, and that's on a fast dual-core machine with 4gigs of memory and
> > 7200rpm disk
Hello,
Got problems with CFS after a kernel upgrade from 2.6.20 to 2.6.23.
After a certain amount of time since cattach i get:
ios:~$ ls /opt/clear/
ls: /opt/clear/: Not a directory
stracing the command i get stat64() returning ENOTDIR.
Applications won't find the directory.
If i cd into it an
Hello,
Got problems with CFS after a kernel upgrade from 2.6.20 to 2.6.23.
After a certain amount of time since cattach i get:
ios:~$ ls /opt/clear/
ls: /opt/clear/: Not a directory
stracing the command i get stat64() returning ENOTDIR.
Applications won't find the directory.
If i cd into it an
Alan D. Brunelle wrote:
Read large file:
Kernel MinAvgMax Std Dev%user %system %iowait
--
base : 201.6 215.1 275.5 22.8 0.26%4.69% 33.54%
arjan: 198.0 210.3 261.5 18.5 0.33% 10.24% 54.00%
R
On Fri, 16 Nov 2007 18:08:40 +0300 Alexey Dobriyan wrote:
> Andrew, please drop procfs-detect-duplicate-names.patch and apply this
> instead.
>
> [PATCH] proc: detect duplicate names on registration
>
> From: Zhang Rui <[EMAIL PROTECTED]>
>
> Print a warning if PDE is registered wit
On Fri, Nov 16, 2007 at 10:51:08AM -0500, Jeff Dike wrote:
> On Thu, Nov 15, 2007 at 11:15:27PM -0800, Greg KH wrote:
> > Rob, I'll queue this up for the next cycle, now that you've verified
> > that it was not fixed already, thanks for testing.
>
> I wouldn't.
>
> sparc includes swap.h in its pg
On 16-11-07 08:39, Zhao Yakui wrote:
Subject: PNP: Increase the value of PNP constant
From: Zhao Yakui <[EMAIL PROTECTED]>
On some systems the number of resources(IO,MEM) returnedy by PNP
device is greater than the PNP constant, for example motherboard devices.
It brings that some resources c
This patch (as1013) was suggested by David Woodhouse; it fixes a race
in the driver core. If a device is unregistered at the same time as
its driver is unloaded, the driver's code pages may be unmapped while
the remove method is still running. The calls to get_driver() and
put_driver() were inten
On Nov 16, 2007 5:20 PM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> The freezer doesn't regard the current task as freezable.
>
Hmm, I don't get your point.
If I understood this driver correctly, several processes can be
waiting for a suspend event by reading /dev/apm_bios, apmd (the _user
From: Heiko Carstens <[EMAIL PROTECTED]>
This is needed since the sclp must be initialized before cpus are
brought online and after interrupts are enabled. The sclp interface
is used figure out which cpus are present and can be brought online.
Adding an sclp_init() call to __cpu_up() is not a vali
From: Heiko Carstens <[EMAIL PROTECTED]>
Current support for TRACE_IRQFLAGS and lockdep_sys_exit is broken.
IRQ flag tracing is broken for program checks. Even worse is that
the newly introduced calls to lockdep_sys_exit are in the critical
section code which is not supposed to call any C function
On Fri, Nov 16, 2007 at 03:29:45PM +0100, Martin Schwidefsky wrote:
> #else
> static inline void acpi_early_init(void) { }
> #endif
> +#ifdef CONFIG_S390
> +extern int sclp_init(void);
> +#else
> +static inline int sclp_init(void) {return 0;}
> +#endif
> #ifndef CONFIG_DEBUG_RODATA
> static in
Andi Kleen wrote:
I think Jeremy's question was due to trying to reduce the 32/64-bit
differences. Performance-wise, it might add a small amount to user
setup time (a typical 32-bit process will need all four, for the main
binary, libraries, stack and kernel, respectively)
With the new top
On Nov 16, 2007 3:29 PM, Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
> +
> +static decl_subsys(cpi, NULL, NULL);
> +
decl_subsys() and all other static kset cruft called "subsys" will be
gone with 2.6.25.
The patch series doing this is in -mm, and this patch will need
(trivial) adaption to the
n
From: Michael Holzheu <[EMAIL PROTECTED]>
In case of a kernel panic it is currently possible to specify that a dump
should be created, the system should be rebooted or stopped. Virtual sysfs
files under the directory /sys/firmware/ are used for that configuration.
In addition to that, there are ke
From: Heiko Carstens <[EMAIL PROTECTED]>
Don't perform a sigp store-status-at-address on smp_send_stop().
It will overwrite the lowcores of other cpus and destroys valueable
debug informations.
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
From: Christian Borntraeger <[EMAIL PROTECTED]>
When doing an magic sysrq reboot on s390 the following bug message
appears:
SysRq : Resetting
BUG: sleeping function called from invalid context at include/asm/semaphore.h:61
in_atomic():1, irqs_disabled():0
074002a8 0fe6bc48 00
On Fri, 2007-11-16 at 03:03 -0800, Chris Wedgwood wrote:
> On Fri, Nov 16, 2007 at 10:17:17AM +0100, Christian Kujau wrote:
>
> > OK, I'll try this. I hope this can be fixed somehow before 2.6.24...
>
> Well, one simple nasty idea would be something like:
>
> diff --git a/fs/Kconfig b/fs/Kconfi
* Rusty Russell ([EMAIL PROTECTED]) wrote:
> On Thursday 15 November 2007 16:37:51 Mathieu Desnoyers wrote:
> > * Rusty Russell ([EMAIL PROTECTED]) wrote:
> > > On Thursday 15 November 2007 15:06:10 Mathieu Desnoyers wrote:
> > > > A - the NMI or MCE code calls any external kernel code (printk,
> >
On Fri, 2007-11-16 at 12:23 +0100, Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > once that tracer bug was fixed, the best method to generate a trace
> > was to do this:
> >
> >echo 1 > /proc/sys/kernel/stackframe_tracing
> >echo 1 > /proc/sys/kernel/syscall_tracing
Fix MTD JEDEC probe so that the ASB2303 bootprom can be accessed. This is
presumably required because the bootprom is normally write-protected and so
the normal flash probes don't work as they require the ability to write to the
flash to send it commands.
In the condition of the excluded if-state
On Friday, 16 of November 2007, Ingo Molnar wrote:
>
> snd hda suspend latency goes down a second via the patch below.
>
> Ingo
>
> ->
> Subject: snd hda suspend latency: shorten codec read
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> not sleeping for every codec read/write but
On Nov 16, 2007 3:57 AM, Sven-Thorsten Dietrich <[EMAIL PROTECTED]>
wrote:
> Compile fix for new code in -rc2.
>
> I'm not positive about the insertion point...
>
> Subject: compile error fix (needs review)
>
> RT changes __list_splice to require prev and next pointers.
>
> This changes the use
Mark,
I've ported the old sataMV driver (version 3.6) to the 2.6.23.1
kernel - and it works - no problems with a full mem=4000M (4Gig).
The only problem with this is that it is MUCH slower than the
sata_mv driver which - by this test - definitely has some
bug/dependency that gets broken when
Linus Torvalds wrote:
> On Thu, 15 Nov 2007, Jeremy Fitzhardinge wrote:
>
>> Once difference is that 64-bit incrementally allocates all levels of the
>> pagetable, whereas 32-bit PAE preallocates the 4 pmds when it allocates
>> the pgd. What's the rationale for this? What pitfalls would there
On Fri, Nov 16, 2007 at 12:14:46PM +0100, Andreas Herrmann wrote:
> BTW, is the x86 kernel build documented somewhere?
> At a first glance I didn't find anything suitable under Documentation/.
> Maybe some explanation (like the above) should be added there.
When the ARCH=x86 build is documented, s
1 - 100 of 421 matches
Mail list logo
