On Sat, Sep 22, 2007 at 10:35:45PM -0700, Andrew Morton wrote:
> On Sun, 23 Sep 2007 13:30:40 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
>
> > > That's interensting. serial_in(). We have had NMI watchdog expiries when
> > > the kernel is printing a large amount of stuff out a slow serial
[EMAIL PROTECTED] (Mel Gorman) writes:
> On (16/09/07 23:31), Andrea Arcangeli didst pronounce:
>> On Sun, Sep 16, 2007 at 09:54:18PM +0100, Mel Gorman wrote:
>> Allocating ptes from slab is fairly simple but I think it would be
>> better to allocate ptes in PAGE_SIZE (64k) chunks and preallocate
On Sun, 23 Sep 2007 13:30:40 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
> > That's interensting. serial_in(). We have had NMI watchdog expiries when
> > the kernel is printing a large amount of stuff out a slow serial port with
> > interrutps disabled. But I thought we'd pretty much plugged
On Sat, Sep 22, 2007 at 09:22:36PM -0700, Andrew Morton wrote:
> On Sun, 23 Sep 2007 09:42:14 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Sep 18, 2007 at 01:18:41AM -0700, Andrew Morton wrote:
> > >
> > >
On Sunday 23 September 2007, Linus Torvalds wrote:
> From a "future behaviour" standpoint it would probably be interesting to
> hear whether Mihai can make his machine with not with the old IDE layer
> (which distributions are migrating away from) but with the ATA layer
> (libata) instead. It
On Sat, 2007-09-22 at 14:43 +0200, Avi Kivity wrote:
> What guest drivers?
>
> Cc: Jan Engelhardt <[EMAIL PROTECTED]>
> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
Yes, agreed.
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Sun, 23 Sep 2007 09:42:14 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 18, 2007 at 01:18:41AM -0700, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
> >
> > 2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
Rather than sitting on this for far too long, I wanted to go ahead and
get this out there. I heard some chips might be trickling out into
public hands.
This is a bare bones Broadcom 8603 SAS+SATA driver, attempting to use
the vaunted libsas. Notes:
* A quick glance at the FIXMEs will tell you
On Sep 22, 2007, at 20:47:21, Joe Perches wrote:
On Sat, 2007-09-22 at 20:40 -0400, Kyle Moffett wrote:
Severity is *exactly* "desirability of logging".
Disagree.
What's info to someone is an alert to someone else. The problem is
the valuation of the reasoning.
It's all opinion.
For
On Sat, Sep 22, 2007 at 10:23:59PM -0400, Gerhard Mack wrote:
>On Sat, 22 Sep 2007, WANG Cong wrote:
>
>> >Summary:
>> > CC mm/slub.o
>> >mm/slub.c: In function 'kfree':
>> >mm/slub.c:2491: warning: passing argument 3 of 'slab_free' discards
>> >qualifiers from pointer target type
>
>static
On Sun, 23 Sep 2007, Oleg Verych wrote:
>
> As i never had any suspend working ever, let me point this LKML post
>
> http://mid.gmane.org/[EMAIL PROTECTED]
>
> from Mihal, who just managed to do some other magic in sligtly
> different context (maybe yet another anti "ACPI screwed up").
>
>
This patch does the following things:
- Make hidp_setup_input() return int to indicate errors.
- Check its return value to handle errors.
Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
---
net/bluetooth/hidp/core.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
Index:
On Sat, 22 Sep 2007, WANG Cong wrote:
> >Summary:
> > CC mm/slub.o
> >mm/slub.c: In function 'kfree':
> >mm/slub.c:2491: warning: passing argument 3 of 'slab_free' discards
> >qualifiers from pointer target type
static void __slab_free(struct kmem_cache *s, struct page *page,
i used to add proxy arp's on the router when i had problems like
this. Dunno if it's the recommended fix, but it worked.
http://en.wikipedia.org/wiki/Proxy_arp
Carlos Narváez wrote:
This is starting to frustrate me, because it should be much simpler
than it seems to be, and I feel like I'm
Cleanup by using pgd_list_add() and pgd_list_del() in the right place.
Cc: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
---
include/asm-x86_64/pgalloc.h | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
Index:
i spoke too soon. The Gbit interface still dies. Lasted around
19hrs. or so. i can't tell if there are hardware issues: yesterday
a Gbit NIC on the firewall died. Different chip (Realtek),
different driver, different machine, same segment. Segment is a
mix of 100Mbit and 1Gbit machines.
2007/9/23, Thomas Gleixner <[EMAIL PROTECTED]>:
> On Sat, 2007-09-22 at 00:32 +0200, Andi Kleen wrote:
> > From: Akinobu Mita <[EMAIL PROTECTED]>
> >
> > Do cpuid_device_create() in CPU_UP_PREPARE instead of CPU_ONLINE.
> >
> > Cc: "H. Peter Anvin" <[EMAIL PROTECTED]>
> > Signed-off-by: Akinobu
On Sun, Sep 23, 2007 at 09:42:14AM +0800, Fengguang Wu wrote:
> On Tue, Sep 18, 2007 at 01:18:41AM -0700, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
> >
> > 2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
>
>
> This
On 9/22/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
> Yinghai Lu wrote:
> > On 9/22/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
> >> Thomas Gleixner wrote:
> >>> On Sat, 2007-09-22 at 10:28 -0600, Robert Hancock wrote:
> Yinghai Lu wrote:
> > No!
> >
> > MMCONFIG will not work
Much, much better :)
> -static void __meminit phys_pud_init(pud_t *pud_page, unsigned long addr,
> unsigned long end)
> -{
+static void __meminit phys_pud_init(pud_t *pud_page, ulong addr, ulong end)
If somebody have *strong* objections, please say so.
[]
> @@ -737,7 +750,7 @@ int
On Sat, Sep 22, 2007 at 03:16:22PM +0200, Peter Zijlstra wrote:
> On Sat, 22 Sep 2007 09:55:09 +0800 Fengguang Wu <[EMAIL PROTECTED]>
> wrote:
>
> > --- linux-2.6.22.orig/mm/page-writeback.c
> > +++ linux-2.6.22/mm/page-writeback.c
> > @@ -426,6 +426,14 @@ static void balance_dirty_pages(struct a
On 9/22/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
> Yinghai Lu wrote:
> > On 9/22/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
> >> Thomas Gleixner wrote:
> >>> On Sat, 2007-09-22 at 10:28 -0600, Robert Hancock wrote:
> Yinghai Lu wrote:
> > No!
> >
> > MMCONFIG will not work
On Saturday 22 September 2007 16:35:56 Andreas Schwab wrote:
> "John Z. Bohach" <[EMAIL PROTECTED]> writes:
> > if (WIFEXITED(siginfo->si_status))
>
> That does not make any sense. si_status is _not_ a wait status.
>
> Andreas.
Thank you for clearing that up. That explains it.
--john
-
To
On 9/22/07, Vegard Nossum <[EMAIL PROTECTED]> wrote:
> After recent discussions on LKML and a general dissatisfaction at the
> current printk() kernel-message logging interface, I've decided to
> write down some of the ideas for a better system.
Nice. I would suggest having some kind of standard
* Sat, 22 Sep 2007 15:59:25 -0700 (PDT)
As i never had any suspend working ever, let me point this LKML post
http://mid.gmane.org/[EMAIL PROTECTED]
from Mihal, who just managed to do some other magic in sligtly
different context (maybe yet another anti "ACPI screwed up").
Mihai, you can find
On Sat, 2007-09-22 at 20:40 -0400, Kyle Moffett wrote:
> Severity is *exactly* "desirability of logging".
Disagree.
What's info to someone is an alert to someone else.
The problem is the valuation of the reasoning.
It's all opinion.
cheers, Joe
-
To unsubscribe from this list: send the line
On Sep 22, 2007, at 20:13:03, Joe Perches wrote:
On Sat, 2007-09-22 at 21:27 +0200, Vegard Nossum wrote:
Additionally, this would allow the compiler to completely optimize
out calls that are below a certain log-level severity level [2][3].
Severity doesn't really equate to desire to log.
On Sat, 2007-09-22 at 21:27 +0200, Vegard Nossum wrote:
> #define kprint(fmt, ...)
Good ideas. Perhaps a prefix of klog or kp_ instead?
Given the number of 80 column zealots, character naming length matters.
> Additionally, this would allow the compiler to completely optimize out
> calls that
Hello
I am disturbing you with this problem because I think there is
something to be learnt, I have
no urgency or further-problem with my work-around.
Description: trying to boot with kernel 2.6.22 the booting process
stops not finding
the root partition, in the previous line it gives an
On Thu, 2007-09-20 at 02:26 -0400, ben soo wrote:
> Antonino A. Daplas wrote:
> > On Tue, 2007-09-18 at 03:26 -0400, ben soo wrote:
> >> i've 2 servers with old PCI VGA cards, one using X86_64 kernel
> >> version 2.6.23-rc5 and one with i386 kernel version 2.6.23-rc6,
> >> both wired into the
"John Z. Bohach" <[EMAIL PROTECTED]> writes:
> if (WIFEXITED(siginfo->si_status))
That does not make any sense. si_status is _not_ a wait status.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key
On Sat, 2007-09-22 at 13:53 -0700, David Brownell wrote:
> > Sigh. I need a real deep look inside that code to understand, why
> > tx_reqs is not a requestlist but a freelist. Very intuitive naming :)
>
> It *is* a list of requests: free ones -- the only kind this level of
> driver is allowed to
Linus,
On Sat, 2007-09-22 at 15:59 -0700, Linus Torvalds wrote:
> > My final enlightment was, when I removed the ACPI processor module,
> > which controls the lower idle C-states, right before resume; this
> > worked fine all the time even without all the workaround hacks.
> >
> > I really hope
* Sat, 22 Sep 2007 18:09:15 -0500
> This is starting to frustrate me, because it should be much simpler
> than it seems to be, and I feel like I'm missing something small and
> obvious.
Please address such questions to any user forum, or to
<[EMAIL PROTECTED]> otherwise.
While doing that,
On Sat, 22 Sep 2007, Thomas Gleixner wrote:
> On Sat, 2007-09-22 at 14:07 -0700, Davide Libenzi wrote:
> > On Sat, 22 Sep 2007, Michael Kerrisk wrote:
> >
> > > So I'm inclined to implement option (b), unless someone has strong
> > > objections. Davide, could I persuade you to help?
> >
> > I
This is starting to frustrate me, because it should be much simpler
than it seems to be, and I feel like I'm missing something small and
obvious.
I have two private networks, we'll say 192.168.254.0/24 and
192.168.251.0/24. And I have a linux box in the middle with addresses
192.168.254.17 and
On Sat, 22 Sep 2007, Thomas Gleixner wrote:
>
> My final enlightment was, when I removed the ACPI processor module,
> which controls the lower idle C-states, right before resume; this
> worked fine all the time even without all the workaround hacks.
>
> I really hope that this two patches
* Thu, 20 Sep 2007 19:18:46 +0200
[]
> extern u32 vmcoreinfo_note[VMCOREINFO_NOTE_SIZE/4];
> extern unsigned int vmcoreinfo_size;
> extern unsigned int vmcoreinfo_max_size;
> +int __init parse_crashkernel(char *cmdline, unsigned long long system_ram,
> + unsigned long long
In a desparate attempt to fix the suspend/resume problem on Andrews
VAIO I added a workaround which enforced the broadcast of the oneshot
timer on resume. This was actually resolving the problem on the VAIO
but was just a stupid workaround, which was not tackling the root
cause: the assignement of
Sorry, it took me quite a while to realize the real root cause of the
VAIO - and probably many other machines - suspend/resume regressions,
which were unearthed by the dyntick / clockevents patches.
We disable a lot of ACPI/BIOS functionality during suspend, but we
keep the lower idle C-states
device_suspend() calls ACPI suspend functions, which seems to have undesired
side effects on lower idle C-states. It took me some time to realize that
especially the VAIO BIOSes (both Andrews jinxed UP and my elfstruck SMP one)
show this effect. I'm quite sure that other bug reports against
Intel FB: the chip adds two halflines automatically in interlaced mode,
force even line count for the right timings.
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
--- a/drivers/video/intelfb/intelfbhw.c
+++ b/drivers/video/intelfb/intelfbhw.c
@@ -317,6 +317,14 @@ int
Intel FB: allow odd- and even-field-first in interlaced modes, and
proper sync to vertical retrace
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
--- a/drivers/video/intelfb/intelfbhw.c
+++ b/drivers/video/intelfb/intelfbhw.c
@@ -376,7 +376,7 @@ int intelfbhw_pan_display(struct
Intel FB: obvious changes and corrections
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
--- a/drivers/video/intelfb/intelfb.h
+++ b/drivers/video/intelfb/intelfb.h
@@ -355,7 +355,10 @@ struct intelfb_info {
struct intelfb_output_rec output[MAX_OUTPUTS];
};
-#define
Intel FB: whitespace, bracket and other clean-ups
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
--- a/drivers/video/intelfb/intelfb.h
+++ b/drivers/video/intelfb/intelfb.h
@@ -231,8 +231,8 @@ struct intelfb_hwstate {
struct intelfb_heap_data {
u32 physical;
u8 __iomem
Hi,
I'll attach 4 patches for Intel FB (i830+) here:
1/4 - whitespace, bracket and other clean-ups (rather long)
working with kernel-style brackets instead of:
void
function_name (int arg) {
is a bit easier. I think it would be best to apply it in
On Sat, Sep 22, 2007 at 10:40:02PM +0200, Sam Ravnborg wrote:
> On Sat, Sep 22, 2007 at 05:42:52PM +0200, Oleg Verych wrote:
> > * Sat, 22 Sep 2007 13:24:32 +0200 (CEST)
> > []
> > > The make O=$PWD truncates the Makefile, making it necessary to run `git
> > > checkout Makefile` - should you have
On 9/21/07, Huang, Ying <[EMAIL PROTECTED]> wrote:
> This is fairly simple in fact. For example, you can specify the
> bdev/sectors in kernel command line when do kexec load "kexec -l <...>
> --append='...'", then the image writing system can get it through
> "cat /proc/cmdline".
I hope you take
On Saturday, 22 September 2007 17:41, Christian P. Schmidt wrote:
> Hi all,
>
> I'm having a strange problem, of course not reproducible. Sometimes
> after a suspend (to ram) and resume cycle, the kernel will try to free
> all memory. This means, all running applications are flushed to swap (as
>
On Saturday, 22 September 2007 20:00, Kyle Moffett wrote:
> On Sep 22, 2007, at 06:34:17, Rafael J. Wysocki wrote:
> > On Saturday, 22 September 2007 01:19, Kyle Moffett wrote:
> >> On Sep 21, 2007, at 17:16:59, Jeremy Maitin-Shepard wrote:
> >>> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
>
Hello,
currently, the parport_pc driver doesn't use IRQs automatically for
PCI devices. However, why is it not possible? It's no problem to find
out the corresponding IRQ, and it should also be possible to use IRQ
sharing. The following patch implements this.
Could somebody tell me what's wrong
Yinghai Lu wrote:
On 9/22/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
Thomas Gleixner wrote:
On Sat, 2007-09-22 at 10:28 -0600, Robert Hancock wrote:
Yinghai Lu wrote:
No!
MMCONFIG will not work with acpi=off any more.
I don't think this is unreasonable. The ACPI MCFG table is how we are
On Sat, 2007-09-22 at 14:07 -0700, Davide Libenzi wrote:
> On Sat, 22 Sep 2007, Michael Kerrisk wrote:
>
> > So I'm inclined to implement option (b), unless someone has strong
> > objections. Davide, could I persuade you to help?
>
> I guess I better do, otherwise you'll continue to stress me
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> You can cause a recursion in kbuild/make with the following:
>
> make O=$PWD kernel/time.o
> make mrproper
>
> Of course no one would use O=$PWD (that's just the testcase),
> but this happened too often:
>
> /ws/linux/linux-2.6.23$ make
On Sat, 22 Sep 2007, Michael Kerrisk wrote:
> So I'm inclined to implement option (b), unless someone has strong
> objections. Davide, could I persuade you to help?
I guess I better do, otherwise you'll continue to stress me ;)
int timerfd_create(int clockid);
int timerfd_settime(int ufd, int
Yinghai Lu wrote:
>>> We all know how correct ACPI tables are. Specifications are nice,
>>> reality tells a different story.
>> MMCONFIG can't be used without ACPI in any case unless we know where the
>> table is using chipset-specific knowledge (i.e. reading the registers
>> directly). Doing
> Sigh. I need a real deep look inside that code to understand, why
> tx_reqs is not a requestlist but a freelist. Very intuitive naming :)
It *is* a list of requests: free ones -- the only kind this level of
driver is allowed to remember! ;)
Yeah, I had to go back and read the driver again
On Sat, Sep 22, 2007 at 01:24:32PM +0200, Jan Engelhardt wrote:
> Hi,
>
>
> You can cause a recursion in kbuild/make with the following:
>
> make O=$PWD kernel/time.o
> make mrproper
>
> Of course no one would use O=$PWD (that's just the testcase),
> but this happened too often:
>
>
On 9/22/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
> Yinghai Lu wrote:
> > No!
> >
> > MMCONFIG will not work with acpi=off any more.
>
> I don't think this is unreasonable. The ACPI MCFG table is how we are
> supposed to learn about the area in the first place. If we can't get the
> table
On 9/22/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
> Thomas Gleixner wrote:
> > On Sat, 2007-09-22 at 10:28 -0600, Robert Hancock wrote:
> >> Yinghai Lu wrote:
> >>> No!
> >>>
> >>> MMCONFIG will not work with acpi=off any more.
> >> I don't think this is unreasonable. The ACPI MCFG table is
On Sat, Sep 22, 2007 at 05:42:52PM +0200, Oleg Verych wrote:
> * Sat, 22 Sep 2007 13:24:32 +0200 (CEST)
> []
> > The make O=$PWD truncates the Makefile, making it necessary to run `git
> > checkout Makefile` - should you have git; or reextract the tarball
> > (should you /still/ have it). Well,
22-09-2007, Bernd Eckenfels:
> In article <[EMAIL PROTECTED]> you wrote:
>> it doesn't add value memset with a constant 0 is just as fast
>> (since the compiler knows it's 0) than any wrapper around it, and the
>> syntax around it is otherwise the same.
linux/arch/x86_64/lib/memset.S isn't
On Sat, 2007-09-22 at 13:14 -0700, David Brownell wrote:
> How's this? Note that the queue should already have been stopped,
> so I removed what should be an extra call (as well as fixing the
> comments).
Yeah, stop queue should be not necessary.
> - Dave
>
>
> From: Thomas Gleixner
On Saturday 22 September 2007 11:49:09 Michael Kerrisk wrote:
> John,
>
...snip...
>
> If the child terminated by calling exit(), regardless of whether it
> was done from inside a signal handler, then WIFEXITED() should test
> true, but WIFSIGNALED() will not. If you are seeing otherwise, then
How's this? Note that the queue should already have been stopped,
so I removed what should be an extra call (as well as fixing the
comments).
- Dave
From: Thomas Gleixner <[EMAIL PROTECTED]>
This patch fixes a longstanding race in the Ethernet gadget driver,
which can cause an oops on
On Sat, 22 Sep 2007, Hans de Goede wrote:
> >> Now call me naive, but I would expect a mass-storage devices with no
> >> partitions mounted to autosuspend when autosuspend is enabled for that
> >> device.
> >
> > Yes, that is naive. The driver has no way to tell whether or not any
> >
On Sat, Sep 22, 2007 at 04:45:28PM +0200, Paul Rolland (ポール・ロラン) wrote:
> Hello,
>
> > [PATCH] mac80211: fix initialisation when built-in
> > http://article.gmane.org/gmane.linux.kernel.wireless.general/5710/match=patch+mac80211+initialisation
> >
> > [PATCH] cfg80211: fix initialisation if
This saves some bytes on usual config here and allows inserting integer
overflow warning without pissing off printk-haters crowd later on.
textdata bss dec hex filename
2662791 195347 159744 3017882 2e0c9a vmlinux -O2 before
2662535 195347 159744 3017626 2e0b9a
Jeremy Fitzhardinge wrote:
>
> Do you actually need a linked list of data? This is similar to the
> changes to bzImage to support booting bzImage a paravirt environment,
> but I just proposed a pointer to a single info structure, along with a
> field to identify the boot environment (ie,
This patch just makes the version number in ips.c and ips.h consistent. It
seems that this has been forgotten in a60768e2d43eb30a1adb8a119aeac35dc0d03ef6.
It also removes code duplication, each number is now only once in the code to
avoid similar errors in the future.
Signed-off-by: Bernhard
On Sat, 2007-09-22 at 00:32 +0200, Andi Kleen wrote:
> From: Akinobu Mita <[EMAIL PROTECTED]>
>
> Do cpuid_device_create() in CPU_UP_PREPARE instead of CPU_ONLINE.
>
> Cc: "H. Peter Anvin" <[EMAIL PROTECTED]>
> Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
> Signed-off-by: Andi Kleen <[EMAIL
[Arjan van de Ven - Sat, Sep 22, 2007 at 12:46:59PM -0700]
| On Sat, 22 Sep 2007 12:33:55 +0400
| Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
|
| > Hi list,
| >
| > could anyone tell me why there is no official memzero function (or
| > macros) in the kernel.
|
| it doesn't add value memset
On Sat, 2007-09-22 at 12:18 -0700, David Brownell wrote:
> I think you misread my comment. Those requests are **NOT** pending!!
> So this update has a *MORE* incorrect description of the issue.
>
> That's just the freelist ... it's a fairly conventional model whereby
> there's a pool of "free"
After recent discussions on LKML and a general dissatisfaction at the
current printk() kernel-message logging interface, I've decided to
write down some of the ideas for a better system.
Requirements
* Backwards compatibility with printk(), syslog(), etc. There is no
way the whole
In article <[EMAIL PROTECTED]> you wrote:
> it doesn't add value memset with a constant 0 is just as fast
> (since the compiler knows it's 0) than any wrapper around it, and the
> syntax around it is otherwise the same.
it would however allow easier changing if you need to add a page cleaning
On Sat, 2007-09-22 at 00:32 +0200, Andi Kleen wrote:
> - notify_die(DIE_OOPS, str, regs, err, current->thread.trap_no, SIGSEGV);
> + if (notify_die(DIE_OOPS, str, regs, err, current->thread.trap_no,
> SIGSEGV) == NOTIFY_STOP)
80 chars please.
tglx
-
To unsubscribe from this
On Sat, 2007-09-22 at 00:32 +0200, Andi Kleen wrote:
> No functional changes
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Can we please fix _ALL_ white space and coding style issues in this file
while we are at it?
Updated patch below.
tglx
diff --git a/arch/x86_64/mm/init.c
I think you misread my comment. Those requests are **NOT** pending!!
So this update has a *MORE* incorrect description of the issue.
That's just the freelist ... it's a fairly conventional model whereby
there's a pool of "free" request slots which can be issued. When the
pool empties, the TX
On Sat, 2007-09-22 at 00:32 +0200, Andi Kleen wrote:
> Also allow to set svm lock.
Please use two separate patches. The detection and cpuinfo display is
not related to set svm lock.
> TBD double check, documentation, i386 support
Yes, documentation would be useful. See below.
> Signed-off-by:
On Sat, 22 Sep 2007, Arjan van de Ven wrote:
>
> it doesn't add value memset with a constant 0 is just as fast
> (since the compiler knows it's 0) than any wrapper around it, and the
> syntax around it is otherwise the same.
Indeed.
The reason we have "clear_page()" is not because the
On Sat, 2007-09-22 at 11:22 -0700, John Z. Bohach wrote:
> Hello,
>
> It is unclear from the various documentions in the kernel and glibc what
> the proper behaviour should be for the case when a child process
> catches a SIGNAL (say for instance, SIGTERM), and then calls exit()
> from within
John,
> It is unclear from the various documentions in the kernel and glibc what
> the proper behaviour should be for the case when a child process
> catches a SIGNAL (say for instance, SIGTERM), and then calls exit()
> from within its caught SIGNAL handler.
>
> Since the exit() will cause a
On Sat, 22 Sep 2007 12:33:55 +0400
Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
> Hi list,
>
> could anyone tell me why there is no official memzero function (or
> macros) in the kernel.
it doesn't add value memset with a constant 0 is just as fast
(since the compiler knows it's 0) than any
Thomas Gleixner wrote:
On Sat, 2007-09-22 at 10:28 -0600, Robert Hancock wrote:
Yinghai Lu wrote:
No!
MMCONFIG will not work with acpi=off any more.
I don't think this is unreasonable. The ACPI MCFG table is how we are
supposed to learn about the area in the first place. If we can't get the
This adds the documentation for the extended crashkernel syntax into
Documentation/kernel-parameters.txt.
Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>
---
Documentation/kernel-parameters.txt |7 +++
1 file changed, 7 insertions(+)
--- a/Documentation/kernel-parameters.txt
+++
This adds the documentation for the extended crashkernel syntax into
Documentation/kernel-parameters.txt.
Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>
---
Documentation/kernel-parameters.txt |7 +++
1 file changed, 7 insertions(+)
--- a/Documentation/kernel-parameters.txt
+++
Hello,
It is unclear from the various documentions in the kernel and glibc what
the proper behaviour should be for the case when a child process
catches a SIGNAL (say for instance, SIGTERM), and then calls exit()
from within its caught SIGNAL handler.
Since the exit() will cause a SIGCHLD to
Guillaume Chazarain wrote:
> TASKSTATS_CMD_ATTR_TGID used to return only the delay accounting stats, not
> the basic and extended accounting. With this patch,
> TASKSTATS_CMD_ATTR_TGID also aggregates the accounting info for all threads
> of a thread group.
>
> TASKSTATS_CMD_ATTR_PID output
On Sep 22, 2007, at 06:34:17, Rafael J. Wysocki wrote:
On Saturday, 22 September 2007 01:19, Kyle Moffett wrote:
On Sep 21, 2007, at 17:16:59, Jeremy Maitin-Shepard wrote:
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
The ACPI platform firmware is allowed to preserve information
accross
On Sat, 2007-09-22 at 10:28 -0600, Robert Hancock wrote:
> Yinghai Lu wrote:
> > No!
> >
> > MMCONFIG will not work with acpi=off any more.
>
> I don't think this is unreasonable. The ACPI MCFG table is how we are
> supposed to learn about the area in the first place. If we can't get the
>
On Fri, Sep 21, 2007 at 05:32:08PM -0400, Steven Rostedt wrote:
>
> --
> On Fri, 21 Sep 2007, Paul E. McKenney wrote:
>
> > On Thu, Sep 20, 2007 at 02:34:11PM -0400, Steven Rostedt wrote:
> > > In recent development of the RT kernel, some of our experimental code
> > > corrupted the rcu header.
On Sat, 2007-09-22 at 00:32 +0200, Andi Kleen wrote:
> From: "Oliver Pinter" <[EMAIL PROTECTED]>
>
> add cpu core name for arch/i386/Kconfig.cpu:Pentium 4 sections help
> add Pentium D for arch/i386/Kconfig.cpu
> add Pentium D for arch/x86_64/Kconfig
>
> Signed-off-by: Oliver Pinter <[EMAIL
On Sat, 22 Sep 2007 12:01:16 +0200 (CEST) Jan Engelhardt wrote:
>
> On Sep 22 2007 10:36, Satyam Sharma wrote:
> >> from arch/i386/boot/compressed/misc.c:14:
> >> include/asm/processor.h: In function $B!F(Jcpuid_count$B!G(J:
> > ^^
On Sat, 22 Sep 2007 10:23:25 -0400 Dave Jones wrote:
> On Sat, Sep 22, 2007 at 08:57:24AM +0200, Sam Ravnborg wrote:
>
> > > This seems like yet another list that will need to be perpetually
> > > kept up to date, and given 99% of users don't know the codename
> > > of their core, just the
From: Benedikt Spranger <[EMAIL PROTECTED]>
eth_start_xmit() can race against a disconnect interrupt in the gadget
device driver, which nukes all pending request. Right now we access the
pending request list unconditionally and dereference the request list
head itself in such a case, which
On Sat, 22 Sep 2007 01:41:17 -0700 (PDT) Matti Linnanvuori wrote:
> From: Matti Linnanvuori <[EMAIL PROTECTED]>
>
> Reference to two different conventions is unnecessarily unclear unless you
> know them already and requires seeking and reading another file for
> understanding.
Could you hit
* Oliver Pinter ([EMAIL PROTECTED]) wrote:
> it is Lepton's patch.
> Namesys boys, this patch is OK?
> Greg, I neither do find this patch in Linus's tree.
The point is, if it's not important enough to go into Linus' tree, than
it isn't important enough to be in the -stable tree. So please get
On Sat, Sep 22, 2007 at 03:04:47AM -0400, Kyle Moffett wrote:
> On Sep 21, 2007, at 17:32:08, Steven Rostedt wrote:
> >On Fri, 21 Sep 2007, Paul E. McKenney wrote:
> >>On Thu, Sep 20, 2007 at 02:34:11PM -0400, Steven Rostedt wrote:
> >>>-#define RCU_HEAD_INIT { .next = NULL, .func = NULL }
>
Alan Stern wrote:
On Sat, 22 Sep 2007, Hans de Goede wrote:
I'm afraid that that doesn't work for usb mass-storage devices.
Here is what I did:
1) kill hal
2) insert usb stick -> led lights
3):
echo -n 1 >/sys/bus/usb/devices/.../power/autosuspend
echo -n auto >
Michael,
On Sat, 2007-09-22 at 15:12 +0200, Michael Kerrisk wrote:
> Davide, Andrew, Linus, et al.
>
> At the start of this thread
> (http://thread.gmane.org/gmane.linux.kernel/581115 ), I proposed 4
> alternatives to Davide's original timerfd API. Based on the feedback in
> that thread (and
1 - 100 of 338 matches
Mail list logo
