* Davide Libenzi wrote:
> > No, it absolutely is a matter of speed. The reason to have those
> > two implemented that way is so that they can be implemented as
> > vsyscalls completely in userspace. This means that on most modern
> > platforms you can implement the "make a threadlet when I
On Sat, 2007-02-24 at 21:13 -0800, David Miller wrote:
> As I suspected, the one-shot code wasn't very well tested and I'd be
> the one to debug this thing on sparc64 :-)
>
> When a timer exceeds the timer period, the one-shot handling code does
> the following loop:
>
> for (;;) {
>
On Tue, 2007-02-20 at 11:26 +0100, Mike Galbraith wrote:
> Kernel I captured this from is dirty, but virgin source does exactly the
> same. gzipped config attached.
>
>
> [ 32.211999] rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
> [ 32.227226] BUG: unable to handle kernel NULL point
commit 346e14262ff04e5c85f069eb95f0bb7a64d7b062
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Sun Feb 25 02:53:41 2007 -0500
[libata] sata_mv: don't touch reserved bits in EDMA config register
The code in mv_edma_cfg() reflected its 60xx origins, by doing things
[slightly] inco
> On Sat, 24 Feb 2007 20:30:41 -0600 Larry Finger <[EMAIL PROTECTED]> wrote:
> Pavel Machek wrote:
> > Hi!
> >
> >> -stable review patch. If anyone has any objections, please let us know.
> >>
> >> --
> >> From: Larry Finger <[EMAIL PROTECTED]>
> >>
> >> There is a kernel oops on
On Sat, 2007-02-24 at 21:42 -0800, David Miller wrote:
> While getting dynticks/hrtimers up on sparc64 I ran into
> the following build problem. If you use get_irq_regs() you
> need to include asm/irq_regs.h
>
> Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Acked-by: Thomas Gleixner <[EMAIL
David Miller <[EMAIL PROTECTED]> writes:
> ric, you recommended to me that I use:
>
> struct msi_desc *entry = get_irq_data(irq);
>
> in my arch_teardown_msi_irq() routine earlier, but the current
> code unlinks the entry before the call to arch_teardown_msi_irq()
> so I get OOPS's on shutd
Michal,
On Sat, 2007-02-24 at 23:45 +0100, Michal Piotrowski wrote:
> Here is a dmesg after over 25 hours of uptime
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc1/git-dmesg3
> nothing new.
can you please turn off CONFIG_SCHED_SMT ? It seems all reports have one
thing in com
commit 7aa3ffd983c12d224e33e5d4f89ad083392f9d8d
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Sun Feb 25 04:19:45 2007 -0500
[libata] sata_mv: Fix 50xx irq mask
IRQ mask bits assumed a 60xx or newer generation chip, which is very
wrong for the 50xx series. Luckily both generat
On Fri, 2007-02-23 at 01:38 +0200, Michael S. Tsirkin wrote:
> 1. After suspend to RAM, system wakes up but no screen.
> I can log in through ssh though.
> dmesg output at this point below.
> Works fine on 2.6.20 and below, with same .config
> .config and log file for this issue attached.
>
> 2. A
On Sunday, 25 February 2007 00:26, Andrey Borzenkov wrote:
> On Суббота 24 февраля 2007, Rafael J. Wysocki wrote:
> > Hi,
> >
> > On Saturday, 24 February 2007 10:55, Andrey Borzenkov wrote:
> > > On Вторник 13 февраля 2007, Andrey Borzenkov wrote:
> > > > On Четверг 07 декабря 2006, Lebedev, Vladi
On 2/24/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
>
> Keep in mind that setting nvidiafb to totally ignore the EDID (either
> by not compiling in EDID support or by using e.g. the ignoreedid patch
> I had proposed) the snow effect
> In current architecture, you have to patch kernel IPv6 and IPv4
> protocols when you add new link layer that they don't recognize.
Which is right, because the IP layer is the place which knows how to
map IP addresses to link layer addresses.
IP must know its link layer. E.g. it needs a way to d
Hi!
> Actually, it's quite clear under US law what a derivative work is and
> what rights you need to distribute it, and equally clear that
> compiling code does not make a "translation" in a copyright sense.
> Read Micro Star v. Formgen -- it's good law and it's funny and
> readable.
>
> I've dr
On Tue 2007-02-20 15:33:18, David Woodhouse wrote:
> On Tue, 2007-02-20 at 10:22 -0500, Theodore Tso wrote:
> > But __be32 will catch the same errors these days because the be/le
> > types use __bitwise now, right? So use of the __be32/__be64 types should
> > be preferred since it also will work w
On Wed 2007-02-21 00:12:28, Tilman Schmidt wrote:
> Am 20.02.2007 23:52 schrieb Robert P. J. Day:
> > "deprecated" means that there *is* a complete replacement available
> > *right now* and you should consider switching to it.
> >
> > if you can't offer someone a completely functional, better alte
Hi!
> For the ISA irqs we reserve 16 vectors. This patch adds constants for
> those vectors and modifies the code to use them. Making the code a
> little clearer and making it possible to move these vectors in the future.
> /*
> * Vectors 0x20-0x2f are used for ISA interrupts.
> */
> +#de
Hi!
> I'd like to add backlight support for input devices since my custom
> board has a backlighted mini keyboard.
>
> It could be acceptable to move the code from drivers/video/backlight/
> to drivers/backlight/ renaming the "Backlight & LCD" name into
> "Backlight" and adding two new entries "L
On Fri 2007-02-23 11:18:06, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> The reading of PF_BORROWED_MM in is_user_space() without task_lock() is racy.
> Fix it.
>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
ACK.
--
(english) http://www.livejournal.com/~
Hi!
> If the freezing of tasks fails and a task is preempted in refrigerator()
> before
> calling frozen_process(), then thaw_tasks() may run before this task is
> frozen.
> In that case the task will freeze and no one will thaw it.
>
> To fix this race we can call freezing(current) in refriger
On Fri 2007-02-23 11:23:43, Rafael J. Wysocki wrote:
> From: Paul E. McKenney <[EMAIL PROTECTED]>
>
> Remove PF_NOFREEZE from the rcutorture thread, adding a try_to_freeze() call
> as
> required.
>
> Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
> Signed-off-by: Rafael J. Wysocki <[EMAIL P
On Fri 2007-02-23 11:25:42, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> Remove PF_NOFREEZE from the bluetooth threads, adding try_to_freeze() calls as
> required.
>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
ACK.
--
(english) http://www.livejournal.co
Hi!
> Add try_to_freeze() calls to the remaining kernel threads that do not call
> try_to_freeze() already, although they set PF_NOFREEZE.
>
> In the future we are going to replace PF_NOFREEZE with a set of flags that
> will
> be set to indicate in which situations the task should not be frozen
On Sunday 25 February 2007 15:34, Gene Heskett wrote:
> I have a problem, Con. The patch itself works fine for me, BUT it doesn't
> update the version.h available in
> /lib/modules/2.6.20-ck1/source/include/linux to include the -ck1 in the
> reported kernel version when trying to build an fglrx dr
Hi!
> Currently try_to_freeze_tasks() has to wait until all of the vforked processes
> exit and for this reason every user can make it fail. To fix this problem
> we can introduce the additional process flag PF_FREEZER_SKIP to be used by
> tasks
> that do not want to be counted as freezable by t
On Wed, 14 Feb 2007, Pavel Machek wrote:
Hi!
[..snip..]
The current situation ought to be documented. Better yet some flag
can
It probably _is_ documented, somewhere :-). If you find nice place
where to document it (top manpage?) go ahead with the patch.
How about this:
CPU load
-
Hi,
On Sunday, 25 February 2007 11:46, Pavel Machek wrote:
> Hi!
>
> > Currently try_to_freeze_tasks() has to wait until all of the vforked
> > processes
> > exit and for this reason every user can make it fail. To fix this problem
> > we can introduce the additional process flag PF_FREEZER_SKI
On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
> On 2/24/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
> > >
> > > Keep in mind that setting nvidiafb to totally ignore the EDID (either
> > > by not compiling in EDID supp
Pavel Machek <[EMAIL PROTECTED]> writes:
> Hi!
>
>> For the ISA irqs we reserve 16 vectors. This patch adds constants for
>> those vectors and modifies the code to use them. Making the code a
>> little clearer and making it possible to move these vectors in the future.
>
>
>> /*
>> * Vectors
> But... how does situation change when Evil Linker does #include
> from his
> binary-only part?
Right, but *why* is he doing that? The answer: It is the most practical way
to write his driver.
> I believe situation in this case changes a lot... And that's what
> embedded people are doing; I do
Hi!
> > I've done so, with some interesting results. Source on
> > http://ds9a.nl/tmp/recvtimings.c - be careful to adjust the '3000' divider
> > to your CPU frequency if you care about absolute numbers!
> >
> > These are two groups, each consisting of 10 consecutive nonblocking UDP
> > recvfroms
On Sunday, 25 February 2007 11:37, Andrey Borzenkov wrote:
> On Воскресенье 25 февраля 2007, Rafael J. Wysocki wrote:
> > On Sunday, 25 February 2007 00:26, Andrey Borzenkov wrote:
> > > On Суббота 24 февраля 2007, Rafael J. Wysocki wrote:
> > > > Hi,
> > > >
> > > > On Saturday, 24 February 2007 1
On Sat, February 24, 2007 11:30 pm, Antonino A. Daplas wrote:
>
> How about booting with just vga=normal?
>
>
> Tony
>
That seems to work too. I've rebooted about 20 times in a row
and it hasn't done it again yet. Why would this only occur
at higher modes?
In the 2.6.20 dmesg log it reads "Nvidia
David Miller wrote:
> From: Markku Savela <[EMAIL PROTECTED]>
> > I think that is worse than allow a new driver to provide a simple
> > service function which maps IPv4/6 multicast address into link layer
> > address, when asked.
>
> The problem is that this mapping isn't so simple for several
> li
When I merged my 20619 new EH conversion with #libata-upstream
I had to manually resolve a conflict, and inadvertently lost
pdc_pata_ops' ->post_internal_cmd binding. Corrected by this patch.
Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
---
drivers/ata/sata_promise.c |1 +
1 files c
The invokation of signal handlers on x86 has several bugs
in its treatment of the signal number parameter:
- the i386 kernel passes the raw not the translated signal number
in EAX to non-SA_SIGINFO handlers compiled with -mregparm=3;
the value passed on the stack is correct, and SA_SIGINFO han
Update my email address in CREDITS to one that works.
Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
---
Should CREDITS have a specific maintainer?
diff -rupN linux-2.6.21-rc1/CREDITS linux-2.6.21-rc1.mikpe-email-address/CREDITS
--- linux-2.6.21-rc1/CREDITS2007-02-24 22:32:42.
On 2/25/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
Ok, but this is not realistic. I agree that if Evil Linker only adds
two hooks "void pop_server_starting(), void pop_server_stopping()", he
can get away with that.
But... how does situation change when Evil Linker does #include
from his
binary
On Sun, Feb 25, 2007 at 05:50:11AM +, Christoph Hellwig wrote:
> global variables are very bad for code maintainability and understanadbility.
> So we usually try to avoid them if possible and make them static to a
> single file and provide proper accessors for allowed actions on them.
Another
Eric W. Biederman wrote:
* Vectors 0x20-0x2f are used for ISA interrupts.
*/
-#define IRQ0_VECTORFIRST_EXTERNAL_VECTOR
+#define IRQ0_VECTORFIRST_EXTERNAL_VECTOR + 0x10
#define IRQ1_VECTORIRQ0_VECTOR + 1
#define IRQ2_VECTORIRQ0_VECTOR + 2
#def
What an unpleasing patchset. I really really hope we really have a bug in
there, and that all this crap isn't pointless uglification.
We _do_ need a flush_dcaceh_page() in all cases which you're concerned
about. Perhaps we should stick the appropriate barriers in there.
> On Thu, 15 Feb 2007 0
Mika Penttilä <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> * Vectors 0x20-0x2f are used for ISA interrupts.
>> */
>> -#define IRQ0_VECTOR FIRST_EXTERNAL_VECTOR
>> +#define IRQ0_VECTOR FIRST_EXTERNAL_VECTOR + 0x10
>> #define IRQ1_VECTOR IRQ0_VECTOR + 1
>>
> of other places too. Especially when the graphics chip maker explains
> that keeping their driver source code closed isn't really an attempt
> to hide their knowledge under a bushel basket. It's a defensive
> measure against having their retail margins destroyed by nitwits who
> take out all th
> On Tue, 20 Feb 2007 16:08:11 +0100 "Markus Rechberger" <[EMAIL PROTECTED]>
> wrote:
> following patch prevents a mutex/semaphore deadlock within the pcmcia
> framework when ejecting devices multiple times using pccardctl eject.
>
> For some more details see:
> http://lkml.org/lkml/2007/2/19/58
I'm changing the kvm userspace interface to be more friendly to other
archs. One issue is the PIO port size. x86 uses 16 bits to hold the
port size (64K ports). Is that an issue for other archs?
I guess I could change it to __u32, but it's better to know what various
architectures actually
Avi Kivity wrote:
The patchset, along with the previous fixset, is available as a git
tree from git://kvm.qumranet.com/home/avi/kvm/linux-2.6. You may wish
to plant it in your little git forest.
This is now git://kvm.qumranet.com/home/avi/kvm.git, as a bare 'git
pull' will pull the curre
The big news today is that live migration works with kvm (kvm-14 could
do live migration, but only with -no-kvm). See
http://kvm.qumranet.com/kvmwiki/Migration for instructions.
Changes from kvm-14:
- live migration with kvm (Uri Lublin)
- based on Anthony Liguori's qemu patches
- new usersp
> On Sun, 25 Feb 2007 11:58:23 +0200 Avi Kivity <[EMAIL PROTECTED]> wrote:
> Avi Kivity wrote:
> >
> > The patchset, along with the previous fixset, is available as a git
> > tree from git://kvm.qumranet.com/home/avi/kvm/linux-2.6. You may wish
> > to plant it in your little git forest.
> >
>
>
> On Tue, 20 Feb 2007 13:27:12 + "J.J. Green" <[EMAIL PROTECTED]> wrote:
> Hi all
>
> I got bitten by this problem on sparc64 (a blade 1000)
>
> http://ubuntuforums.org/showthread.php?t=297474
>
> summary :
>
> modprobe bbc
>
> runs kenvctrld which uses 100% of a CPU for 5 seconds,
> th
On 2/25/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
Hi!
> Currently try_to_freeze_tasks() has to wait until all of the vforked processes
> exit and for this reason every user can make it fail. To fix this problem
> we can introduce the additional process flag PF_FREEZER_SKIP to be used by
task
On Sunday, 25 February 2007 11:45, Rafael J. Wysocki wrote:
> Hi,
>
> On Sunday, 25 February 2007 11:46, Pavel Machek wrote:
> > Hi!
> >
> > > Currently try_to_freeze_tasks() has to wait until all of the vforked
> > > processes
> > > exit and for this reason every user can make it fail. To fix
Hi Andrew, all,
I appear to need the following fix to be able to build 2.6.20-mm2 on
x86_64. Without the fix, my build attempt dies on:
In file included from drivers/pci/quirks.c:532:
include/asm/io_apic.h:61: error: "MAX_IO_APICS" undeclared here (not in a
function)
Not sure how nobody else wa
On 2/25/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
>
> Applied. No noticeable difference, in the sense that the EDID debug
> output is still the same and so is the snow effect.
Here's a temporary workaround:
In drivers/video/nvid
On Sunday, 25 February 2007 14:01, Aneesh Kumar wrote:
> On 2/25/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > Hi!
> >
> > > Currently try_to_freeze_tasks() has to wait until all of the vforked
> > > processes
> > > exit and for this reason every user can make it fail. To fix this problem
> > >
* Andrew Morton <[EMAIL PROTECTED]>, [2007-02-25 4:47 -0800]:
> > On Tue, 20 Feb 2007 13:27:12 + "J.J. Green" <[EMAIL PROTECTED]> wrote:
> > I got bitten by this problem on sparc64 (a blade 1000)
> >
> > http://ubuntuforums.org/showthread.php?t=297474
> The code around there looks rel
This small patchset plugs a few holes in the kvm dirty page logging
implementation. With these fixes (which really want to be in Linux
2.6.21), one can migrate a running virtual machine from one host to
another. The virtual machine continues executing while its memory image
is transferred, so
A few places where we modify guest memory fail to call mark_page_dirty(),
causing live migration to fail. This adds the missing calls.
Signed-off-by: Uri Lublin <[EMAIL PROTECTED]>
Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
---
drivers/kvm/kvm_main.c |6 ++
1 files changed, 6 insertio
Since dirty_bitmap is an unsigned long array, the alignment and size need
to take that into account.
Signed-off-by: Uri Lublin <[EMAIL PROTECTED]>
Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
---
drivers/kvm/kvm_main.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/d
To be called from kvm_vm_ioctl_set_memory_region()
Signed-off-by: Uri Lublin <[EMAIL PROTECTED]>
Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
---
drivers/kvm/kvm_main.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_
Enabling dirty page logging is done using KVM_SET_MEMORY_REGION ioctl.
If the memory region already exists, we need to remove write accesses,
so writes will be caught, and dirty pages will be logged.
Signed-off-by: Uri Lublin <[EMAIL PROTECTED]>
Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
---
d
Avi Kivity wrote:
This small patchset plugs a few holes in the kvm dirty page logging
implementation. With these fixes (which really want to be in Linux
2.6.21), one can migrate a running virtual machine from one host to
another. The virtual machine continues executing while its memory
image
On 2/25/07, Alan <[EMAIL PROTECTED]> wrote:
> of other places too. Especially when the graphics chip maker explains
> that keeping their driver source code closed isn't really an attempt
> to hide their knowledge under a bushel basket. It's a defensive
> measure against having their retail marg
On 2/25/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
On Sunday, 25 February 2007 11:45, Rafael J. Wysocki wrote:
> Hi,
>
> =
--- linux-2.6.20-mm2.orig/kernel/power/process.c2007-02-22
23:44:04.0 +0100
+++ linux-2.6.20-mm2/kernel/power/process.c 2007-02-23 22:33:11
On Sunday, 25 February 2007 15:33, Aneesh Kumar wrote:
> On 2/25/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > On Sunday, 25 February 2007 11:45, Rafael J. Wysocki wrote:
> > > Hi,
> > >
> > > =
> > --- linux-2.6.20-mm2.orig/kernel/power/process.c2007-02-22
> > 23:44:04.
Hi,
As of now there is only support for x86
arch of dyntick in 2.6.21. When will it be
available for x86_64?
-
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
On 2/25/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
On Sunday, 25 February 2007 15:33, Aneesh Kumar wrote:
> On 2/25/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > On Sunday, 25 February 2007 11:45, Rafael J. Wysocki wrote:
> > > Hi,
> > >
> > > =
> > --- linux-2.6.20-mm2.orig/
On Sun, 25 February 2007 03:41:40 +0100, Juan Piernas Canovas wrote:
>
> Well, our experimental results say another thing. As I have said, the
> greatest part of the files are written at once, so their meta-data blocks
> are together on disk. This allows DualFS to implement an explicit
> prefet
On 2/25/07, Aneesh Kumar <[EMAIL PROTECTED]> wrote:
On 2/25/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> On Sunday, 25 February 2007 15:33, Aneesh Kumar wrote:
> > On 2/25/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > > On Sunday, 25 February 2007 11:45, Rafael J. Wysocki wrote:
> >
On Sun, 25 Feb 2007 00:25:27 +0100, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> Attached patch does:
> 1) Do not check vmlinux but check all .o files that is used to create vmlinux
> 2) Teach modpost to skip non-elf files (.a files and empty .o files etc)
>
> With this change we get proper check of
On Sat, 24 Feb 2007 20:51:27 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Tejun Heo wrote:
> > ata_host_release() uses drvdata to determine ata_host to release and
> > clearing drvdata in ->remove_one causes NULL pointer deference. Clear
> > drvdata only in ata_host_release() after all resource
Bob Tracy <[EMAIL PROTECTED]> reported that the addition of support
for Aculab E1/T1 cPCI carrier cards broke detection of vanilla natsemi
cards. This patch fixes that: the problem is that the driver-specific
ta in the PCI device table is an index into a second table and this
had not been updated
Krzysztof Halasa wrote:
> Udo van den Heuvel <[EMAIL PROTECTED]> writes:
>
>> I will try a different case with a different dual PCI riser card soon.
>> This Morex riser has DN20-31 or so, so more options.
>
> OTOH I wonder how do they use DN 21-31? The board uses lines AD11 to AD31
> (21 lines) f
Randy Dunlap wrote:
On Sat, 24 Feb 2007 16:44:20 +0100 Mario Vanoni wrote:
2.6.18.7 vanilla & 2.6.16.41 vanilla:
/dev/hda CD/DVD
/dev/hda1 / IDE HD 160GB
/dev/hda2 swap
/dev/sda1 /xyz SATA HD 320GB
/dev/sda2 swap
/dev/sdb1 /zzz SATA HD 320GB
/dev/sdb2 swap
/dev/sdc1 /usb USB KEY 512MB
For 2.
On Sunday 25 February 2007, Con Kolivas wrote:
>On Sunday 25 February 2007 15:34, Gene Heskett wrote:
>> I have a problem, Con. The patch itself works fine for me, BUT it
[...]
>> Can we have a patch to address this? Or should I just hardcode it
>> since it will never be linked to any other later
On Sun, Feb 25, 2007 at 05:33:10PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> Hi Ingo.
>
> I tried to create web server application for threadlets to show (will
> not write what I wanted to show, but you might guess :)
>
> I started threadlet-test from async-test-v4 and got following b
On Wed, Feb 21, 2007 at 10:13:55PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
> this is the v3 release of the syslet/threadlet subsystem:
>
>http://redhat.com/~mingo/syslet-patches/
There is no %xgs.
--- ./arch/i386/kernel/process.c~ 2007-02-24 22:56:14.0 +0300
+++ ./arch/i3
Hi Ingo.
I tried to create web server application for threadlets to show (will
not write what I wanted to show, but you might guess :)
I started threadlet-test from async-test-v4 and got following bug.
To compile v4 and v3 I need to apply a patch (sent in previous e-mail),
which removes %xgs ass
On Sat, 24 February 2007 16:14:48 -0800, Christoph Lameter wrote:
>
> It eliminates 50% of the slab caches. Thus it reduces the management
> overhead by half.
How much management overhead is there left with SLUB? Is it just the
one per-node slab? Is there runtime overhead as well?
In a slight
Chuck Ebbert wrote:
> It is the standard Fedora script "iptables" and it recursively
> unloads all referring modules, then the base ones: ip_tables and
> ip_conntrack. I can't tell which module it stopped on because
> that computer is at home today.
>
> And yes, it really locks up until it's caug
* Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 21, 2007 at 10:13:55PM +0100, Ingo Molnar ([EMAIL PROTECTED])
> wrote:
> > this is the v3 release of the syslet/threadlet subsystem:
> >
> >http://redhat.com/~mingo/syslet-patches/
>
> There is no %xgs.
>
> --- ./arch/i386/kernel
[ Since Alan forwarded part the original question to LKML ... if you
follow up, please adjust CC's appropriately ]
-- Forwarded Message --
Subject: Re: [linux-usb-devel] usbfs2: Why asynchronous I/O?
Date: Sunday 25 February 2007 8:53 am
From: David Brownell <[EMAIL PROTECTED]>
* Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> My main concern was only about the situation, when we ends up with
> truly bloking context (like network), and this results in having
> thousands of threads doing the work - even having most of them
> sleeping, there is a problem with memory over
On Sun, Feb 25, 2007 at 06:23:38PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> * Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Feb 21, 2007 at 10:13:55PM +0100, Ingo Molnar ([EMAIL PROTECTED])
> > wrote:
> > > this is the v3 release of the syslet/threadlet subsystem:
> > >
> >
On Воскресенье 25 февраля 2007, Rafael J. Wysocki wrote:
> On Sunday, 25 February 2007 11:37, Andrey Borzenkov wrote:
> > On Воскресенье 25 февраля 2007, Rafael J. Wysocki wrote:
> > > On Sunday, 25 February 2007 00:26, Andrey Borzenkov wrote:
> > > > On Суббота 24 февраля 2007, Rafael J. Wysocki w
Milind Arun Choudhary wrote:
why bitops.h? coz BIT qualifies for a "bitop"
& bitops.h is inclued by kernel.h, hence accessible from every part
of the tree without mucb efforts
I don't think there is anyone who objects to this
c>but it is not sutaible for those who want to go beyond this li
This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering
Pavel Machek wrote:
Hi!
Actually, it's quite clear under US law what a derivative work is and
what rights you need to distribute it, and equally clear that
compiling code does not make a "translation" in a copyright sense.
Read Micro Star v. Formgen -- it's good law and it's funny and
reada
* Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > hm, what tree are you using as a base? The syslet patches are
> > against v2.6.20 at the moment. (the x86 PDA changes will probably
> > interfere with it on v2.6.21-rc1-ish kernels) Note that otherwise
> > the syslet/threadlet patches are for x
> Busy-wait loops were a rhetorical flourish, I grant you.
Thats a complicated fancy way of saying you were talking rubbish ?
Alan
-
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.o
I had the same problem, and your patch fixes it.
I found that disabling CONFIG_RTC_DRV_CMOS
fixes^Wworkarounds it too...
Acked-by: Vincent Legoll <[EMAIL PROTECTED]>
--
Vincent Legoll
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PR
On Sun, Feb 25, 2007 at 06:45:05PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> * Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > My main concern was only about the situation, when we ends up with
> > truly bloking context (like network), and this results in having
> > thousands of threa
On Sun, Feb 25, 2007 at 06:54:37PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> * Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > > hm, what tree are you using as a base? The syslet patches are
> > > against v2.6.20 at the moment. (the x86 PDA changes will probably
> > > interfere with i
* Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > Do you have any link where i could check the type of HTTP parsing
> > and send transport you are (or will be) using? What type of http
> > client are you using to measure, with precisely what options?
>
> For example this ones (essentially the
Hi everybody,
"The bug was introduced somewhere at the transition of 2.6.20 towards
2.6.20-git14."
I fortunately had some git9 patch at home and found out that it is sane.
In so far the floppy mount bug was introduced somewhen between 2.6.20-git10 and
2.6.20-git14.
"I'm afraid that the most proac
* Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > > Do you have any link where i could check the type of HTTP parsing
> > > and send transport you are (or will be) using? What type of http
> > > client are you using to measure, with precisely what options?
> >
> > For example this ones (essent
On Sun, Feb 25, 2007 at 09:21:35PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> > Do you have any link where i could check the type of HTTP parsing and
> > send transport you are (or will be) using? What type of http client are
> > you using to measure, with precisely what options?
>
>
Hello,
Andrew Morton wrote:
(cc's restored. Please, always do reply-to-all)
On Fri, 23 Feb 2007 22:57:27 + (UTC) Mark Gray <[EMAIL PROTECTED]> wrote:
i2o/hda:<3>Buffer I/O error on device i2o/hda, logical block 0
Buffer I/O error on device i2o/hda, logical block 0
Same error here. Both
Here is the second round to the new display class. This is meant to unite
the various solutions to display units ie acpi output device, auxdisplay
and the defunct lcd class in the backlight directory. Please apply.
Signed-off-by: James Simmons <[EMAIL PROTECTED]>
diff -urN -X fbdev-2.6/Documen
On Sun, Feb 25, 2007 at 07:22:30PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
> > > Do you have any link where i could check the type of HTTP parsing
> > > and send transport you are (or will be) using? What type of http
> > > client are you using to measure, with precisely what options?
> >
* Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > thx - i guess i should just run them without any options and they
> > bind themselves to port 80? What 'ab' options are you using
> > typically to measure them?
>
> Yes, but they require /tmp/index.html to have http header and actual
> data pa
1 - 100 of 227 matches
Mail list logo
