Miklos Szeredi wrote:
These change still have the undesirable property that although the
modified pages may be flushed to stable storage, the metadata on
the file will not be updated until the application takes positive
action. This is permissible given the current wording in the
While these entry points do not actually modify the file itself,
as was pointed out, they are handy points at which the kernel gains
control and could actually notice that the contents of the file are
no longer the same as they were, ie. modified.
From the operating system viewpoint, this
Miklos Szeredi wrote:
While these entry points do not actually modify the file itself,
as was pointed out, they are handy points at which the kernel gains
control and could actually notice that the contents of the file are
no longer the same as they were, ie. modified.
From the operating
While these entry points do not actually modify the file itself,
as was pointed out, they are handy points at which the kernel gains
control and could actually notice that the contents of the file are
no longer the same as they were, ie. modified.
From the operating system viewpoint,
What happens if the application overwrites what it had written some
time later? Nothing. The page is already read-write, the pte dirty,
so even though the file was clearly modified, there's absolutely no
way in which this can be used to force an update to the timestamp.
Which, I realize
Miklos Szeredi wrote:
What happens if the application overwrites what it had written some
time later? Nothing. The page is already read-write, the pte dirty,
so even though the file was clearly modified, there's absolutely no
way in which this can be used to force an update to the timestamp.
On Feb 28, 2007, at 9:54 AM, Segher Boessenkool wrote:
46 = /dev/ttyCPM0PPC CPM (SCC or SMC) - port 0
...
- 47 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5
+ 49 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5
If CPM0 is 46, then CPM5
Dan Malek wrote:
I don't know the origin of this thread, but none of
that looks correct. Today, there can be up to 8
CPM UART devices, 6 on CPM/CPM2 and 8
on the QE. If ttyCPM0 starts at minor 46, they
should be at least monotonically incrementing
up to ttyCPM7 with minor 53.
Minor nit: On
On Feb 28, 2007, at 12:04 PM, Timur Tabi wrote:
... However, ttyCPM0 is currently assigned to 46, and device 50 is
an Altix serial card. The only way to give the CPM 6 or 8 slots
without moving it is to overlap the Altix card.
Then, this is currently broken in all cases
and needs to be
Dan Malek wrote:
I don't think that would be a problem, and I'd like the
CPM/QE to share devices because it makes the
software distributions common to all Freescale
embedded processors.
I'm willing to use whatever minor number and range the community agrees upon.
An alternative idea, which
On Feb 28, 2007, at 12:35 PM, Timur Tabi wrote:
An alternative idea, which one person already shot down, was to
allow only 4 devices normally, but allow more devices if you use
udev, since udev doesn't care about minor number assignments. This
eliminates the overlap and encourages people
Dan Malek wrote:
I'd shoot that down, too. Using udev in an
embedded, reliable environment is very
troublesome. Although, products I've
developed using more than 4 UARTs had
some custom /dev work done to it just
to get everything mapped. My only
concern is we don't add a new range for
QE
Timur Tabi wrote:
Dan Malek wrote:
I'd shoot that down, too. Using udev in an
embedded, reliable environment is very
troublesome. Although, products I've
developed using more than 4 UARTs had
some custom /dev work done to it just
to get everything mapped. My only
concern is we don't add a
On Feb 28, 2007, at 12:20 PM, Dan Malek wrote:
On Feb 28, 2007, at 1:00 PM, H. Peter Anvin wrote:
I would much rather see these devices moved to a different minor
range.
No. We just did that all too recently, and
i don't know why the minors didn't get
allocated properly. I don't want to
Kumar Gala wrote:
Why don't we allocate the 2nd group of four as well, just at a new
location. They'll be discontinuous, but at least we'll have support for
all 8.
Right, it means two tty driver structures, but that's not a problem.
-hpa
-
To unsubscribe from this list: send the
Dan Malek wrote:
Just allocate the four slots and we'll deal with
anything above this in custom products.
Assuming that this is the agreed-upon standard, should I arbitrarily restrict my driver to
4 ports, or allow all 8?
I assume that if a driver already claims a particular major/minor
Just allocate the four slots and we'll deal with
anything above this in custom products.
Another option is to use 46..49 for UARTs #0..3,
and 192..195 for UARTs #4..7.
Or, perhaps better, use 46..49 for #0..3, and
192..199 for #0..7, handling the duplication in
the driver; and deprecate the
Segher Boessenkool wrote:
Just allocate the four slots and we'll deal with
anything above this in custom products.
Another option is to use 46..49 for UARTs #0..3,
and 192..195 for UARTs #4..7.
Or, perhaps better, use 46..49 for #0..3, and
192..199 for #0..7, handling the duplication in
the
H. Peter Anvin wrote:
Kumar Gala wrote:
Why don't we allocate the 2nd group of four as well, just at a new
location. They'll be discontinuous, but at least we'll have support
for all 8.
Right, it means two tty driver structures, but that's not a problem.
Eh, I'm not crazy about that.
On Feb 28, 2007, at 1:30 PM, Timur Tabi wrote:
H. Peter Anvin wrote:
Kumar Gala wrote:
Why don't we allocate the 2nd group of four as well, just at a
new location. They'll be discontinuous, but at least we'll have
support for all 8.
Right, it means two tty driver structures, but
Kumar Gala wrote:
Eh, I'm not crazy about that. That means that I have to complicate my
driver because someone else screwed up a long time ago.
If not you someone else. The cost in the driver is small compared to
fixing up all the distro's and such. If you don't provide this change
Another option is to use 46..49 for UARTs #0..3,
and 192..195 for UARTs #4..7.
Or, perhaps better, use 46..49 for #0..3, and
192..199 for #0..7, handling the duplication in
the driver; and deprecate the old range.
That sounds like more hassle than it's worth. The discontinuous range
may be
On Feb 28, 2007, at 2:43 PM, Timur Tabi wrote:
What about major number 205? It also has the screwed-up /dev/
ttyCPM entries, but it has more room, and the CPM driver doesn't
actually use it. At least, I can't see where it uses it.
Please, let's just leave the four we have and let
the
Please, let's just leave the four we have
No one is suggesting otherwise.
and let
the driver just allocate increasing minor numbers.
If anyone has a product with more than 4 UARTs,
they will have to figure out what to do with the
additional minors.
Since you say no one has ever used more
On Feb 28 2007 20:25, Segher Boessenkool wrote:
Just allocate the four slots and we'll deal with
anything above this in custom products.
Another option is to use 46..49 for UARTs #0..3,
and 192..195 for UARTs #4..7.
Or, perhaps better, use 46..49 for #0..3, and
192..199 for #0..7,
PNP now initializes device dma masks, which prevents oopses when generic
dma calls are made using pnp device nodes.
This assumes PNP only uses ISA DMA, with 24 bit addresses; and that it's
safe to init those masks for all devices (rather than finding out which
devices have been assigned DMA
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.
Signed-off-by: David Brownell [EMAIL PROTECTED]
Index: g26/MAINTAINERS
* Linus Torvalds [EMAIL PROTECTED] wrote:
So I would repeat my call for getting rid of the atoms, and instead
just do a single submission at a time. Do the linking by running a
threadlet that has user space code (and the stack overhead), which is
MUCH more flexible. And do nonlinked
Gerhard Mack wrote:
On Wed, 28 Feb 2007, Charles Shannon Hendrix wrote:
On Wed, 28 Feb 2007 13:25:00 -0500 (EST)
Gerhard Mack [EMAIL PROTECTED] wrote:
In another thread, I think they were saying it was either a SATA chipset
driver bug, or a problem in libata core.
I also have an nforce4.
On Wed, Feb 28, 2007 at 09:41:44PM +0100, Andi Kleen wrote:
Likely already too late then -- if critical state is overwritten
you crashed before. Also a lot of stack intensive codes
relatively large unused holes so it might miss the canary completely
Anyways if you want a crash on context
Charles Shannon Hendrix wrote:
On Wed, 28 Feb 2007 07:40:23 -0500 (EST)
Gerhard Mack [EMAIL PROTECTED] wrote:
hello,
Can someone tell me what this means?
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x40 action 0x2 frozen
ata1.00: cmd 35/00:00:40:a6:23/00:04:00:00:00/e0 tag 0 cdb 0x0 data
2.6.21-rc2-git2
from some make randconfig
# CONFIG_SMP is not set
CONFIG_X86_VOYAGER=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
LD .tmp_vmlinux1
arch/i386/kernel/built-in.o: In function `vic_sys_interrupt':
(.text+0x3141): undefined reference to `smp_vic_sys_interrupt'
On Wed, 28 Feb 2007, Robert Hancock wrote:
Gerhard Mack wrote:
On Wed, 28 Feb 2007, Charles Shannon Hendrix wrote:
On Wed, 28 Feb 2007 13:25:00 -0500 (EST)
Gerhard Mack [EMAIL PROTECTED] wrote:
In another thread, I think they were saying it was either a SATA
chipset
Greg KH [EMAIL PROTECTED] writes:
On Wed, Feb 28, 2007 at 05:28:27AM -0700, Eric W. Biederman wrote:
What are the rules that are supposed to govern backports to stable
trees these days anyway?
Documentation/stable_kernel_rules.txt
Ok if that is really what we are going with, the this
On Feb 28 2007 15:20, Bill Irwin wrote:
I don't know about the rest of the world, but halting the system in the
case of memory corruption sounds like an extremely good idea to me.
Just because a rather unimportant driver (e.g. parport) might oops
thanks to a now-invalid address after memory
Hello,
On an embedded system, I use two ramdisks. They are both
16 megabytes in size. I can create them interactively in
the normal way with mke2fs. However, when the system is
booted using isolinux, the RAM disks become corrupted.
Apparently isolinux.cfg's ramdisk_size (not documented,
only
Chuck Ebbert [EMAIL PROTECTED] writes:
Starting with kernel 2.6.19, the process directories in
/proc are sorted by number. They were sorted by process
start time in 2.6.18 and earlier. This makes the output
of procps come out in that order too, pissing off users
who are used to the old way.
On Feb 28 2007 15:20, Bill Irwin wrote:
I don't know about the rest of the world, but halting the system in the
case of memory corruption sounds like an extremely good idea to me.
On Thu, Mar 01, 2007 at 12:36:47AM +0100, Jan Engelhardt wrote:
Just because a rather unimportant driver (e.g.
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.
Signed-off-by:
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 seen announcements of Linux systems that support MOST:
http://linuxdevices.com/news/NS2586090082.html
But I have
New hwmon drivers since 2.6.16.42 for the following hardware:
- National Semiconductor pc87427
- SMSC lpc47m192 and lpc47m997
- Winbond w83791d
Location:
ftp://ftp.kernel.org/pub/linux/kernel/people/bunk/linux-2.6.16.y/testing/
git tree:
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 when the serial port is configured,
any attempts to alter the
On Tuesday 27 February 2007 6:43 pm, Gregor Jasny wrote:
Hi,
2007/2/28, Rob Landley [EMAIL PROTECTED]:
I ran make ARCH=x86_64 menuconfig, did a lot of editing, and saved
the .config. Then I copied that to a backup, ran make oldconfig on the
I'd try with make ARCH=x86_64 oldconfig
I
Hello,
* 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 seen announcements of Linux systems that support MOST:
I was playing with some code that sometimes got a string where a %n
match should have been done where the input string ended, for example
like this:
sscanf(abc123, abc%d%n, a, n);
However, the scanf function in the kernel doesn't convert the %n in that
case because it has already matched the
On Tuesday 27 February 2007 6:36 pm, Randy Dunlap wrote:
The first hunk I expect, the second I did not. Anybody care to venture a
guess why the visibility logic is unstable?
can we get .config^Wtryit ? (version 0, not version 1)
Unfortunately, the first .config was generated by me
If you'll recall, over a year ago, I pointed out that the current
Radeon driver erroneously returns -EINVAL for valid blanking codes,
here is a link to that thread:
http://lkml.org/lkml/2006/1/28/6
No other driver does this, and it confuses the X server into thinking
that the device
On 2/27/07, Nish Aravamudan [EMAIL PROTECTED] wrote:
On 2/27/07, Bill Davidsen [EMAIL PROTECTED] wrote:
Paulo Marques wrote:
Rik van Riel wrote:
J.A. Magallón wrote:
[...]
Its the same to answer 4+4 queries than 8 at half the speed, isn't it ?
That still doesn't fix the potential
Gerhard Mack wrote:
Sorry for the false alarm,
There is one thing that seems odd, if you do have an nForce4 chipset, the
kernel should be running the SATA controller in ADMA mode in 2.6.20, but it
doesn't seem like it is from your dmesg output. Can you post the output of
lspci -vvn? Also what
On Wed, 2007-02-28 at 10:13 +, David Woodhouse wrote:
On Wed, 2007-02-28 at 07:43 +0100, Benjamin Herrenschmidt wrote:
I wouldn't be that sure ... I've had problems in the past with PMU based
cpufreq... looks like flushing all caches and hard-resetting the
processor on the fly when
will likely also trigger the oops.
Libhugetlbfs can be downloaded from:
http://libhugetlbfs.ozlabs.org/snapshots/libhugetlbfs-dev-20070228.tar.gz
I have collected the following information:
Thanks. I'm going to be offline starting early tomorrow so I'm
unfortunately not going to be timely in tracing
On Sat, 24 Feb 2007 12:22:11 +
Ralf Baechle [EMAIL PROTECTED] wrote:
sysdev.h uses THIS_MODULE so should include linux/module.h.
Signed-off-by: Ralf Baechle [EMAIL PROTECTED]
diff --git a/include/linux/sysdev.h b/include/linux/sysdev.h
index 389ccf8..e699ab2 100644
---
On Wed, 28 Feb 2007, David Miller wrote:
Maybe if you managed your individual changes in GIT or similar
this could be debugged very quickly. :-)
I think once things calm down and the changes become smaller its going
to be easier. Likely the case with after V4.
Meanwhile I noticed that your
On 2/28/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
Chuck Ebbert [EMAIL PROTECTED] writes:
Starting with kernel 2.6.19, the process directories in
/proc are sorted by number. They were sorted by process
start time in 2.6.18 and earlier. This makes the output
of procps come out in that
On Tue, 27 Feb 2007, Andrew Morton wrote:
On Mon, 26 Feb 2007 17:35:17 -0800 Stephen Hemminger [EMAIL PROTECTED]
wrote:
The kernel already has several implmentations and usages of 64 by 64
bit divide.
Although it is significantly slower, there are places that need it so
provide
On Wed, 28 Feb 2007, Robert Hancock wrote:
Date: Wed, 28 Feb 2007 18:21:48 -0600
From: Robert Hancock [EMAIL PROTECTED]
To: Gerhard Mack [EMAIL PROTECTED]
Cc: linux-kernel linux-kernel@vger.kernel.org,
Charles Shannon Hendrix [EMAIL PROTECTED]
Subject: Re: 2.6.20 SATA error
Gerhard
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
user-space code without having to exit out of kernel mode too
frequently) Or perhaps a
The patch is for tracking writes made to a loop device made through
mmap.
A file_operations structure variable called loop_fops is initialised
with the default block device file operations (def_blk_fops).
The mmap operation is overriden with a new function called
loop_file_mmap.
A
From: Christoph Lameter [EMAIL PROTECTED]
Date: Wed, 28 Feb 2007 17:06:19 -0800 (PST)
On Wed, 28 Feb 2007, David Miller wrote:
Arguably SLAB_HWCACHE_ALIGN and SLAB_MUST_HWCACHE_ALIGN should
not be set here, but SLUBs change in semantics in this area
could cause similar grief in other
On Wed, 2007-02-28 at 16:20 -0800, David Miller wrote:
If you'll recall, over a year ago, I pointed out that the current
Radeon driver erroneously returns -EINVAL for valid blanking codes,
here is a link to that thread:
http://lkml.org/lkml/2006/1/28/6
No other driver does this, and
On Wed, Feb 28, 2007 at 10:41:17PM +0100, Ingo Molnar wrote:
From: Ingo Molnar [EMAIL PROTECTED]
add include/linux/syslet.h which contains the user-space API/ABI
declarations. Add the new header to include/linux/Kbuild as well.
Hi Ingo,
I'd like to propose a simpler userspace API for
On Wed, 28 Feb 2007, Roland McGrath wrote:
It is true that debug registers are inherited by fork and clone.
I am 99% sure that this was never specifically intended, but it
has been this way for a long time (since 2.4 at least). It's an
implicit consequence of the do_fork implementation
Alan,
On Wed, Feb 28, 2007 at 07:01:17PM -0500, Alan Stern wrote:
On Wed, 28 Feb 2007, Roland McGrath wrote:
It is true that debug registers are inherited by fork and clone.
I am 99% sure that this was never specifically intended, but it
has been this way for a long time (since 2.4 at
Hi,
I have a laptop Toshiba A70, I attach a DMESG so you know my system.
The problem is that the system hang randomly and I don't know why, I can se
nothing on /var/log/message realted to the hang (I have to force a shutdown
first).
With the NOAPIC option the hang just delay or dismish in
On Monday 26 February 2007 12:54 am, Sarah Bailey wrote:
On Sun, Feb 25, 2007 at 08:53:03AM -0800, David Brownell wrote:
On Sunday 25 February 2007 12:57 am, Sarah Bailey wrote:
I haven't seen any evidence that the kernel-side aio is substantially
more efficient than the GNU libc
Add a missing #define for the platform_kernel_launch_event.
Without this fix, a call to platform_kernel_launch_event()
becomes a noop on generic kernels. SN systems require this
fix to successfully kdump/kexec from certain hardware errors.
Signed-off-by: John Keller [EMAIL PROTECTED]
---
Index:
Subject: ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin [EMAIL PROTECTED]
Handled-By : Ingo Molnar [EMAIL PROTECTED]
Status : unknown
Just reproduced this in -rc2.
Another thing I noticed:
with 2.6.20, pressing
On Wed, 2007-02-28 at 23:13 +0200, Michael S. Tsirkin wrote:
Subject: ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin [EMAIL PROTECTED]
Handled-By : Ingo Molnar [EMAIL PROTECTED]
Status : unknown
Just
Hi!
Well I had an idea after looking at k8temp -- why not make it default to
doing only reads from the sensor? You'd only get information from whatever
core/sensor combination that ACPI had last used, but it would be safe.
ACPI is broken here, not k8temp, so let's fix ACPI instead. ACPI
Quoting Thomas Gleixner [EMAIL PROTECTED]:
Subject: Re: 2.6.21-rc1: known regressions (v2) (part 1)
On Wed, 2007-02-28 at 23:13 +0200, Michael S. Tsirkin wrote:
Subject: ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S.
This exception appears to be originating somewhere in the EC driver:
ACPI Exception (evregion-0420): AE_NOT_FOUND, Returned by Handler for
[EmbeddedControl] [20070126]
-Original Message-
From: [EMAIL PROTECTED] [mailto:linux-acpi-
[EMAIL PROTECTED] On Behalf Of Meelis Roos
Sent:
To provide compatibilty with SN kernels that do and do not
have ACPI IO support, the SN PROM must build different
versions of some ACPI tables based on which kernel is booting.
As such, the tables may have to change at kernel boot time.
By default, prior to kernel boot, the PROM builds an empty
Arkadiusz,
Could try the attached patch to see if it solves the problem?
If not, please send the output of acpidump command and log.
Regards.
Konstantin.
-Original Message-
From: Adrian Bunk [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 25, 2007 8:53 PM
To: Linus Torvalds; Andrew
If a process is closing /dev/input/mice and an mouse disconnects simulta-
neously, the system is likely to oops. This usually happens when someone
hits AltCtrlF1 or logs out from X, and flips a KVM while the system
is reacting.
I reproduced the issue by running this:
while true; do cat
Ingo Molnar wrote:
Yes, but it happens after asm/paravirt.h has already included some
things, and it ends up causing problems. paravirt.h still defines
various stub functions in the !CONFIG_PARAVIRT case, so it needs to do
the includes either way.
hm, it then needs to be fixed
On Wed, 2007-02-28 at 09:32 +0100, Ingo Molnar wrote:
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
+#ifdef CONFIG_PARAVIRT
+/* After pte_t, etc, have been defined */
+#include asm/paravirt.h
+#endif
hm - there's already a CONFIG_PARAVIRT conditional in
On 3/1/07, Michael S. Tsirkin [EMAIL PROTECTED] wrote:
with 2.6.20, pressing Fn/F4 generates an ACPI event and triggers suspend to RAM.
On 2.6.21-rc2, after resume (when the box is accessible from network),
pressing Fn/F4 again does not seem to have any effect.
I have the same problem on my
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.
Signed-off-by: Tony Breeds [EMAIL PROTECTED]
Signed-off-by: Jens Axboe [EMAIL
Hi folks,
Here is the update version of blackfin-arch.patch in -mm tree.
simply add support to utrace and it was tested on blackfin STAMP board
as well as other following patches.
The whole patch is located at URL:
https://blackfin.uclinux.org/gf/download/frsrelease/39/2583/blackfin-arch.patch
Hi folks,
Here is the update version of blackfin serial driver in -mm tree.
Fixed some bugs and please rename the patch file to
blackfin-driver-serial-core.patch.
[PATCH] Blackfin: serial driver for Blackfin architecture
This patch implements the driver necessary use the Analog Devices Blackfin
Hi folks,
As SMC91X ethernet controller are used in blackfin STAMP 533 development
board, this patch add blackfin support to the smc91x linux driver.
It's name is blackfin-driver-net-stamp533.patch.
[PATCH] Blackfin: patch add blackfin support in smc91x ethernet
controller driver
Hi folks,
Here is the blackfin on-chip RTC controller driver for Linux.
It's name is blackfin-driver-rtc.patch
[PATCH] Blackfin: on-chip RTC controller driver
This patch implements the driver necessary use the Analog Devices
Blackfin processor's on-chip RTC controller.
Signed-off-by: Bryan Wu
On Tuesday 20 February 2007 04:19, Nicolas Ferre wrote:
Add support for the ads7843 touchscreen controller to the ads7846
driver code.
Applied to the input tree, thank you.
--
Dmitry
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
The patch is for tracking writes made to a loop device made through mmap.
A file_operations structure variable called loop_fops is initialised with the
default block device file operations (def_blk_fops).
The mmap operation is overriden with a new function called loop_file_mmap.
A
On Thu, 2007-03-01 at 09:01 +1100, Con Kolivas wrote:
On Wednesday 28 February 2007 15:21, Mike Galbraith wrote:
On Wed, 2007-02-28 at 09:58 +1100, Con Kolivas wrote:
On Tuesday 27 February 2007 19:54, Mike Galbraith wrote:
Agreed.
I was recently looking at that spot because I
On Mon, 26 Feb 2007 00:45:00 -0600 [EMAIL PROTECTED] (Florin Iucha) wrote:
Hello, it's me and my 70 GB of photos again.
I have tested both CIFS and NFSv4 clients in kernel 2.6.20-rc1 . CIFS
passed with flying colors and NFSv4 stalled after 7 GB.
Configuration:
Server: PIII/1GHz, 512
On Mon, 26 Feb 2007 12:10:37 -0800 Mathieu Desnoyers [EMAIL PROTECTED] wrote:
Hi,
How come I'm the only person around here with a Reply button?
Looking into the thread flags, I found out that some architecture
specific kernel functions (in 2.6.20) sets the thread flags with non
atomic
On Tue, 27 Feb 2007 07:22:00 -0500 Prarit Bhargava [EMAIL PROTECTED] wrote:
Replace call_smp_function with stop_machine_run in the Intel RNG driver.
CPU A has done read_lock(lock)
CPU B has done write_lock_irq(lock) and is waiting for A to release the lock.
A third CPU calls
On Mon, 2006-11-20 at 18:45 +0100, Arnd Bergmann wrote:
plain text document attachment (spufs-master-control.diff)
When the user changes the runcontrol register, an SPU might be
running without a process being attached to it and waiting for
events. In order to prevent this, make sure we always
From: Andrew Morton [EMAIL PROTECTED]
Date: Wed, 28 Feb 2007 22:03:49 -0800
On Mon, 26 Feb 2007 12:10:37 -0800 Mathieu Desnoyers [EMAIL PROTECTED]
wrote:
Other examples :
sparc64/kernel/ptrace.c:if
((task_thread_info(child)-flags _TIF_32BIT) != 0) {
linux-kernel-markers-architecture-independant-code-flags
- GEN_MARK changed for MARK_GENERIC is now declared in linux/marker.h
- Adds the MF_* flags than can be used by the _MARK macro
MF_OPTIMIZED (Use optimized markers)
MF_LOCKDEP (Can call lockdep)
MF_PRINTK (vprintk can be called in the
linux-kernel-markers-kconfig-menus-fix-5
- Change CONFIG_MARKERS_ENABLE_OPTIMIZATION for
CONFIG_MARKERS_DISABLE_OPTIMIZATION.
- Have CONFIG_MARKERS_DISABLE_OPTIMIZATION depend on EMBEDDED.
Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED]
--- a/kernel/Kconfig.marker
+++
linux-kernel-markers-powerpc-optimization-flags
Add flag support to powerpc optimization
Fix the .section .markers, \a\, @progbits;\n\t inline assembly :
adding the @progbits seems to remove a warning from the linker (forces
the section to DATA, which is the same a what the MARK_GENERIC version
linux-kernel-markers-i386-optimization-flags
i386 marker optimization flags support.
Also fixes the @progbits assembly section declaration.
Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED]
--- a/arch/i386/kernel/marker.c
+++ b/arch/i386/kernel/marker.c
@@ -40,7 +40,7 @@ static int
On Tue, 2007-02-27 at 13:54 -0500, Dale Blount wrote:
On Fri, 2007-02-23 at 12:00 -0500, Dale Blount wrote:
Hi,
Excuse me if this has been covered or fixed, I couldn't find anything in
the archives.
I upgraded from 2.6.11.7 to 2.6.20.1 today and found all the drives
connected to 2
On Tue, 27 Feb 2007 23:38:12 +0100 Miklos Szeredi [EMAIL PROTECTED] wrote:
From: Miklos Szeredi [EMAIL PROTECTED]
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
On Tue, 27 Feb 2007 23:38:13 +0100 Miklos Szeredi [EMAIL PROTECTED] wrote:
From: Miklos Szeredi [EMAIL PROTECTED]
This deadlock is similar to the one in balance_dirty_pages, but
instead of waiting in balance_dirty_pages after submitting a write
request, it happens during a memory allocation
linux-kernel-markers-non-optimized-architures-fallback-flags
- asm-generic/marker.h is now only used as a fallback defining _MARK as
MARK_GENERIC.
- flags support
Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED]
--- a/include/asm-generic/marker.h
+++ b/include/asm-generic/marker.h
@@ -1,8
linux-kernel-markers-documentation-update-flags
Documents the flag usage.
Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED]
--- a/Documentation/marker.txt
+++ b/Documentation/marker.txt
@@ -78,6 +78,21 @@ which saves a data cache hit, but also requires cross CPU
code modification. In
order
What happens if the application overwrites what it had written some
time later? Nothing. The page is already read-write, the pte dirty,
so even though the file was clearly modified, there's absolutely no
way in which this can be used to force an update to the timestamp.
Which,
601 - 700 of 728 matches
Mail list logo
