Ulrich Drepper a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Dumazet wrote:
1) Can the fd passing with recvmsg() on AF_UNIX also gets O_CLOEXEC
support ?
Already there, see MSG_CMSG_CLOEXEC.
OK, but maybe for consistency, we might accept the two mechanisms.
The one added in
wait_task_stopped() doesn't need the delay_group_leader parameter. If the
child is not traced it must be a group leader. With or without subthreads
What do you mean has to be a group leader? It could be a stopped thread.
-group_stop_count == 0 when the whole task is stopped.
On Sat, 24 Nov 2007 12:11:04 +1100, Benjamin Herrenschmidt wrote:
On Fri, 2007-11-23 at 23:29 +0100, Jean Delvare wrote:
On Fri, 23 Nov 2007 17:00:52 +0100, Michael Buesch wrote:
This patch fixes my crash problem.
Out of curiosity, what kind of crash was it? I admit that I can't see
Torsten, could you ack/nack this patch?
Torsten Kaiser wrote:
static inline int in_range(const void *start, const void *addr, const void
*end)
{
return addr = start addr = end;
}
This will return true, if addr is in the range of start (including)
to end (including).
But
On Fri, Nov 23, 2007 at 04:52:39PM +0100, BERTRAND Joël wrote:
BERTRAND Joël wrote:
Hello,
Since I have installed a 2.6.23.1 linux kernel on my U60, I can see
several NETDEV WATCHDOG. This trouble never occurs with 2.6.23-rc4.
This bug occurs after a random uptime.
I have
Casey Schaufler wrote:
--- Andrew Morgan [EMAIL PROTECTED] wrote:
I do have a question about whether one capability is sufficient in
general for MAC. Looking at the:
http://wt.xpilot.org/publications/posix.1e/download.html
last draft, there are no less than 5 capabilities (p173) allocated
Andrew Morgan wrote:
Its not so much why you are wrong, as being clear that we're not using a
generic name and inadvertently limiting ourselves to a SMACK-like model...
It seems we all agree that it is a bad idea to tie a POSIX Capability to
one specific LSM model.
It feels to me as if a
Hi, Andrew
Hi, Andrew
I got following result in 'sync' command.
It was too slow. (memory controller config is off ;)
I attaches my .config.
==
(snip)
Well I wonder how we did that.
It seems OK here from a quick test (i386, ext3-on-IDE).
Maybe device driver/block breakage?
Hello,
What happened in the attached messages?
It was on a VIA Epia EN12000, while compiling.
Yes, the machine has been stable before and after that issue.
So I suspect no hardware issues.
Kind regards,
Udo
messages.recorder.gz
Description: application/gzip
On Nov 24, 2007 11:53 AM, Oleg Nesterov [EMAIL PROTECTED] wrote:
Torsten, could you ack/nack this patch?
From looking at the code I would ack it.
I will reapply agk-dm-dm-crypt-move-bio-submission-to-thread.patch and
this patch and boot several times, but as the message was not
triggered on
* Oleg Nesterov [EMAIL PROTECTED] wrote:
But debug_check_no_locks_freed() seems does:
const void *mem_to = mem_from + mem_len
- mem_to is the last byte of the freed range, that fits in_range
lock_from = (void *)hlock-instance;
- first byte of the lock
lock_to = (void
On 11/24, Torsten Kaiser wrote:
On Nov 24, 2007 11:53 AM, Oleg Nesterov [EMAIL PROTECTED] wrote:
Torsten, could you ack/nack this patch?
From looking at the code I would ack it.
Great.
I will reapply agk-dm-dm-crypt-move-bio-submission-to-thread.patch and
this patch and boot several
On Sat, Nov 24, 2007 at 01:18:35PM +0100, Torsten Kaiser wrote:
I will reapply agk-dm-dm-crypt-move-bio-submission-to-thread.patch and
this patch and boot several times
OK for a test system, but until the write loop problem is addressed I believe
there's a risk of data corruption under low
On Sat, Nov 24, 2007 at 03:53:34PM +1100, Rusty Russell wrote:
So, you're saying that there's a problem with in-tree modules using symbols
they shouldn't? Can you give an example?
I believe that is fairly important in tree too because the
kernel has become so big now that review cannot
Le 24.11.2007 07:42, James Bottomley a écrit :
On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote:
Le 23.11.2007 12:38, Hannes Reinecke a écrit :
Hannes Reinecke wrote:
Laurent Riffard wrote:
Le 21.11.2007 23:41, Andrew Morton a écrit :
On Wed, 21 Nov 2007 22:45:22 +0100
Laurent
Unable to handle kernel paging request at virtual address c3c0
pgd = c3a5c000
[c3c0] *pgd=
Internal error: Oops: f5 [#1]
Modules linked in: dm642 mv_sata ixp400_eth ixp400
CPU: 0
PC is at .c2u_0cpynopld+0x8/0x24
LR is at mpeg_read+0x19c/0x35c [dm642]
pc : [c0106934]lr :
On Sat 24 Nov 2007 02:15, Bryan Wu pondered:
On Nov 24, 2007 2:43 PM, David Woodhouse [EMAIL PROTECTED] wrote:
On Fri, 2007-11-23 at 17:04 -0500, Robin Getz wrote:
It could be a runtime if() but we don't currently have the is_mach() all
set up properly today.
This is because on
Steffen Klassert wrote:
On Fri, Nov 23, 2007 at 04:52:39PM +0100, BERTRAND Joël wrote:
BERTRAND Joël wrote:
Hello,
Since I have installed a 2.6.23.1 linux kernel on my U60, I can see
several NETDEV WATCHDOG. This trouble never occurs with 2.6.23-rc4.
This bug occurs after a random
On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote:
Le 24.11.2007 07:42, James Bottomley a écrit :
On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote:
Le 23.11.2007 12:38, Hannes Reinecke a écrit :
Hannes Reinecke wrote:
Laurent Riffard wrote:
Le 21.11.2007 23:41, Andrew
On Friday 23 November 2007 23:29:28 Jean Delvare wrote:
On Fri, 23 Nov 2007 17:00:52 +0100, Michael Buesch wrote:
This patch fixes my crash problem.
Out of curiosity, what kind of crash was it? I admit that I can't see
how the code could crash.
It's not the code that crashes. It's the
On Fri, 23 Nov 2007 00:15:53 + (GMT)
Daniel Drake [EMAIL PROTECTED] wrote:
Being spoilt by the luxuries of i386/x86_64 I've never really had a good
grasp on unaligned memory access problems on other architectures and decided
it was time to figure it out. As a result I've written this
On Wed, Nov 21, 2007 at 10:58:21AM +0100, Sam Ravnborg wrote:
On Wed, Nov 21, 2007 at 10:44:40AM +0200, Avi Kivity wrote:
Kamalesh Babulal wrote:
Andrew Morton wrote:
On Wed, 21 Nov 2007 13:54:50 +0530 Kamalesh Babulal
[EMAIL PROTECTED] wrote:
The make headers_check
On Wed, 21 Nov 2007 12:33:45 +0100
Andre Haupt [EMAIL PROTECTED] wrote:
I think, the status paramter should be unsigned. Is this correct?
This also fixes a sparse warning about different signedness.
Only compile tested, because i do not have the hardware.
From: Andre Haupt [EMAIL PROTECTED]
wuhm schrieb:
Unable to handle kernel paging request at virtual address c3c0
pgd = c3a5c000
[c3c0] *pgd=
Internal error: Oops: f5 [#1]
Modules linked in: dm642 mv_sata ixp400_eth ixp400
dm642 is an out-of-tree module. Contact the author of that module.
CPU: 0
PC is at
Imho, the current usage of security_task_wait() is not logical.
Suppose we have the single child p, and security_task_wait(p) return -EANY.
In that case waitpid(-1) returns this error. Why? Isn't it better to return
ECHLD? We don't really have the reapable childs.
Now suppose that child was
On Sat, 24 Nov 2007, Pierre Ossman wrote:
On Wed, 21 Nov 2007 12:33:45 +0100
Andre Haupt [EMAIL PROTECTED] wrote:
I think, the status paramter should be unsigned. Is this correct?
This also fixes a sparse warning about different signedness.
Only compile tested, because i do not have the
On Sat, Nov 24, 2007 at 02:34:41PM +0100, Pierre Ossman wrote:
On Fri, 23 Nov 2007 00:15:53 + (GMT)
Daniel Drake [EMAIL PROTECTED] wrote:
Being spoilt by the luxuries of i386/x86_64 I've never really had a good
grasp on unaligned memory access problems on other architectures and
On Nov 24, 2007 12:28 AM, Eric Dumazet [EMAIL PROTECTED] wrote:
OK, but maybe for consistency, we might accept the two mechanisms.
It's not a question of the kernel interface. The issue with all these
extensions is the userlevel interface. Ideally no new userlevel
interface is needed. This is
On Sat, 24 Nov 2007 15:50:52 +
Luciano Rocha [EMAIL PROTECTED] wrote:
Dumb memcpy (while (len--) { *d++ = *s++ }) will have alignment problems
in any case. Intelligent ones, like the one provided in glibc, first copy
bytes till output is aligned (C file) *or* size is a multiple (i686 asm
Surprise, other 2 wait_task_() functions also abuse task_pid_nr_ns(). May cause
read-after-free or report nr == 0 in wait_task_continued(). wait_task_zombie()
doesn't have this problem, but still it is better to cache pid_t rather than
call task_pid_nr_ns() 3 times on the saved pid_namespace.
On Fri, 23 Nov 2007 13:20:13 +0100
Haavard Skinnemoen [EMAIL PROTECTED] wrote:
This is a driver for the MMC controller on the AP7000 chips from
Atmel. It should in theory work on AT91 systems too with some
tweaking, but since the DMA interface is quite different, it's not
entirely clear if
The Coverity checker spotted the following check-after-use in
fs/cifs/cifsacl.c:
-- snip --
...
static void parse_dacl(struct cifs_acl *pdacl, char *end_of_acl,
struct cifs_sid *pownersid, struct cifs_sid *pgrpsid,
struct inode *inode)
{
...
On Sat, Nov 24, 2007 at 05:19:31PM +0100, Pierre Ossman wrote:
On Sat, 24 Nov 2007 15:50:52 +
Luciano Rocha [EMAIL PROTECTED] wrote:
Dumb memcpy (while (len--) { *d++ = *s++ }) will have alignment problems
in any case. Intelligent ones, like the one provided in glibc, first copy
The first p-exit_state != EXIT_ZOMBIE check doesn't make too much sense. The
exit_state was EXIT_ZOMBIE when the function was called, and another thread can
change it to EXIT_DEAD right after the check.
The second condition is not possible, detached non-traced threads were already
filtered out by
It looks like the jiffies counter sometimes jumps back and forth of some
hundreds seconds in 2.6.24-rc3. I observed that this happens when I use the
su(1) command, e.g.:
Nov 24 06:17:17 morte [190769.065301] wmaster0: STA 00:14:c1:35:8d:eb Average
rate: 232 (6730/29)
Nov 24 06:17:22 morte
I just booted 2.6.24-rc3 on two different PCs, one with i945 based MSI
motherboard and i386 kernel and one with i945 based Apple motherboard
and x86-64 kernel. Before that I ran linux 2.6.23.
On both PCs, sensors exits with
No sensors found!
Make sure you loaded all the kernel drivers you
On Sat, 24 Nov 2007 17:22:36 +
Luciano Rocha [EMAIL PROTECTED] wrote:
On Sat, Nov 24, 2007 at 05:19:31PM +0100, Pierre Ossman wrote:
It most certainly does not. gcc will assume that an int* has int alignment.
memcpy() is a builtin, which gcc can translate to pretty much anything. And
Stefan Richter wrote:
I just booted 2.6.24-rc3 on two different PCs, one with i945 based MSI
motherboard and i386 kernel and one with i945 based Apple motherboard
and x86-64 kernel. Before that I ran linux 2.6.23.
On both PCs, sensors exits with
No sensors found!
now logged at
Probing intermittent failures in Domain Validation, even with the fixes
applied leads me to the conclusion that there are further problems with
this commit:
commit fc5eb4facedbd6d7117905e775cee1975f894e79
Author: Hannes Reinecke [EMAIL PROTECTED]
Date: Tue Nov 6 09:23:40 2007 +0100
[SCSI]
James Bottomley wrote:
On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote:
Le 24.11.2007 07:42, James Bottomley a écrit :
On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote:
Le 23.11.2007 12:38, Hannes Reinecke a écrit :
Hannes Reinecke wrote:
Laurent Riffard wrote:
Le
On Sat, 24 Nov 2007 17:22:36 +
Luciano Rocha [EMAIL PROTECTED] wrote:
Nothing does, even memcpy doesn't check alignment of the source, or
alignment at all in some assembly implementations (only word-copy,
without checking if at word-boundary).
An out-of-line implementation can only do
Stefano Brivio wrote:
It looks like the jiffies counter sometimes jumps back and forth of some
hundreds seconds in 2.6.24-rc3. I observed that this happens when I use
the su(1) command, e.g.:
Can you please explain what exactly the problem is here?
Are you perhaps referring to the number
On Sat, 2007-11-24 at 18:54 +0100, Gabriel C wrote:
James Bottomley wrote:
On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote:
Le 24.11.2007 07:42, James Bottomley a écrit :
On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote:
Le 23.11.2007 12:38, Hannes Reinecke a écrit :
kosaki wrote:
Hi, Andrew
Hi, Andrew
I got following result in 'sync' command.
It was too slow. (memory controller config is off ;)
I attaches my .config.
==
(snip)
Well I wonder how we did that.
It seems OK here from a quick test (i386, ext3-on-IDE).
Maybe device driver/block
On Saturday, 24 of November 2007, Jan-Simon Möller wrote:
Am Freitag 23 November 2007 08:21:09 schrieb Andrew Morton:
On Tue, 13 Nov 2007 21:55:15 +0100 Jan-Simon M__ller [EMAIL PROTECTED]
wrote:
Hi!
You removed from cc the guys who are most likely to fix this. Please
always do
James Bottomley wrote:
On Sat, 2007-11-24 at 18:54 +0100, Gabriel C wrote:
James Bottomley wrote:
On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote:
Le 24.11.2007 07:42, James Bottomley a écrit :
On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote:
Le 23.11.2007 12:38, Hannes
On Sat, 24 Nov 2007 18:56:57 +0100
Frans Pop [EMAIL PROTECTED] wrote:
Stefano Brivio wrote:
It looks like the jiffies counter sometimes jumps back and forth of some
hundreds seconds in 2.6.24-rc3. I observed that this happens when I use
the su(1) command, e.g.:
Can you please explain
On Sat, 24 Nov 2007 18:00:23 +0100
Pierre Ossman [EMAIL PROTECTED] wrote:
On Fri, 23 Nov 2007 13:20:13 +0100
Haavard Skinnemoen [EMAIL PROTECTED] wrote:
This is a driver for the MMC controller on the AP7000 chips from
Atmel. It should in theory work on AT91 systems too with some
Simon, can you test this patch? I think it's the most straightforward
2.6.24 fix.
diff -r c60016ba6237 net/core/netpoll.c
--- a/net/core/netpoll.cTue Nov 13 09:09:36 2007 -0800
+++ b/net/core/netpoll.cFri Nov 23 13:10:28 2007 -0600
@@ -203,6 +203,12 @@ static void
Gabriel C wrote:
James Bottomley wrote:
On Sat, 2007-11-24 at 18:54 +0100, Gabriel C wrote:
James Bottomley wrote:
On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote:
Le 24.11.2007 07:42, James Bottomley a écrit :
On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote:
Le 23.11.2007
On Sat, Nov 24, 2007 at 06:35:25PM +0100, Pierre Ossman wrote:
On Sat, 24 Nov 2007 17:22:36 +
Luciano Rocha [EMAIL PROTECTED] wrote:
On Sat, Nov 24, 2007 at 05:19:31PM +0100, Pierre Ossman wrote:
It most certainly does not. gcc will assume that an int* has int
alignment. memcpy()
On Saturday, 24 of November 2007, Stefano Brivio wrote:
It looks like the jiffies counter sometimes jumps back and forth of some
hundreds seconds in 2.6.24-rc3. I observed that this happens when I use the
su(1) command, e.g.:
Nov 24 06:17:17 morte [190769.065301] wmaster0: STA
On Saturday, 24 of November 2007, Udo van den Heuvel wrote:
Hello,
What happened in the attached messages?
It was on a VIA Epia EN12000, while compiling.
Yes, the machine has been stable before and after that issue.
So I suspect no hardware issues.
Which kernel is this?
Rafael
-
To
On Fri, Nov 23, 2007 at 01:01:15PM +0100, Andi Kleen wrote:
On Fri, Nov 23, 2007 at 03:03:29PM +1100, David Chinner wrote:
On Fri, Nov 23, 2007 at 03:53:17AM +0100, Andi Kleen wrote:
On Fri, Nov 23, 2007 at 12:15:39AM +1100, David Chinner wrote:
On Thu, Nov 22, 2007 at 01:06:11PM +0100,
Rafael J. Wysocki wrote:
On Saturday, 24 of November 2007, Udo van den Heuvel wrote:
Hello,
What happened in the attached messages?
It was on a VIA Epia EN12000, while compiling.
Yes, the machine has been stable before and after that issue.
So I suspect no hardware issues.
Which kernel
On Sat, 24 Nov 2007 19:48:58 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
NO_HZ? Highres timers?
CONFIG_HZ_1000=y
# CONFIG_HIGH_RES_TIMERS is not set
I understand that the previous kernels behave correctly. All of them?
2.6.21 behaved correctly. Sorry but git-bisect would take a lot
On Saturday, 24 of November 2007, Bartlomiej Zolnierkiewicz wrote:
[--snip--]
Rafael, I see that you've filled a bug for this bugreport into kernel
bugzilla tracker (one day after the bugreport):
http://bugzilla.kernel.org/show_bug.cgi?id=9442
Since we try to address regressions with
On Saturday 24 November 2007, Haavard Skinnemoen wrote:
Why is this needed and is it perhaps something that can be moved to
the MMC core?
We used to have lots of problems with overruns and underruns and those
parameters were useful to limit the transfer rate. Now that the RDPROOF
and
Len Brown ha scritto:
On Thursday 22 November 2007 02:24, [EMAIL PROTECTED] wrote:
It is also important to note that this bug always comes with bug 8740
http://bugzilla.kernel.org/show_bug.cgi?id=8740 (also confirmed and also
an ACPI issue).
No, 8740 is not an ACPI issue.
Len Brown ha scritto:
On Sunday 21 October 2007 05:43, [EMAIL PROTECTED] wrote:
have emerged lm_sensors but can't get it running - it keeps saying No
sensors found! and complaining about kernel drivers not properly setup.
I have attached the output of sensors-detect, from which it seems that
--- Crispin Cowan [EMAIL PROTECTED] wrote:
Andrew Morgan wrote:
Its not so much why you are wrong, as being clear that we're not using a
generic name and inadvertently limiting ourselves to a SMACK-like model...
It seems we all agree that it is a bad idea to tie a POSIX Capability to
atl1: disable broken 64-bit DMA
[ Upstream commit: 5f08e46b621a769e52a9545a23ab1d5fb2aec1d4 ]
The L1 network chip can DMA to 64-bit addresses, but multiple descriptor
rings share a single register for the high 32 bits of their address, so
only a single, aligned, 4 GB physical address range can
On Sat, 24 Nov 2007 10:48:39 -0800
David Brownell [EMAIL PROTECTED] wrote:
On Saturday 24 November 2007, Haavard Skinnemoen wrote:
Why is this needed and is it perhaps something that can be moved
to the MMC core?
We used to have lots of problems with overruns and underruns and
On Saturday, 24 of November 2007, Stefano Brivio wrote:
On Sat, 24 Nov 2007 19:48:58 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
NO_HZ? Highres timers?
CONFIG_HZ_1000=y
# CONFIG_HIGH_RES_TIMERS is not set
I understand that the previous kernels behave correctly. All of them?
On Saturday, 24 of November 2007, Frans Pop wrote:
On Saturday 24 November 2007, Bartlomiej Zolnierkiewicz wrote:
Unfortunately I'm unable to reproduce this with:
* VirtualBox 1.5.2 from http://www.virtualbox.org
(VirtualBox-1.5.2_25433_fedora7-1.i586.rpm)
* Fedora 7 with
On Fri, Nov 23, 2007 at 11:20:55PM +, Phil Endecott wrote:
Dear Experts,
NFS doesn't work with inotify (and it looks like it can't, certainly not
before NFS v4.1). However, if I give an NFS filename to
inotify_add_watch(), I don't get an error.
If it indicated an error in this case
J. Bruce Fields wrote:
On Fri, Nov 23, 2007 at 11:20:55PM +, Phil Endecott wrote:
Dear Experts,
NFS doesn't work with inotify (and it looks like it can't, certainly not
before NFS v4.1). However, if I give an NFS filename to
inotify_add_watch(), I don't get an error.
If it indicated
Stefan Richter wrote:
I just booted 2.6.24-rc3 on two different PCs, one with i945 based MSI
motherboard and i386 kernel and one with i945 based Apple motherboard
and x86-64 kernel. Before that I ran linux 2.6.23.
On both PCs, sensors exits with
No sensors found!
now logged at
This message contains a list of some regressions from 2.6.23 which have been
reported since 2.6.24-rc1 was released and for which there are no fixes in the
mainline that I know of. If any of them have been fixed already, please let me
know.
If you know of any other unresolved regressions from
I have no COM port on notebook (without port replicator which I do not have)
so COM is disabled in BIOS. No ttyS* is detected during boot (and no device
created) but I just noticed that serial modules are still loaded. Well, this
partially defeats the purpose of disabling COM port - the intention
On Sat, Nov 24, 2007 at 08:11:45PM +, Phil Endecott wrote:
J. Bruce Fields wrote:
On Fri, Nov 23, 2007 at 11:20:55PM +, Phil Endecott wrote:
Dear Experts,
NFS doesn't work with inotify (and it looks like it can't, certainly not
before NFS v4.1). However, if I give an NFS filename
Compliment va_start() with va_end().
Signed-off-by: Richard Knutsson [EMAIL PROTECTED]
---
Compile-tested on i386 with allyesconfig allmodconfig.
utdebug.c |2 ++
utmisc.c |4
2 files changed, 6 insertions(+)
diff --git a/drivers/acpi/utilities/utdebug.c
Make a single va_start() - va_end() path + fixing:
CHECK /home/kernel/src/net/irda/parameters.c
/home/kernel/src/net/irda/parameters.c:466:2: warning: Using plain integer as
NULL pointer
/home/kernel/src/net/irda/parameters.c:520:2: warning: Using plain integer as
NULL pointer
On Sat, 24 Nov 2007, Michael Kerrisk wrote:
+asmlinkage long sys_timerfd_create(int clockid, int flags)
{
- int error;
+ int error, ufd;
struct timerfd_ctx *ctx;
struct file *file;
struct inode *inode;
- struct itimerspec ktmr;
-
- if (copy_from_user(ktmr,
Compliment va_start() with va_end().
Signed-off-by: Richard Knutsson [EMAIL PROTECTED]
---
ieee754.c |2 ++
ieee754dp.c |2 ++
ieee754sp.c |2 ++
3 files changed, 6 insertions(+)
diff --git a/arch/mips/math-emu/ieee754.c b/arch/mips/math-emu/ieee754.c
index 946aee3..cb1b682
thanks, applied.
-
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 FAQ at http://www.tux.org/lkml/
to., 04.10.2007 kl. 10.02 +1000, skrev Rusty Russell:
On Wed, 2007-10-03 at 10:37 +0100, Chris Malley wrote:
Hi guys
Would it not be clearer to #include asm/bootparam.h and use
the relevant named members of struct setup_header / struct boot_params
rather than the hard-coded values
Compliment va_copy() with va_end().
Signed-off-by: Richard Knutsson [EMAIL PROTECTED]
---
Compile-tested on i386 with allyesconfig allmodconfig.
diff --git a/kernel/audit.c b/kernel/audit.c
index f93c271..836626c 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1245,6 +1245,7 @@ static
Kjartan Maraas wrote:
to., 04.10.2007 kl. 10.02 +1000, skrev Rusty Russell:
On Wed, 2007-10-03 at 10:37 +0100, Chris Malley wrote:
Hi guys
Would it not be clearer to #include asm/bootparam.h and use
the relevant named members of struct setup_header / struct boot_params
rather than the
On Sat, 24 Nov 2007 15:18:26 +0100, Michael Buesch wrote:
On Friday 23 November 2007 23:29:28 Jean Delvare wrote:
Out of curiosity, what kind of crash was it? I admit that I can't see
how the code could crash.
It's not the code that crashes. It's the hardware that turns off the machine.
Very strange indeed. Another possibility is that there is a hardware
monitoring chip connected to one of the Radeon adapter's I2C buses, and
that holding the I2C lines prevents reading from it, so whatever is
responsible for controlling the temperature prefers to play it safe and
shuts
On Thu 2007-11-22 21:29:51, Thomas Gleixner wrote:
On Thu, 22 Nov 2007, Pavel Machek wrote:
but perhaps somehow we miss this fact and fail to turn off the lapic
clockevents drivers?
Ok, I guess I'm lost. If I offline second CPU, I immediately get
1000Hz timer tick... is that
Hi!
but perhaps somehow we miss this fact and fail to turn off the lapic
clockevents drivers?
Ok, I guess I'm lost. If I offline second CPU, I immediately get
1000Hz timer tick... is that expected?
Hmm. No. I have no idea why this is happening.
34196 total events, 55.083
[PATCH] x86_64: not set boot cpu in cpu_online_map at x86_64_start_kernel
in init/main.c boot_cpu_init() does that later
Signed-off-by: Yinghai Lu [EMAIL PROTECTED]
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 6b34693..82b9f03 100644
--- a/arch/x86/kernel/head64.c
+++
[PATCH] x86_64: not set boot cpu in cpu_present_map again
in init/main.c boot_cpu_init() already does that before setup_arch
Signed-off-by: Yinghai Lu [EMAIL PROTECTED]
diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
index 30d94d1..9905c45 100644
---
Le 24.11.2007 14:26, James Bottomley a écrit :
On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote:
Le 24.11.2007 07:42, James Bottomley a écrit :
On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote:
Le 23.11.2007 12:38, Hannes Reinecke a écrit :
[snip]
I can confirm : reverting
On Nov 24, 2007 12:36 PM, Andrey Borzenkov [EMAIL PROTECTED] wrote:
I have no COM port on notebook (without port replicator which I do not have)
so COM is disabled in BIOS. No ttyS* is detected during boot (and no device
created) but I just noticed that serial modules are still loaded. Well,
On Saturday, 24 of November 2007, Pavel Machek wrote:
Hi!
but perhaps somehow we miss this fact and fail to turn off the lapic
clockevents drivers?
Ok, I guess I'm lost. If I offline second CPU, I immediately get
1000Hz timer tick... is that expected?
Hmm. No. I have no
Hi Sam,
On Sunday 18 November 2007 15:00, Sam Ravnborg wrote:
On Tue, Sep 11, 2007 at 09:05:33PM +0100, Denys Vlasenko wrote:
Build system: section garbage collection for vmlinux
Newer gcc and binutils can do dead code and data removal
at link time. It is achieved using combination of
On Sunday, 25 of November 2007, Rafael J. Wysocki wrote:
On Saturday, 24 of November 2007, Pavel Machek wrote:
Hi!
but perhaps somehow we miss this fact and fail to turn off the lapic
clockevents drivers?
Ok, I guess I'm lost. If I offline second CPU, I immediately get
On Saturday 24 November 2007 15:14, Denys Vlasenko wrote:
2.modpost
Update scripts/mod/* machinery to correctly handle the case
when we have more than 64k sections.
Signed-off-by: Denys Vlasenko [EMAIL PROTECTED]
--
vda
diff -urpN linux-2.6.gc1/scripts/mod/file2alias.c
On Saturday 24 November 2007 15:14, Denys Vlasenko wrote:
3.gc
The meat of the patchset is here.
Introduce config option DISCARD_UNUSED_SECTIONS.
If it is selected:
Pass -ffunction-sections -fdata-sections to gcc and
--gc-sections --print-gc-sections to ld.
Use
Ok. I have kicked around a lot implementation ideas and took a good hard
look at my /proc/net implementation. The patch below should close all
of the holes with /proc/net that I am aware of.
Bind mounts work and properly capture /proc/net/
stat of /proc/net and /proc/net/ return the same
Hi,
I have recently assembled a Core 2 Duo system with 4GB RAM and I believe there
might be a bug in the r8169 driver in 4GB RAM configurations.
Initially I can use one of two active r8169 NICs on the motherboard with this
quantity of RAM with other devices, without issue. But after some
[ I removed Frans from cc: since it is off-topic to the original bugreport ]
On Saturday 24 November 2007, Rafael J. Wysocki wrote:
On Saturday, 24 of November 2007, Bartlomiej Zolnierkiewicz wrote:
[--snip--]
Rafael, I see that you've filled a bug for this bugreport into kernel
bugzilla
Alistair John Strachan [EMAIL PROTECTED] :
[...]
The choke affects other devices on the system too, notably libata, which
does not recover gracefully. In my logs, I see a stream of:
DMA: Out of SW-IOMMU space for 7222 bytes at device :04:00.0
DMA: Out of SW-IOMMU space for 7222 bytes at
when these messages appear, removing r8169 would appear to be key. Indeed, if
there is no significant libata activity, the problem still occurs on the NIC
within approximately the same amount of transfer.
You seem to have a leak, which actually isn't suprising
rtl8169_xmit_frags
No Message Collected
-
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 FAQ at http://www.tux.org/lkml/
Alan Cox [EMAIL PROTECTED] :
[...]
You seem to have a leak, which actually isn't suprising
rtl8169_xmit_frags allocates a set of maps for a fragmented packet
rtl8169_start_xmit allocates a buffer
When we finish the transit we free the main buffer (always using skb-len
when
This fixes only symptom, not illness.
This check represent what code think about filesystem layout.
On what actually kind of UFS system did you test this patch?
When I sometime ago fixed similar issue for openstep ufs,
actully this was darwin's ufs which has the same layout,
I just set
1 - 100 of 242 matches
Mail list logo
