Vadim Lobanov wrote:
I figured it was something along these lines. In that case, is the
following code (from kernel/posix-timers.c) really doing the right
thing?
do
expires = timr-it_timer.expires;
while ((volatile long) (timr-it_timer.expires) != expires);
Seems it's casting the value,
On Thu, 2005-08-25 at 16:09 -0400, Steven Rostedt wrote:
A word of caution (aka. disclaimer). This is still new. I still expect
there are some cases in the code that was missed and can cause a dead
lock or other bad side effect. Hopefully, we can iron these all out.
Also, I noticed that
On Thu, 2005-08-25 at 19:45 +0200, Ingo Molnar wrote:
* Daniel Walker [EMAIL PROTECTED] wrote:
Does anyone have x86_64 working in PREEMPT_RT ?
builds fine, but doesnt seem to boot at the moment. Havent investigated
yet.
I tested an em64t , and it hung during boot .. But this patched
The adm9240 driver, in adm9240_detect(), allocates a structure. The
error path attempts to kfree() -client field of it (second one),
resulting in an oops (or slab corruption) if the hardware is not present.
-client field in adm1026, adm1031, smsc47b397 and smsc47m1 is the first in
${HWMON}_data
(frequency) * (1/drift) * (1/latency) * (1/(jitter_factor * cpus))
(Note that 1/cpus, being a constant for all evaluations of this
expression, has no effect on the final ranking.)
The usual way it's done is with some fiddle factors:
quality_a^a * quality_b^b * quality_c^c
Or, equivalently:
a
On Wednesday, 24 of August 2005 23:21, Andi Kleen wrote:
On Wednesday 24 August 2005 23:08, Rafael J. Wysocki wrote:
Hi,
I'm currently seeing a memory problem on a NUMA-enabled dual-Opteron 250
box with the 2.6.12.5 and 2.6.13-rc* (up to 7) kernels. Namely, the box
has 12 GB of RAM, 8
I'm searching my way through changesests.
rc2 was OK, rc3 was broken.
60a762b6a6dec17cc4339b60154902fd04c2f9f2 was OK too - the commit before
ACPI merge on 2005-07-12
Currently compiling 5028770a42e7bc4d15791a44c28f0ad539323807 - acpi
merge commit. Will see tomorroy whether it works.
--
Wakeup race checking shouldn't trigger when interrupts are off. Here's a
fix.
Daniel
Index: linux-2.6.12/kernel/rt.c
===
--- linux-2.6.12.orig/kernel/rt.c 2005-08-25 21:33:43.0 +
+++ linux-2.6.12/kernel/rt.c
Hi!
I just switched out motherboards and CPUs From a Asus K8v SE Deluxe
to a to a Asus A8V-E Deluxe, and a 754 pin 3200+ to a 934 pin 3200+.
I am now having some fairly serious instability issues. The system
locks up completely with no oops. After disabling CONFIGHIMEM and
* Daniel Walker [EMAIL PROTECTED] wrote:
@@ -257,6 +257,7 @@ void check_preempt_wakeup(struct task_st
* hangs and race conditions.
*/
if (!preempt_count()
+ !__raw_irqs_disabled()
p-prio current-prio
rt_task(p)
Dumb typo: iounmap(local_pointer_variable).
Signed-off-by: Al Viro [EMAIL PROTECTED]
diff -urN RC13-rc7-m68k-adb.patch/drivers/net/ibm_emac/ibm_emac_core.c
RC13-rc7-emac-iounmap/drivers/net/ibm_emac/ibm_emac_core.c
--- RC13-rc7-m68k-adb.patch/drivers/net/ibm_emac/ibm_emac_core.c
In qdio_get_micros() volatile in return type is plain noise (even with old
gccisms it would make no sense - noreturn function returning __u64 is a
bit odd ;-)
Signed-off-by: Al Viro [EMAIL PROTECTED]
diff -urN RC13-rc7-emac-iounmap/drivers/s390/cio/qdio.c
Hi Alexey,
The adm9240 driver, in adm9240_detect(), allocates a structure. The
error path attempts to kfree() -client field of it (second one),
resulting in an oops (or slab corruption) if the hardware is not
present.
-client field in adm1026, adm1031, smsc47b397 and smsc47m1 is the
Add some infrastructure for saving and restoring the context of an
SPE. This patch creates a new structure that can hold the whole
state of a physical SPE in memory. It also contains code that
avoids races during the context switch and the binary code that
is loaded to the SPU in order to access
Thankfully, there is now documentation available to the world about
the Cell architecture (http://cell.scei.co.jp/e_download.html), so I
am now able to disclose more of our work on the SPU file system.
This is a rather big update compared to the previous version, as it
contains work from Mark
In order to debug spu threads, we need access to the registers
of the running SPU. Unfortunately, this is only possible when
the SPU context is saved to memory.
This patch adds operations that enable accessing an SPU
in either runnable or saved state. We use an RW semaphore
to protect the state
Add the source code that is used to generate spu_save_dump.h and
spu_restore_dump.h. Since a full spu tool chain is needed to
generate these files, the default remains to use the shipped
versions in order to keep the number of tools for building the
kernel down.
From: Mark Nutter: [EMAIL
Jordan Crouse wrote:
Todd - do you have a ChangeLog from Take 1? :)
Right, here's what's changed in this version...
The generic structure of an operating point as an array of integers is
dropped. A struct powerop_point is now an entirely backend-defined
struct of arbitrary fields.
There
This patch makes it possible to receive user-defined
signals when the spufs ibox and wbox files are accessed
from an SPE, so data can be read/written from/to
them again.
Unfortunately, this kind of messes with the layering
of the high- and low-level parts of the code, so I'm
currently thinking
On Thu, 2005-08-25 at 23:54 +0200, Ingo Molnar wrote:
* Daniel Walker [EMAIL PROTECTED] wrote:
@@ -257,6 +257,7 @@ void check_preempt_wakeup(struct task_st
* hangs and race conditions.
*/
if (!preempt_count()
+ !__raw_irqs_disabled()
p-prio
This patch makes it possible to use a system call instead of
an ioctl to run spu code on spufs.
This is only provided for reference, the current patch is
unlikely to be used in future versions.
We planning to move to a model where creation/destruction
of SPU threads as well as entering the
spinlock used in irq handler should be initialized before registering
irq, even if we know that our device has interrupts disabled; handler
is registered shared and taking spinlock is done unconditionally. As
it is, we can and do get oopsen on boot for some configuration, depending
on irq routing
On Thu, Aug 25, 2005 at 08:07:55PM +0100, Al Viro wrote:
IMO that's a question to rth: why do we really need to block always_inline
on alpha?
Because I use extern inline in the proper way. That is, I have both
inline and out-of-line versions of some routines. These routines have
their address
Nevermind , the original patch looks fine.
Daniel
On Thu, 2005-08-25 at 23:54 +0200, Ingo Molnar wrote:
* Daniel Walker [EMAIL PROTECTED] wrote:
@@ -257,6 +257,7 @@ void check_preempt_wakeup(struct task_st
* hangs and race conditions.
*/
if (!preempt_count()
+
On Thu, Aug 25, 2005 at 03:16:49PM -0700, Richard Henderson wrote:
On Thu, Aug 25, 2005 at 08:07:55PM +0100, Al Viro wrote:
IMO that's a question to rth: why do we really need to block always_inline
on alpha?
Because I use extern inline in the proper way. That is, I have both
inline and
On Thu, 2005-08-25 at 17:40 -0400, [EMAIL PROTECTED] wrote:
(frequency) * (1/drift) * (1/latency) * (1/(jitter_factor * cpus))
(Note that 1/cpus, being a constant for all evaluations of this
expression, has no effect on the final ranking.)
I was sloppy expressing how the jitter factors
John McCutchan wrote:
On Thu, 2005-08-25 at 11:54 -0700, George Anzinger wrote:
Robert Love wrote:
On Thu, 2005-08-25 at 09:33 -0400, John McCutchan wrote:
On Thu, 2005-08-25 at 22:07 +1200, Reuben Farrelly wrote:
~
I think the best thing is to take idr into user space and emulate the
Benjamin Herrenschmidt writes:
Ok, so what is the problem then ? Why do we have to wait at all ? Why
not just unplug/replug right away ?
We'd have to be absolutely certain that the driver could not possibly
take another interrupt or try to access the device on behalf of the
old instance of the
On Thu, 2005-08-25 at 16:10 -0700, George Anzinger wrote:
That IS strange. 1024 is on a level boundry, but then next level is
2**15, not 2**11. I will take a look.
Remember that the level is never filled, so maybe the smallest level
just gets an offset or something? Well, you're the expert
Sorry. Here's the start of the thread.
Tony
On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
Linus Torvalds [EMAIL PROTECTED] wrote:
Antonino A. Daplas:
intelfb/fbdev: Save info-flags in a local variable
Sylvain Meyer:
intelfb: Do not ioremap entire graphics aperture
One of these changes
Devastating latency on a 3Ghz xeon .. Maybe the raw_spinlock in the
timer base is creating a unbounded latency?
Daniel
( softirq-timer/1-13 |#1): new 66088 us maximum-latency critical section.
= started at timestamp 1857957769: __down_mutex+0x5f/0x295
= ended at timestamp 1858023857:
On Fri, 2005-08-26 at 09:18 +1000, Paul Mackerras wrote:
Benjamin Herrenschmidt writes:
Ok, so what is the problem then ? Why do we have to wait at all ? Why
not just unplug/replug right away ?
We'd have to be absolutely certain that the driver could not possibly
take another interrupt
Already fixed in Greg's i2c tree and -mm for quite some time now...
So it is. The comment says, however, that the existing code works
somewhat by accident. In the case of the 9240 driver, however, the
existing code demonstrably does not work - it oopsed on me. The patch
in Greg's tree looks
Alan Cox wrote:
On Sul, 2005-06-19 at 18:55, Pavel Machek wrote:
...
If we are serious about utf-8 support in ext3, we should return
-EINVAL if someone passes non-canonical utf-8 string.
That would ironically not be standards compliant
Which standards?
The standards I've read
Pekka Enberg [EMAIL PROTECTED] wrote:
This patch changes fifo_poll not to return POLLERR to take care of a FIXME
in fs/pipe.c stating that Most unices do not set POLLERR for fifos. The
comment has been there since 2.3.99-pre3 so either apply this patch or
alternatively, I can send a new one
On Thu, 2005-08-25 at 16:29 -0700, Daniel Walker wrote:
Devastating latency on a 3Ghz xeon .. Maybe the raw_spinlock in the
timer base is creating a unbounded latency?
The lock is only held for really short periods. The only possible long
period would be migration of timers from a dead hotplug
NAK, this is wrong:
+ lock_super(sb);
err = ext3_group_extend(sb, EXT3_SB(sb)-s_es, n_blocks_count);
+ unlock_super(sb);
This basically reverses the order of locking between lock_super() and
journal_start() (the latter acts like a lock because it can
On Thursday, August 25, 2005 8:02 PM (JST), Adrian Bunk wrote:
2.6.13- rc7-libata1.patch.bz2 was used.
A combined mode of ata_piix seems not to work.
Is the following patches correct?
diff -urN linux-2.6.13-rc7.orig/drivers/scsi/Kconfig
linux-2.6.13-rc7/drivers/scsi/Kconfig
---
On Fri, Aug 26, 2005 at 09:04:37AM +0900, Tomita, Haruo wrote:
On Thursday, August 25, 2005 8:02 PM (JST), Adrian Bunk wrote:
2.6.13- rc7-libata1.patch.bz2 was used.
A combined mode of ata_piix seems not to work.
Is the following patches correct?
diff -urN
--- Ben Greear [EMAIL PROTECTED] wrote:
Danial Thom wrote:
The tests I reported where on UP systems.
Perhaps
the default settings are better for this in
2.4,
since that is what I used, and you used your
hacks for both.
My modifications to the kernel are unlikely to
speed
This patch adds the Dell Systems Management Base Driver with sysfs support.
This driver has been tested with Dell OpenManage.
Signed-off-by: Doug Warzecha [EMAIL PROTECTED]
---
diff -uprN linux-2.6.13-rc7.orig/Documentation/dcdbas.txt
linux-2.6.13-rc7/Documentation/dcdbas.txt
---
On Wed, Aug 24, 2005 at 01:31:07PM -0700, Paul Jackson wrote:
==
The safest, mind numbingly simple thing to do that would avoid the oops
that Hawkes reported is to simply not have the cpuset code call the
code to setup a dynamic sched domain. This is choice (2) above, and
could be
Dinakar wrote:
I'll ack this for now until I fix the problems that I am seeing
on ppc64
Thanks, Dinakar.
Linus - do *NOT* actually apply the literal patch that Dinakar ack'd.
1) It's logic is backwards - arrgh.
2) It doesn't undo the other attempt to partially disable this.
3) It's not a
The partial disabling of Dinakar's new facility to allow
cpu_exclusive cpusets to define dynamic sched domains
doesn't go far enough. At the suggestion of Nick Piggin
and Dinakar, let us instead totally disable this facility
for 2.6.13, in order to avoid problems first reported
by John Hawkes
At the suggestion of Nick Piggin and Dinakar, totally disable
the facility to allow cpu_exclusive cpusets to define dynamic
sched domains in Linux 2.6.13, in order to avoid problems
first reported by John Hawkes (corrupt sched data structures
and kernel oops).
This has been built for ppc64, i386,
I've been asked to pass this on for some kind of clarification.
We have management apps requiring specific information from the Smart
Array controller. We're trying to use sysfs to accomplish the task. An
example of what we need to do is below. I'm sure some of you will
recognize this as CSMI.
On Thu, 2005-08-25 at 13:52 -0500, Miller, Mike (OS Dev) wrote:
I've been asked to pass this on for some kind of clarification.
We have management apps requiring specific information from the Smart
Array controller. We're trying to use sysfs to accomplish the task. An
example of what we need
typedef struct _CSMI_SAS_IDENTIFY {
__u8 bDeviceType;
__u8 bRestricted;
__u8 bInitiatorPortProtocol;
__u8 bTargetPortProtocol;
__u8 bRestricted2[8];
__u8 bSASAddress[8];
__u8 bPhyIdentifier;
__u8 bSignalClass;
__u8 bReserved[6];
}
Hi Andrew,
I'd like to get this into 2.6.13 if possible. If it's too late, it's
not the end of the world -- we can wait for 2.6.13.1. But it's a
tiny, obvious patch that fixes a crash that at least one person
actually hit running a normal application:
Eric Dumazet wrote:
Furthermore, a lazy sync would mean to change sysctl proc_handler for
file-nr to perform a synchronize before calling proc_dointvec, this
would be really obscure.
I was only using your terminology (ie. the 'lazy' synch after the
atomic is updated).
Actually, a better
On Fri, 2005-08-26 at 02:22 +0200, Thomas Gleixner wrote:
On Thu, 2005-08-25 at 16:29 -0700, Daniel Walker wrote:
Devastating latency on a 3Ghz xeon .. Maybe the raw_spinlock in the
timer base is creating a unbounded latency?
The lock is only held for really short periods. The only
Rik van Riel wrote:
On Thu, 25 Aug 2005, Nick Piggin wrote:
fork() can be changed so as not to set up page tables for
MAP_SHARED mappings. I think that has other tradeoffs like
initially causing several unavoidable faults reading
libraries and program text.
Actually, libraries and program
I know that anon_hash_chain has gone away in 2.6 because
the inodes for special filesystems like sockfs, pipefs,
etc are now associated with a superblock. Should these
inodes have i_hash linked into the inode hashtable then?
It appears in 2.4 now they are associated with superblocks
as well.
I
jerome lacoste [EMAIL PROTECTED] wrote:
On 8/23/05, Andrew Morton [EMAIL PROTECTED] wrote:
jerome lacoste [EMAIL PROTECTED] wrote:
I am on a Dell Inspiron 8100 laptop with 512 M and 1G disk cache. I
usually have at least 4 big applications running simultaneously: a
Java IDE,
Paul Jackson wrote:
At the suggestion of Nick Piggin and Dinakar, totally disable
the facility to allow cpu_exclusive cpusets to define dynamic
sched domains in Linux 2.6.13, in order to avoid problems
first reported by John Hawkes (corrupt sched data structures
and kernel oops).
This has been
This is in reference to Chris Wedgwood's patch.
Wouldn't it be better to put overmount_rootfs in initramfs.c
and call it only if there's a initramfs?
printk(KERN_INFO checking if image is initramfs...);
err = unpack_to_rootfs((char *)initrd_start,
On Fri, 26 Aug 2005, Nick Piggin wrote:
Skipping MAP_SHARED in fork() sounds like a good idea to me...
Indeed. Linus, can you remember why we haven't done this before?
Where this looks something like the patch below, shamelessly
merging Nick's and Andy's patches and adding the
On Thu, 2005-08-25 at 21:59 +0800, Yingchao Zhou wrote:
In stop_machine function, there are codes:
if (ret 0) {
stopmachine_set_state(STOPMACHINE_EXIT);
up(stopmachine_mutex);
return ret;
}
And in __stop_machine_run ,there are:
On Thu, 2005-08-25 at 16:09 -0400, Steven Rostedt wrote:
A word of caution (aka. disclaimer). This is still new. I still expect
there are some cases in the code that was missed and can cause a dead
lock or other bad side effect. Hopefully, we can iron these all out.
Also, I noticed that
Who is the memory mapping expert? :)
What are the current file size limits for memory mapping via glibc's
mmap() function on linux:
- for a native 32-Bit System not using LFS?
- for a native 32-Bit System using LFS?
- for a native 64-Bit System?
(linux-kernel 2.6, of course)
It would be nice
John W. Linville wrote:
On Wed, Aug 24, 2005 at 02:52:44PM -0300, Márcio Oliveira wrote:
The command rdev can change the default root partition on x86 linux
systems with pre-built kernels.
Of course...I meant I don't know of anything like that for PPC.
About the CONFIG_CMDLINE
The recent change to locks_remove_flock code in fs/locks.c changes how
byte range locks are removed from closing files, which shows up a bug in
cifs. The assumption in the cifs code was that the close call sent to
the server would remove any pending locks on the server on this file,
but that
--- Ben Greear [EMAIL PROTECTED] wrote:
Danial Thom wrote:
--- Ben Greear [EMAIL PROTECTED]
wrote:
Danial Thom wrote:
I think the concensus is that 2.6 has made
trade
offs that lower raw throughput, which is
what
a
networking device needs. So as a router or
Hi all!
First I would like to thank everyone who commented on my code.
I understand that this won't go into mainline but nevertheless I would
like to work on it further as it is a great learning experience to me.
I incorporated the changes suggested to me by this list (at least I hope
so), any
This is the second of two patches, it implements the setprlimit()
syscall.
Implementation: This patch provides a new syscall setprlimit() for
writing a given process resource limits for i386. Its implementation
follows closely the setrlimit syscall. It is given a pid as an
additional argument. If
On Fri, 26 Aug 2005, Nick Piggin wrote:
Skipping MAP_SHARED in fork() sounds like a good idea to me...
Indeed. Linus, can you remember why we haven't done this before?
Hmm. Historical reasons. Also, if the child ends up needing it, it will
now have to fault them in.
That said, I
On Fri, 2005-08-12 at 14:58 +0200, Ingo Molnar wrote:
FYI, in -53-05 i've added a bh-b_update_lock, which enabled me to get
rid of the bitlock ugliness in fs/buffer.c. Maybe it could be used to
have a better fix for the jbd bitlock thing too?
Well, I just spent several hours trying to use
When skimming through the code I thought that reboot_thru_bios was the
default.
My bad. I retested it and it's reboot=w was the one that works.
If you can't track this down we can at least dig up your board DMI ID
and put it in the list of systems that need to go through the BIOS to reboot.
Hi Bartlomiej,
Thank you for your feedback :), as this is my first dabble in
ide/block drivers I certainly need it!
On 8/25/05, Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote:
+config IDEDISK_FREEZE
Is there any advantage of having it as a config option?
The main reasons I added the
Meelis Roos [EMAIL PROTECTED] writes:
When skimming through the code I thought that reboot_thru_bios was the
default.
My bad. I retested it and it's reboot=w was the one that works.
If you can't track this down we can at least dig up your board DMI ID
and put it in the list of systems that
501 - 570 of 570 matches
Mail list logo
