On Wed, 28 Feb 2007 15:14:20 -0800, David Brownell wrote:
The writing on the wall seem to be that the parport stack is orphaned,
rather than maintained by four folk ... and having a webpage that says
the latest patches are based on a 2.5 kernel.
I share David's impression here. Andrew, can you
On Thu, 1 Mar 2007 00:54:32 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Since freezable workqueues are broken in 2.6.21-rc
(cf. http://marc.theaimsgroup.com/?l=linux-kernelm=116855740612755,
http://marc.theaimsgroup.com/?l=linux-kernelm=117261312523921w=2)
it's better to change the only
On Wed, 28 Feb 2007 22:23:41 -0800 (PST) David Miller [EMAIL PROTECTED] wrote:
That all looks rather deliberate.
powerpc/kernel/process.c: t-flags ^= (_TIF_ABI_PENDING |
_TIF_32BIT);
ia64/kernel/mca.c: ti-flags = _TIF_MCA_INIT;
avr32/kernel/ptrace.c:
On Wed, Feb 28, 2007 at 04:14:14PM +, Pavel Machek ([EMAIL PROTECTED])
wrote:
Hi!
I think what you are not hearing, and what everyone else is saying
(INCLUDING Linus), is that for most programmers, state machines are
much, much harder to program, understand, and debug compared to
Currently sm501fb_crtsrc_store() won't allow the routing to be changed
via echos from userspace in to the sysfs file. The reason for this is
that the strnicmp() for both heads uses a sizeof() for the string length,
which ends up being strlen() + 1 (\0 in the normal case, but the echo
gives a
On Thu, 1 Mar 2007 14:56:40 +1100 [EMAIL PROTECTED] (Tony Breeds) wrote:
From: Tony Breeds [EMAIL PROTECTED]
Fix soft lockup with iSeries viocd driver, caused by eventually calling
end_that_request_first() with nr_bytes 0.
The lockup is triggered by hald, interrogating the device.
What
On Wed, Feb 28, 2007 at 11:42:24AM -0800, Davide Libenzi
(davidel@xmailserver.org) wrote:
On Wed, 28 Feb 2007, Chris Friesen wrote:
Davide Libenzi wrote:
struct async_syscall {
unsigned long nr_sysc;
unsigned long params[8];
long *result;
};
And what would
On Thu, 1 Mar 2007 00:37:48 -0800 Andrew Morton [EMAIL PROTECTED] wrote:
On Thu, 1 Mar 2007 14:56:40 +1100 [EMAIL PROTECTED] (Tony Breeds) wrote:
From: Tony Breeds [EMAIL PROTECTED]
Fix soft lockup with iSeries viocd driver, caused by eventually calling
end_that_request_first() with
* Mike Galbraith [EMAIL PROTECTED] wrote:
I see no real difference between the two assertions. Nice is just a
mechanism to set priority, so I applied your assertion to a different
range of priorities than nice covers, and returned it to show that the
code contradicts itself. It can't be
On Thu, 01 Mar 2007 12:15:29 +0800 Wu, Bryan [EMAIL PROTECTED] wrote:
+/* check if the mac in reg is valid */
+#define SMC_GET_MAC_ADDR(addr) \
+ do {\
+ unsigned int __v;
On Tue, 2007-02-27 at 10:25 +0100, Mike Galbraith wrote:
On Sun, 2007-02-25 at 09:32 +0100, Mike Galbraith wrote:
Fix NULL pointer dereference in cmos_rtc registration failure path.
Signed-off-by: Mike Galbraith [EMAIL PROTECTED]
diff --git a/drivers/rtc/class.c
On 24/02/07 15:19, Simon Arlott wrote:
I've modified the driver of an USB device (cxacru) to schedule the next poll
for status every 1s using round_jiffies_relative instead of just waiting 1s
since the last poll was completed. This process takes on average 11ms to
complete and while it is
Hi!
Since freezable workqueues are broken in 2.6.21-rc
(cf. http://marc.theaimsgroup.com/?l=linux-kernelm=116855740612755,
http://marc.theaimsgroup.com/?l=linux-kernelm=117261312523921w=2)
it's better to change the only user of them, which is XFS, to use normal
nonfreezable workqueues.
On Thu, Mar 01, 2007 at 12:15:46PM +0800, Wu, Bryan wrote:
+#define stamp(fmt, args...) pr_debug(%s:%i: fmt \n, __FUNCTION__,
__LINE__, ## args)
+#define stampit() stamp(here i am)
+
Are these really necessary for the final driver? It's littered all over
the place, and presumably the driver
On Thu, Mar 01, 2007 at 05:24:56PM +0900, Paul Mundt wrote:
Currently sm501fb_crtsrc_store() won't allow the routing to be changed
via echos from userspace in to the sysfs file. The reason for this is
that the strnicmp() for both heads uses a sizeof() for the string length,
which ends up being
On Thu, Mar 01, 2007 at 02:33:01AM +0100, Andrea Arcangeli ([EMAIL PROTECTED])
wrote:
On Thu, Mar 01, 2007 at 12:12:28AM +0100, Ingo Molnar wrote:
more capable by providing more special system calls like sys_upcall() to
execute a user-space function. (that way a syslet could still execute
On 26/02/07, Jesper Juhl [EMAIL PROTECTED] wrote:
I have a webserver running a rather old 2.6.13.4 kernel that a few
minutes ago surprised me by logging the following message :
kernel: nfs_update_inode: inode 309229856 mode changed, 0100644 to 0040755
I just got one more of these (well,
On Thu, 2007-03-01 at 00:54 -0800, Andrew Morton wrote:
On Thu, 01 Mar 2007 12:15:29 +0800 Wu, Bryan [EMAIL PROTECTED] wrote:
+/* check if the mac in reg is valid */
+#define SMC_GET_MAC_ADDR(addr) \
+ do {
* Kevin O'Connor [EMAIL PROTECTED] wrote:
I'd like to propose a simpler userspace API for syslets. I believe
this revised API is just as capable as yours (anything done purely in
kernel space with the existing API can also be done with this one).
An atom would look like:
struct
Hi!
I understand that - and I totally agree.
But when more complex, more bug-prone code results in higher performance
- that must be used. We have linked lists and binary trees - the latter
No-o. Kernel is not designed like that.
Often, more complex and slightly faster code
On Thu, 1 Mar 2007 10:15:21 +0100 Pavel Machek [EMAIL PROTECTED] wrote:
- xfslogd_workqueue = create_freezeable_workqueue(xfslogd);
+ xfslogd_workqueue = create_workqueue(xfslogd);
if (!xfslogd_workqueue)
goto out_free_buf_zone;
- xfsdatad_workqueue =
On Thu, Mar 01, 2007 at 11:38:06AM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
struct async_syscall {
long *result;
unsigned long asynid;
unsigned long nr_sysc;
unsigned long params[8];
};
Having result pointer as NULL might imply that result is not
On Thu, 01 Mar 2007 17:23:23 +0800 Wu, Bryan [EMAIL PROTECTED] wrote:
On Thu, 2007-03-01 at 00:54 -0800, Andrew Morton wrote:
On Thu, 01 Mar 2007 12:15:29 +0800 Wu, Bryan [EMAIL PROTECTED] wrote:
+/* check if the mac in reg is valid */
+#define SMC_GET_MAC_ADDR(addr)
[trimming cc list since I'm only replying to the avr32 part]
On Wed, 28 Feb 2007 22:03:49 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Mon, 26 Feb 2007 12:10:37 -0800 Mathieu Desnoyers [EMAIL PROTECTED]
wrote:
avr32/kernel/ptrace.c: ti-flags |= _TIF_BREAKPOINT;
No, I don't
On Wed, 28 Feb 2007 22:39:38 +0100 Ingo Molnar [EMAIL PROTECTED] wrote:
- 32-bit user-space on 64-bit kernel compat support. 32-bit syslet and
threadlet binaries work fine on 64-bit kernels.
Yay! :-)
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
* Jens Axboe [EMAIL PROTECTED] wrote:
f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, [...]
update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and
01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt
to bisect this.
Ingo
-
To unsubscribe from
On Thu, 1 Mar 2007 10:34:51 +0100 Haavard Skinnemoen [EMAIL PROTECTED] wrote:
On Mon, 26 Feb 2007 12:10:37 -0800 Mathieu Desnoyers [EMAIL PROTECTED]
wrote:
avr32/kernel/ptrace.c: ti-flags |= _TIF_BREAKPOINT;
No, I don't immediately see anything in the flush_old_exec() code
On Thu, Mar 01, 2007 at 10:26:34AM +0100, Pavel Machek ([EMAIL PROTECTED])
wrote:
10% gain in speed is NOT worth major complexity increase.
Should I create a patch to remove rb-tree implementation?
If you can replace them with something simpler, and no worse than 10%
slower in worst
On Thu, 01 Mar 2007 08:35:28 +0100 Miklos Szeredi [EMAIL PROTECTED] wrote:
This deadlock happens, when dirty pages from one filesystem are
written back through another filesystem. It easiest to demonstrate
with fuse although it could affect looback mounts as well (see
following
This deadlock happens, when dirty pages from one filesystem are
written back through another filesystem. It easiest to demonstrate
with fuse although it could affect looback mounts as well (see
following patches).
Let's call the filesystems A(bove) and B(elow). Process
On Thu, 01 Mar 2007 09:37:06 +0100 Miklos Szeredi [EMAIL PROTECTED] wrote:
Sigh. What's this about i_mutex? That appears to be some critical
information which _still_ isn't being communicated.
This:
ssize_t generic_file_aio_write(struct kiocb *iocb, const struct iovec *iov,
On Thu, 01 Mar 2007 12:15:14 +0800 Wu, Bryan [EMAIL PROTECTED] wrote:
Hi folks,
Here is the blackfin on-chip ethernet MAC controller driver for Linux.
It's name is blackfin-driver-net-stamp537.patch
[PATCH] Blackfin: on-chip ethernet MAC controller driver
This patch implements the
I'm just not going to apply weird hacks to work around a bug which
I do not understand, and I have spent way too much time trying to understand
this one.
I suggest you apply patch #5 balance dirty pages from loop device
and see for yourself the same deadlock with a simple loopback mount.
I
On Thu, 2007-03-01 at 13:29 +0530, Vivek Goyal wrote:
On Thu, Mar 01, 2007 at 04:16:59PM +0900, Fernando Luis Vázquez Cao wrote:
Use the APIC to determine the hardware processor id when APIC support
has been selected, independently of whether CONFIG_SMP is set or not.
Signed-off-by:
On Thu, Mar 01, 2007 at 04:18:23PM +0900, Fernando Luis Vázquez Cao wrote:
Move definition of hard_smp_processor_id to asm/smp.h on alpha, m32r,
powerpc, s390, sparc, sparc64, and um architectures.
Signed-off-by: Fernando Luis Vazquez Cao [EMAIL PROTECTED]
---
diff -urNp
On Thu, 2007-03-01 at 01:32 -0800, Andrew Morton wrote:
On Thu, 01 Mar 2007 17:23:23 +0800 Wu, Bryan [EMAIL PROTECTED] wrote:
On Thu, 2007-03-01 at 00:54 -0800, Andrew Morton wrote:
On Thu, 01 Mar 2007 12:15:29 +0800 Wu, Bryan [EMAIL PROTECTED] wrote:
+/* check if the mac in reg is
oh, and please consider removing all the CVS control strings from the
blackfin code. Because they become meaningless once the code is
merged into mainline.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
* Evgeniy Polyakov [EMAIL PROTECTED] wrote:
I posted kevent/epoll benchmarks and related design issues too many
times both with handmade applications (which might be broken as hell)
and popular open-source servers to repeat them again.
numbers are crutial here - and given the epoll bugs in
Here is the latest revision of the anti-fragmentation patches. Of
particular note in this version is special treatment of high-order atomic
allocations. Care is taken to group them together and avoid grouping pages
of other types near them. Artifical tests imply that it works. I'm trying to
get
The fragmentation reduction strategy needs to track if pages within a block
can be moved or reclaimed so that pages are freed to the appropriate list.
This patch adds a bitmap for flags affecting a whole a MAX_ORDER block
of pages.
In non-SPARSEMEM configurations, the bitmap is stored in the
It is often known at allocation time whether a page may be migrated or
not. This patch adds a flag called __GFP_MOVABLE and a new mask called
GFP_HIGH_MOVABLE. Allocations using the __GFP_MOVABLE can be either migrated
using the page migration mechanism or reclaimed by syncing with backing
This patch flags the allocations from low memory that may be migrated.
A GFP_USER_MOVABLE similar to GFP_HIGH_MOVABLE is not provided in this patch
because it would only be used once. This patch uses __GFP_MOVABLE twice
for a GFP_USER and a GFP_NOIO allocation. There is little point defining
This patch adds the core of the fragmentation reduction strategy. It
works by grouping pages together based on their ability to migrate or be
reclaimed. Basically, it works by breaking the list in zone-free_area list
into MIGRATE_TYPES number of lists.
Signed-off-by: Mel Gorman [EMAIL
On Thu, 01 Mar 2007 17:52:48 +0800 Wu, Bryan [EMAIL PROTECTED] wrote:
Please always prefer coding in C over coding in cpp.
Yes, it can be writen as a C function.
We just follow other implementation in the drivers/net/smc91x.h
start at line 1156 of
---
#ifndef SMC_GET_MAC_ADDR
#define
The freelists for each migrate type can slowly become polluted due to the
per-cpu list. Consider what happens when the following happens
1. A 2^(MAX_ORDER-1) list is reserved for __GFP_MOVABLE pages
2. An order-0 page is allocated from the newly reserved block
3. The page is freed and placed on
The grouping mechanism has some memory overhead and a more complex allocation
path. This patch allows the strategy to be disabled for small memory systems
or if it is known the workload is suffering because of the strategy. It also
acts to show where the page groupings strategy interacts with the
Per-cpu pages can accidentally cause fragmentation because they are free, but
pinned pages in an otherwise contiguous block. When this patch is applied,
the per-cpu caches are drained after the direct-reclaim is entered if the
requested order is greater than 0. It simply reuses the code used by
This patch marks a number of allocations that are either short-lived such as
network buffers or are reclaimable such as inode allocations. When something
like updatedb is called, long-lived and unmovable kernel allocations tend
to be spread throughout the address space which increases
When a fallback occurs, there will be free pages for one allocation type
stored on the list for another. When a large steal occurs, this patch will
move all the free pages within one list to the other.
Signed-off-by: Mel Gorman [EMAIL PROTECTED]
---
page_alloc.c | 65
This patch chooses blocks with lower PFNs when placing kernel allocations. This
is particularly important during fallback in low memory situations to stop
unmovable pages being placed throughout the entire address space.
Signed-off-by: Mel Gorman [EMAIL PROTECTED]
---
page_alloc.c | 20
In rare cases, the kernel needs to allocate a high-order block of pages
without sleeping. For example, this is the case with e1000 cards configured
to use jumbo frames. Migrating or reclaiming pages in this situation is
not an option.
This patch groups these allocations together as much as
MIGRATE_RECLAIMABLE allocations tend to be very bursty in nature like
when updatedb starts. It is likely this will occur in situations where
MAX_ORDER blocks of pages are not free. This means that updatedb can scatter
MIGRATE_RECLAIMABLE pages throughout the address space. This patch is more
Changelog since v1
o Rebased to 2.6.20-rc6-mm2
o Added necessary changes to per-zone VM stats for new zone (Christoph)
o Removed unnecessary changes to __ZONE_SHIFT (Christoph)
o Added paranoid check for overflow in cmdline_parse_kernelcore (Andy)
The following 8 patches against 2.6.20-mm2 create
(Note, this is identical to the equivilant patch in list-based
anti-fragmentation. When applying both sets of patches, only apply this once)
It is often known at allocation time when a page may be migrated or
not. This patch adds a flag called __GFP_MOVABLE and a new mask called
This patch creates an additional zone, ZONE_MOVABLE. This zone is only
usable by allocations which specify both __GFP_HIGHMEM and __GFP_MOVABLE.
Hot-added memory continues to be placed in their existing destination as
there is no mechanism to redirect them to a specific zone.
Signed-off-by:
Huge pages are not movable so are not allocated from ZONE_MOVABLE. However,
as ZONE_MOVABLE will always have pages that can be migrated or reclaimed,
it can be used to satisfy hugepage allocations even when the system has been
running a long time. This allows an administrator to resize the
This patch adds the kernelcore= parameter for x86.
Signed-off-by: Mel Gorman [EMAIL PROTECTED]
---
setup.c |1 +
1 files changed, 1 insertion(+)
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
linux-2.6.20-mm2-003_mark_hugepages_movable/arch/i386/kernel/setup.c
This patch adds the kernelcore= parameter for ppc and powerpc.
Signed-off-by: Mel Gorman [EMAIL PROTECTED]
---
powerpc/kernel/prom.c |1 +
ppc/mm/init.c |2 ++
2 files changed, 3 insertions(+)
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
This patch adds the kernelcore= parameter for x86_64.
Signed-off-by: Mel Gorman [EMAIL PROTECTED]
---
e820.c |1 +
1 files changed, 1 insertion(+)
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
linux-2.6.20-mm2-005_ppc64_set_kernelcore/arch/x86_64/kernel/e820.c
This patch adds the kernelcore= parameter for ia64.
Signed-off-by: Mel Gorman [EMAIL PROTECTED]
---
efi.c |3 +++
1 files changed, 3 insertions(+)
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
linux-2.6.20-mm2-006_x8664_set_kernelcore/arch/ia64/kernel/efi.c
Once all patches are applied, a new command-line parameter exist and a new
sysctl. This patch adds the necessary documentation.
Signed-off-by: Mel Gorman [EMAIL PROTECTED]
---
filesystems/proc.txt | 15 +++
kernel-parameters.txt | 16
sysctl/vm.txt |
Hi!
10% gain in speed is NOT worth major complexity increase.
Should I create a patch to remove rb-tree implementation?
If you can replace them with something simpler, and no worse than 10%
slower in worst case, then go ahead. (We actually tried to do that at
some point, only
Hi all,
I've posted up patches that implement the two generally accepted approaches
for reducing external fragmentation in the buddy allocator. The first
(list-based) works by grouping pages of related mobility together, across
all existing zones. The second (zone-based) creates a zone where
On Thu, 1 Mar 2007 01:45:23 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
If there's a lesson here, it is don't provide #defines in the header for
both versions.
Yes, that's true. It looks like all the other arches do the same thing
with the _TIF flags, however, so just ripping it out probably
On Thu, 2007-03-01 at 02:03 -0800, Andrew Morton wrote:
On Thu, 01 Mar 2007 17:52:48 +0800 Wu, Bryan [EMAIL PROTECTED] wrote:
Please always prefer coding in C over coding in cpp.
Yes, it can be writen as a C function.
We just follow other implementation in the drivers/net/smc91x.h
Hi!
But it is true that for most kernel programmers, threaded
programming is much easier to understand, and we need to engineer the
kernel for what will be maintainable for the majority of the kernel
development community.
What's probably true is that, for a kernel to stay competitive
* Pavel Machek [EMAIL PROTECTED] wrote:
Threadlets behave much worse without event driven model, events can
behave worse without backed threads, they are mutually compensating.
I think Ingo demonstrated unoptimized threadlets to be within 5% to
the speed of kevent. [...]
that was
On Thu, Mar 01, 2007 at 10:44:24AM +1100, David Gibson wrote:
On Wed, Feb 28, 2007 at 10:26:30PM +, Russell King wrote:
On Tue, Feb 20, 2007 at 02:19:51PM +1100, David Gibson wrote:
Therefore, this patch defines a UPF_FIXED_PORT flag for the uart_port
structure. If this flag is set
* Bernhard Walle [EMAIL PROTECTED] [2007-03-01 01:11]:
* Jan Kiszka [EMAIL PROTECTED] [2007-03-01 00:22]:
Robin Getz wrote:
Does anyone have a pointer for a MOST (Media Oriented Systems Transport)
driver?
http://en.wikipedia.org/wiki/Media_Oriented_Systems_Transport
I have
This patch contains the following possible cleanups:
- every file should #include the headers containing the prototypes for
it's global functions
- the xen_set_pud() prototype mismatch gcc was now able to detect
is corrected
- make the following needlessly global variable static:
-
* Ingo Molnar [EMAIL PROTECTED] wrote:
update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and
01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt
to bisect this.
hm. There's some weird bisection artifact here. Here are the commits i
tested, in git-log
* Bernhard Walle [EMAIL PROTECTED] [2007-03-01 01:11]:
PS: SUSE has nothing to do with that driver, I only write with my SUSE
address because I don't want to re-subscribe because of one mail.
Interesting, because it was addressed to my gmx address in CC, Mutt
automatically choosed my gmx
Adrian Bunk wrote:
This patch contains the following possible cleanups:
- every file should #include the headers containing the prototypes for
it's global functions
- the xen_set_pud() prototype mismatch gcc was now able to detect
is corrected
- make the following needlessly global
On Wed, 2007-02-28 at 16:55 +, James Simmons wrote:
So the problem is not the configuration but that for some reason the
backlight state is set to off by default.
Maybe, maybe not. I'm not sure there's been enough information to
conclude that.
At the moment, I'd like a patch which makes
On Thu, Mar 01, 2007 at 10:54:02AM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
* Evgeniy Polyakov [EMAIL PROTECTED] wrote:
I posted kevent/epoll benchmarks and related design issues too many
times both with handmade applications (which might be broken as hell)
and popular
* Evgeniy Polyakov [EMAIL PROTECTED] wrote:
I've just re-run tests on my amd64 test machine without debug options:
epoll4794.23
kevent 6468.95
could you please post the two URLs for the exact evserver code used for
these measurements? (even if you did so already in the past
On Thursday 01 March 2007 11:59, Evgeniy Polyakov wrote:
Yes, it is about 98-100% in both cases.
I've just re-run tests on my amd64 test machine without debug options:
epoll 4794.23
kevent6468.95
It would be valuable if you could post oprofile results
On Thursday 01 March 2007 19:46, Ingo Molnar wrote:
* Mike Galbraith [EMAIL PROTECTED] wrote:
I see no real difference between the two assertions. Nice is just a
mechanism to set priority, so I applied your assertion to a different
range of priorities than nice covers, and returned it to
On Thu, Mar 01, 2007 at 12:00:22PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
* Evgeniy Polyakov [EMAIL PROTECTED] wrote:
I've just re-run tests on my amd64 test machine without debug options:
epoll4794.23
kevent 6468.95
could you please post the two URLs for the
On Thu, Mar 01, 2007 at 11:11:02AM +0100, Pavel Machek ([EMAIL PROTECTED])
wrote:
10% gain in speed is NOT worth major complexity increase.
Should I create a patch to remove rb-tree implementation?
If you can replace them with something simpler, and no worse than 10%
On Thu, Mar 01, 2007 at 12:14:44PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
On Thursday 01 March 2007 11:59, Evgeniy Polyakov wrote:
Yes, it is about 98-100% in both cases.
I've just re-run tests on my amd64 test machine without debug options:
epoll 4794.23
kevent
On Thursday 01 March 2007 12:20, Evgeniy Polyakov wrote:
On Thu, Mar 01, 2007 at 12:14:44PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
On Thursday 01 March 2007 11:59, Evgeniy Polyakov wrote:
Yes, it is about 98-100% in both cases.
I've just re-run tests on my amd64 test machine
On Thu, 2007-03-01 at 22:13 +1100, Con Kolivas wrote:
if then there should be a mechanism /in the hardware/ to set the
priority of a CPU - and then the hardware could decide how to prioritize
between siblings. Doing this in software is really hard.
And that's the depressing part because
--- Pekka Enberg [EMAIL PROTECTED] wrote:
Yeah, but the oops looks more like a reference counting problem with
sysfs dentries. No harm in trying out the patch or reproducing without
CONFIG_SCHED_SMT though.
Nope, no difference. Again, this happened while trying to start World of
Warcraft.
Hi Chris,
On Thu, 1 Mar 2007, Chris Rankin wrote:
Nope, no difference. Again, this happened while trying to start World of
Warcraft. However, this time there is no snd-rtctimer module in the
stack.
Please apply this patch to your kernel and try to reproduce:
* Evgeniy Polyakov [EMAIL PROTECTED] wrote:
I've uploaded them to:
http://tservice.net.ru/~s0mbre/archive/kevent/evserver_epoll.c
http://tservice.net.ru/~s0mbre/archive/kevent/evserver_kevent.c
thanks.
I also changed client socket to nonblocking mode with the same result
in epoll
Andrew Morton wrote:
On Thu, 01 Mar 2007 02:34:02 -0800 Zachary Amsden [EMAIL PROTECTED] wrote:
I think on_each_cpu has a serious bug now that hrtimers has been
integrated. Basically, there are many callsites of clock_was_set, none
of which actually know the current interrupt state -
On Thu, Mar 01, 2007 at 12:27:00PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
* Evgeniy Polyakov [EMAIL PROTECTED] wrote:
I've uploaded them to:
http://tservice.net.ru/~s0mbre/archive/kevent/evserver_epoll.c
http://tservice.net.ru/~s0mbre/archive/kevent/evserver_kevent.c
On Thu, 2007-03-01 at 03:34 -0800, Zachary Amsden wrote:
What would be really, really nice would be to statically check all
callsites that issue irq disables actually keep irqs disabled.
Presumably, there was a reason they disabled irqs, and re-enabling them
underneath their noses, even if
Rusty Russell wrote:
On Thu, 2007-03-01 at 03:34 -0800, Zachary Amsden wrote:
What would be really, really nice would be to statically check all
callsites that issue irq disables actually keep irqs disabled.
Presumably, there was a reason they disabled irqs, and re-enabling them
* Evgeniy Polyakov [EMAIL PROTECTED] wrote:
I also changed client socket to nonblocking mode with the same result
in epoll server. If you will find it broken, please send me corrected
to test too.
this line in evserver_kevent.c looks a bit fishy:
err = recv(s, buf, 100, 0);
On Thu, Mar 01, 2007 at 12:28:00PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
On Thursday 01 March 2007 12:20, Evgeniy Polyakov wrote:
On Thu, Mar 01, 2007 at 12:14:44PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
On Thursday 01 March 2007 11:59, Evgeniy Polyakov wrote:
Yes, it
* Ingo Molnar [EMAIL PROTECTED] wrote:
I also changed client socket to nonblocking mode with the same result
in epoll server. If you will find it broken, please send me corrected
to test too.
this line in evserver_kevent.c looks a bit fishy:
this one in evserver_kevent.c looks
On Thu, Mar 01, 2007 at 02:53:21AM -0800, Jeremy Fitzhardinge wrote:
Adrian Bunk wrote:
...
struct shared_info *HYPERVISOR_shared_info = init_shared;
-EXPORT_SYMBOL(HYPERVISOR_shared_info);
Are you sure? I thought I added this because akpm was getting compile
errors with allmodconfig.
On Thu, Mar 01, 2007 at 12:41:37PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
* Evgeniy Polyakov [EMAIL PROTECTED] wrote:
I also changed client socket to nonblocking mode with the same result
in epoll server. If you will find it broken, please send me corrected
to test too.
this
On Thursday 01 March 2007 22:33, Thomas Gleixner wrote:
On Thu, 2007-03-01 at 22:13 +1100, Con Kolivas wrote:
if then there should be a mechanism /in the hardware/ to set the
priority of a CPU - and then the hardware could decide how to
prioritize between siblings. Doing this in software
I think what you're describing here is just the standard old
smp_call_function() deadlock, rather than anything which is specific to
intel-rng, yes?
It is well known that you can't call smp_call_function() with local
interrupts disabled. In fact i386 will spit a warning if you try it.
On Thu, Mar 01, 2007 at 12:47:35PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
I also changed client socket to nonblocking mode with the same result
in epoll server. If you will find it broken, please send me corrected
to test too.
this
On Thu, 2007-03-01 at 23:05 +1100, Con Kolivas wrote:
And that's the depressing part because of course I was interested in that
as the original approach to the problem (and it was a big problem). When
I spoke to Intel and AMD (of course to date no SMT AMD chip exists) at
kernel summit
Am Mittwoch, 28. Februar 2007 19:02 schrieb Dan Williams:
I can reliably reproduce a null pointer dereference on 2.6.20 and
2.6.21-rc2. I will keep digging to find the kernel version where
this last worked, but wanted to see if there were any immediate
experiments I should try.
...
Kernel
1 - 100 of 1065 matches
Mail list logo
