Zan Lynx wrote:
I have been running 2.6.20-rc2-mm1 without problems, but both rc3-mm1
and rc4-mm1 have been giving me these freezes. They were happening
inside X and without external console it was impossible to get anything,
plus I was reluctant to test it since the freeze sometimes requires a
On 2006-11-17, Oleg Verych wrote:
> On Tue, Oct 31, 2006 at 02:51:36PM +0100, olecom wrote:
> []
>> On Tue, Oct 31, 2006 at 02:14:16AM +0100, Horst Schirmeier wrote:
> []
>> > I'm not sure what you mean by $(objdir); I just got something to work
>> > which creates the /dev/null symlink in a (newly
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/ehea/ehea.h |2 +-
drivers/net/ehea/ehea_main.c | 56 +-
what about removing psmouse module?
On 1/23/07, Jean-Marc Valin <[EMAIL PROTECTED]> wrote:
>>> will be a device driver. Common causes of suspend/resume problems from
>>> the list you give below are acpi modules, bluetooth and usb. I'd also be
>>> consider pcmcia, drm and fuse possibilities. But
On Mon, 2007-01-22 at 22:22 -0800, Randy Dunlap wrote:
> On Mon, 22 Jan 2007 22:02:30 -0800 Don Mullis wrote:
>
> >
> > Bisection shows the bad patch to be:
> > gregkh-driver-uio-documentation.patch
> >
> > The htmldocs build failure can be eliminated by:
> > quilt remove
On Mon, Jan 22, 2007 at 10:02:30PM -0800, Don Mullis wrote:
>
> Bisection shows the bad patch to be:
> gregkh-driver-uio-documentation.patch
>
> The htmldocs build failure can be eliminated by:
> quilt remove Documentation/DocBook/kernel-api.tmpl
>
> The error messages were:
>
>
On Mon, 22 Jan 2007 22:02:30 -0800 Don Mullis wrote:
>
> Bisection shows the bad patch to be:
> gregkh-driver-uio-documentation.patch
>
> The htmldocs build failure can be eliminated by:
> quilt remove Documentation/DocBook/kernel-api.tmpl
or by: quilt delete
Henrique de Moraes Holschuh wrote:
> Does SATA electrical conector keying let the disk firmware unload
> heads before the user manages to pull it out enough to sever power?
I don't think so.
> If it does not, the drive will do an emergency head unload, which is
> not good and will likely reduce
On 2006-12-13, Robert P. J. Day wrote:
>
> Replace the very few remaining "depends" Kconfig directives with
> "depends on".
>
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
>
> ---
For this kind of fixes, please use
"kconfig" subsystem instead of
"kbuild" in subject. Thanks.
-
To
Soeren Sonnenburg wrote:
> OK, how about this (please especially check the non SIL part):
>
> SATA Hotplug from the User Side
>
> - For SIL3114 and SIL3124 you don't have to run any commands at all. It
ahci and ck804 flavor of sata_nv's can do hotplug without user
assistance too.
[--snip--]
>
On 2006-12-29, Tim Schmielau wrote:
[]
> OK, building 2.6.20-rc2-mm1 with all 59 configs from arch/arm/configs
> with and w/o the patch indeed found one mysterious #include that may not
> be removed. Thanks, Russell!
>
> Andrew, please use the attached patch instead of the previous one, it also
Bisection shows the bad patch to be:
gregkh-driver-uio-documentation.patch
The htmldocs build failure can be eliminated by:
quilt remove Documentation/DocBook/kernel-api.tmpl
The error messages were:
.../linux-2.6.19 $ make htmldocs
DOCPROC
Thomas Klein wrote:
Not only check the pointer against 0 but also the dereferenced value
Signed-off-by: Thomas Klein <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h |2 +-
drivers/net/ehea/ehea_main.c |6 --
2 files changed, 5 insertions(+), 3 deletions(-)
applied 1-7 to
Jay Cliburn wrote:
This is the latest submittal of the patchset providing support for the
Attansic L1 gigabit ethernet adapter. This patchset is built against
kernel version 2.6.20-rc5.
This version incorporates all comments from:
Christoph Hellwig:
http://lkml.org/lkml/2007/1/11/43
Uses the block notifier to replace the functionality of update_callback().
update_callback() was a special case specifically for the tsc, but including
it in the clocksource structure duplicated it needlessly for other clocks.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
Modifies the way clocks are switched to in the timekeeping code. The original
code would constantly monitor the clocksource list checking for newly added
clocksources. I modified this by using atomic types to signal when a new clock
is added. This allows the operation to be used only when it's
Converts the original plain list into a sorted list based on the clock rating.
Later in my tree this allows some of the variables to be dropped since the
highest rated clock is always at the front of the list. This also does some
other nice things like allow the sysfs files to print the clocks in
Update arch/arm/ with list initialization.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
arch/arm/mach-imx/time.c |1 +
arch/arm/mach-ixp4xx/common.c |1 +
arch/arm/mach-netx/time.c |1 +
arch/arm/mach-pxa/time.c |1 +
4 files changed, 4 insertions(+)
Update arch/avre32/ with list initialization.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
arch/avr32/kernel/time.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.19/arch/avr32/kernel/time.c
===
---
Update arch/i386/ with list initialization.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
arch/i386/kernel/hpet.c |1 +
arch/i386/kernel/i8253.c |1 +
arch/i386/kernel/tsc.c |1 +
3 files changed, 3 insertions(+)
Index: linux-2.6.19/arch/i386/kernel/hpet.c
Update arch/mips/ with list initialization.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
arch/mips/kernel/time.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.19/arch/mips/kernel/time.c
===
---
Update arch/x86_64/ with list initialization.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/hpet.c |1 +
arch/x86_64/kernel/tsc.c |1 +
2 files changed, 2 insertions(+)
Index: linux-2.6.19/arch/x86_64/kernel/hpet.c
Update drivers/clocksource/ with list initialization.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
drivers/clocksource/acpi_pm.c|1 +
drivers/clocksource/cyclone.c|1 +
drivers/clocksource/scx200_hrt.c |1 +
3 files changed, 3 insertions(+)
Index:
A change to clocksource initialization. If the list field is initialized
it allows clocksource_register to complete faster since it doesn't have
to scan the list of clocks doing strcmp on each looking for duplicates.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
Adds a call back interface for register/rating change events. This is also used
later in this series to signal other interesting events.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
include/linux/clocksource.h | 37 +
include/linux/timekeeping.h |
Move the generic timekeeping code from kernel/timer.c to
kernel/time/timekeeping.c . This requires some glue code which is
added to the include/linux/timekeeping.h header.
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
include/linux/clocksource.h |3
include/linux/timekeeping.h |
This patchset represents the most stable clocksource changes in my tree. Also
John (and others) have reviewed these changes a few times. I think it's all
acceptable.
Daniel
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Rik van Riel wrote:
Nick Piggin wrote:
The other nice thing about it was that it didn't have a hard
cutoff that the current reclaim_mapped toggle does -- you could
opt to scan the mapped list at a lower ratio than the unmapped
one. Of course, it also has some downsides too, and would
require
Hi Dann,
On Mon, Jan 22, 2007 at 11:19:43AM -0700, dann frazier wrote:
> On Mon, Jan 22, 2007 at 10:50:47AM +1100, Grant Coady wrote:
> > On Mon, 22 Jan 2007 00:03:21 +0100, Willy Tarreau <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED]:/home/other$ uname -r
> > 2.4.34b
> > [EMAIL
On Mon, 2007-01-22 at 09:57 +0100, Xavier Roche wrote:
> Hi folks,
>
> I have a probably louzy question regarding sigaction() behaviour when an
> alternate signal stack is used: it seems that I can not get the user
> stack reference in the ucontext_t stack context ; ie. the uc_stack
> member
Remove bits left over from prior ftape removal.
Please pull from 'ftape' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git ftape
to receive the following updates:
include/linux/Kbuild |1 -
include/linux/mtio.h | 146
JFFS is already marked CONFIG_BROKEN in fs/Kconfig, with a note that
it's going away in 2.6.21, but the corresponding update to
feature-removal-schedule.txt was accidentally omitted. Fixed.
Please pull from 'kill-jffs-prep' branch of
Nick Piggin wrote:
Balbir Singh wrote:
This makes me wonder if it makes sense to split up the LRU into page
cache LRU and mapped pages LRU. I see two benefits
1. Currently based on swappiness, we might walk an entire list
searching for page cache pages or mapped pages. With these
lists
re-code my patch, tab = 8. Sorry!
Signed-off-by: Yunfeng Zhang <[EMAIL PROTECTED]>
Index: linux-2.6.19/Documentation/vm_pps.txt
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.19/Documentation/vm_pps.txt
Björn Steinbrink wrote:
Hm, I don't think it is unhappy about looking at NV_INT_STATUS_CK804.
I'm running 2.6.20-rc5 with the INT_DEV check removed for 8 hours now
without a single problem and that should still look at
NV_INT_STATUS_CK804, right?
I just noticed that my last email might not have
On Thu, 18 Jan 2007, Andi Kleen wrote:
> > let me know what you think... thanks.
>
> It's ok, although I would like to have the file in a separate directory.
cool -- do you have a directory in mind?
and would you like this change as two separate patches or one combined
patch?
thanks
-dean
-
Hi,
>>>(run echo 1 > coremask, echo 0 > coremask in a loop while dumping
>>>core. Do you have enough locking to make it work as expected?)
>>
>>Currently, any lock isn't acquired. But I think the kernel only
>>have to preserve the coremask setting in a local variable at the
>>begining of core
>>> will be a device driver. Common causes of suspend/resume problems from
>>> the list you give below are acpi modules, bluetooth and usb. I'd also be
>>> consider pcmcia, drm and fuse possibilities. But again, go for unloading
>>> everything possible in the first instance.
>> Actually, the
>> I just encountered the following oops and general protection fault
>> trying to suspend/resume my laptop. I've got a Dell D820 laptop with a 2
>> GHz Core 2 Duo CPU. It usually suspends/resumes fine but not always. The
>> relevant errors are below but the full dmesg log is at
>>
Nick Piggin wrote:
The other nice thing about it was that it didn't have a hard
cutoff that the current reclaim_mapped toggle does -- you could
opt to scan the mapped list at a lower ratio than the unmapped
one. Of course, it also has some downsides too, and would
require retuning...
Here's a
Patched against 2.6.19 leads to:
mm/vmscan.c: In function `shrink_pvma_scan_ptes':
mm/vmscan.c:1340: too many arguments to function `page_remove_rmap'
So changed
page_remove_rmap(series.pages[i], vma);
to
page_remove_rmap(series.pages[i]);
I've worked on 2.6.19, but when update to
Balbir Singh wrote:
This makes me wonder if it makes sense to split up the LRU into page
cache LRU and mapped pages LRU. I see two benefits
1. Currently based on swappiness, we might walk an entire list
searching for page cache pages or mapped pages. With these
lists separated, it should
On Tue, 23 Jan 2007, Balbir Singh wrote:
> Yes, good point, I see what you mean in terms of impact. But the trade
> off could come from shrink_active_list() which does
>
> list_del(>lru)
> if (!reclaim_mapped && other_conditions)
> list_add(>lru, _active);
> ...
>
> In the case mentioned
Christoph Lameter wrote:
perfmon can do much of what you are looking for.
Thanks, I'll look into it.
--
Balbir Singh
Linux Technology Center
IBM, ISTL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Christoph Lameter wrote:
On Tue, 23 Jan 2007, Balbir Singh wrote:
When you unmap or map, you need to touch the pte entries and know the
pages involved, so shouldn't be equivalent to a list_del and list_add
for each page impacted by the map/unmap operation?
When you unmap and map you must
On Tue, 23 Jan 2007, Balbir Singh wrote:
> I have always wondered if it would be useful to have a kernel debug
> feature that can extract page references per task, it would be good
> to see the page references (last 'n') of a workload that is not
> doing too well on a particular system.
perfmon
Rik van Riel wrote:
Christoph Lameter wrote:
With the proposed schemd you would have to move pages between lists if
they are mapped and unmapped by a process. Terminating a process could
lead to lots of pages moving to the unnmapped list.
That could be a problem.
Another problem is that any
From: Dan Williams <[EMAIL PROTECTED]>
handle_stripe sets STRIPE_OP_PREXOR, STRIPE_OP_BIODRAIN, STRIPE_OP_POSTXOR
to request a write to the stripe cache. raid5_run_ops is triggerred to run
and executes the request outside the stripe lock.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
---
From: Dan Williams <[EMAIL PROTECTED]>
handle_stripe sets STRIPE_OP_COMPUTE_BLK to request servicing from
raid5_run_ops. It also sets a flag for the block being computed to let
other parts of handle_stripe submit dependent operations. raid5_run_ops
guarantees that the compute operation
From: Dan Williams <[EMAIL PROTECTED]>
Prepare the raid5 implementation to use async_tx for running stripe
operations:
* biofill (copy data into request buffers to satisfy a read request)
* compute block (generate a missing block in the cache from the other
blocks)
* prexor (subtract existing
From: Dan Williams <[EMAIL PROTECTED]>
Each stripe has three flag variables to reflect the state of operations
(pending, ack, and complete).
-pending: set to request servicing in raid5_run_ops
-ack: set to reflect that raid5_runs_ops has seen this request
-complete: set when the operation is
From: Dan Williams <[EMAIL PROTECTED]>
handle_stripe now only updates the state of stripes. All execution of
operations is moved to raid5_run_ops.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
---
drivers/md/raid5.c | 68
1 files
From: Dan Williams <[EMAIL PROTECTED]>
replaced by raid5_run_ops
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
---
drivers/md/raid5.c | 124
1 files changed, 0 insertions(+), 124 deletions(-)
diff --git a/drivers/md/raid5.c
From: Dan Williams <[EMAIL PROTECTED]>
Use raid5_run_ops to carry out the memory copies for a raid5 read request.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
---
drivers/md/raid5.c | 40 +++-
1 files changed, 15 insertions(+), 25 deletions(-)
diff
From: Dan Williams <[EMAIL PROTECTED]>
This is a driver for the iop DMA/AAU/ADMA units which are capable of pq_xor,
pq_update, pq_zero_sum, xor, dual_xor, xor_zero_sum, fill, copy+crc, and copy
operations.
Changelog:
* fixed a slot allocation bug in do_iop13xx_adma_xor that caused too few
slots
From: Dan Williams <[EMAIL PROTECTED]>
handle_stripe sets STRIPE_OP_CHECK to request a check operation in
raid5_run_ops. If raid5_run_ops is able to perform the check with a
dma engine the parity will be preserved in memory removing the need to
re-read it from disk, as is necessary in the
From: Dan Williams <[EMAIL PROTECTED]>
The parity calculation for an expansion operation is the same as the
calculation performed at the end of a write with the caveat that all blocks
in the stripe are scheduled to be written. An expansion operation is
identified as a stripe with the POSTXOR
From: Dan Williams <[EMAIL PROTECTED]>
async_tx is an api to describe a series of bulk memory
transfers/transforms. When possible these transactions are carried out by
asynchrounous dma engines. The api handles inter-transaction dependencies
and hides dma channel management from the client.
From: Dan Williams <[EMAIL PROTECTED]>
* introduce struct dma_async_tx_descriptor as a common field for all dmaengine
software descriptors
* convert the device_memcpy_* methods into separate prep, set src/dest, and
submit stages
* support capabilities beyond memcpy (xor, memset, xor zero sum,
On Tue, 23 Jan 2007, Balbir Singh wrote:
> When you unmap or map, you need to touch the pte entries and know the
> pages involved, so shouldn't be equivalent to a list_del and list_add
> for each page impacted by the map/unmap operation?
When you unmap and map you must currently get exclusive
Christoph Lameter wrote:
On Tue, 23 Jan 2007, Balbir Singh wrote:
This makes me wonder if it makes sense to split up the LRU into page
cache LRU and mapped pages LRU. I see two benefits
1. Currently based on swappiness, we might walk an entire list
searching for page cache pages or mapped
Jeff Chua <[EMAIL PROTECTED]> wrote:
>
>
> From: Jeff Chua <[EMAIL PROTECTED]>
>
>> CC [M] drivers/kvm/vmx.o
>> {standard input}: Assembler messages:
>> {standard input}:3257: Error: bad register name `%sil'
>> make[2]: *** [drivers/kvm/vmx.o] Error 1
>> make[1]: *** [drivers/kvm] Error 2
>>
Avi Kivity <[EMAIL PROTECTED]> wrote:
> A "g" constraint may place a local variable in an %rsp-relative memory
> operand.
> but if your assembly changes %rsp, the operand points to the wrong location.
>
> An "r" constraint fixes that.
>
> Thanks to Ingo Molnar for neatly bisecting the problem.
On Monday 22 January 2007 20:59, Ingo Molnar wrote:
> * Pavel Pisa <[EMAIL PROTECTED]> wrote:
> > Hello Thomas, Sascha and Ingo
> >
> > please can you find some time to review next patch
> > arm: i.MX/MX1 clock event source
> > which has been sent to you and to the ALKML at 2007-01-13.
> >
> >
Christoph Lameter wrote:
On Mon, 22 Jan 2007, Rik van Riel wrote:
The big one is how we are to do some background aging in a
clock-pro system, so referenced bits don't just pile up when
the VM has enough memory - otherwise we might not know the
right pages to evict when a new process starts up
On Mon, 22 Jan 2007, Rik van Riel wrote:
> The big one is how we are to do some background aging in a
> clock-pro system, so referenced bits don't just pile up when
> the VM has enough memory - otherwise we might not know the
> right pages to evict when a new process starts up and starts
>
On 2007.01.22 19:24:22 -0600, Robert Hancock wrote:
> Björn Steinbrink wrote:
> >>>Running a kernel with the return statement replace by a line that prints
> >>>the irq_stat instead.
> >>>
> >>>Currently I'm seeing lots of 0x10 on ata1 and 0x0 on ata2.
> >>40 minutes stress test now and no
Christoph Lameter wrote:
On Mon, 22 Jan 2007, Rik van Riel wrote:
It would be really nice if we came up with a page replacement
algorithm that did not need many extra heuristics to make it
work...
I guess the "clock" type algorithms are the most promising in that
area. What happened to all
On Tue, Jan 23, 2007 at 07:01:33AM +0530, Balbir Singh wrote:
> This makes me wonder if it makes sense to split up the LRU into page
> cache LRU and mapped pages LRU. I see two benefits
> 1. Currently based on swappiness, we might walk an entire list
>searching for page cache pages or mapped
On Monday January 22, [EMAIL PROTECTED] wrote:
> On 1/22/07, Neil Brown <[EMAIL PROTECTED]> wrote:
> > On Monday January 22, [EMAIL PROTECTED] wrote:
> > > Justin Piszcz wrote:
> > > > My .config is attached, please let me know if any other information is
> > > > needed and please CC (lkml) as I
On Mon, 22 Jan 2007, Rik van Riel wrote:
> It would be really nice if we came up with a page replacement
> algorithm that did not need many extra heuristics to make it
> work...
I guess the "clock" type algorithms are the most promising in that
area. What happened to all those advanced page
Christoph Lameter wrote:
With the proposed schemd you would have to move pages between lists if
they are mapped and unmapped by a process. Terminating a process could
lead to lots of pages moving to the unnmapped list.
That could be a problem.
Another problem is that any such heuristic in
Hi,
what is the preferred way to get at another process's environment
variables? /proc/$$/environ looks like the most portable way [across all
arches Linux runs on], but it cannot easily be mmap'ed because the size
is not known. In fact, mmap does not seem to work at all on that file.
So I
On Jan 23 2007 02:04, Krzysztof Halasa wrote:
>Andreas Schwab <[EMAIL PROTECTED]> writes:
>
>> But other than the sector size there is no natural power of 2 connected to
>> disk size. A disk can have any odd number of sectors.
>
>But the manufacturers don't count in sectors.
>
>It should be
Balbir Singh wrote:
This makes me wonder if it makes sense to split up the LRU into page
cache LRU and mapped pages LRU. I see two benefits
Unlikely. I have seen several workloads fall over because they
did not throw out mapped pages soon enough.
If the kernel does not keep the most
On 1/22/07, Neil Brown <[EMAIL PROTECTED]> wrote:
On Monday January 22, [EMAIL PROTECTED] wrote:
> Justin Piszcz wrote:
> > My .config is attached, please let me know if any other information is
> > needed and please CC (lkml) as I am not on the list, thanks!
> >
> > Running Kernel 2.6.19.2 on a
Alistair John Strachan wrote:
On Tuesday 23 January 2007 01:24, Robert Hancock wrote:
As a final aside, this is another case where the hardware docs for this
controller would really be useful, in order to know whether we are
actually supposed to be reading that register in ADMA mode or not. I
On Tue, 23 Jan 2007, Balbir Singh wrote:
> This makes me wonder if it makes sense to split up the LRU into page
> cache LRU and mapped pages LRU. I see two benefits
>
> 1. Currently based on swappiness, we might walk an entire list
>searching for page cache pages or mapped pages. With these
From: Eric Van Hensbergen <[EMAIL PROTECTED]> - unquoted
We weren't properly NULL terminating protocol error strings for our
debug printk resulting in garbage being included in the output when debug
was enabled.
Signed-off-by: Eric Van Hensbergen <[EMAIL PROTECTED]>
---
fs/9p/error.c |1 +
From: Eric Van Hensbergen <[EMAIL PROTECTED]> - unquoted
Running dbench multithreaded exposed a race condition where fid structures
were removed while in use. This patch adds semaphores to meta-data operations
to protect the fid structure. Some cleanup of error-case handling in the
inode
On Tuesday 23 January 2007 01:24, Robert Hancock wrote:
> As a final aside, this is another case where the hardware docs for this
> controller would really be useful, in order to know whether we are
> actually supposed to be reading that register in ADMA mode or not. I
> sent a query to Allen
Andrea Arcangeli wrote:
On Tue, Jan 23, 2007 at 01:10:46AM +0100, Niki Hammler wrote:
Dear Linux Developers/Enthusiasts,
For a course at my university I'm implementing parts of an operating
system where I get most ideas from the Linux Kernel (which I like very
much). One book I gain
I think your patch is not enough to slove the read_page error
completely. I think in the bitmap_init_from_disk we also need to check
the 'count' never exceeds the size of file before calling the
read_page function. How do your think about it.
Thanks your reply.
2007/1/23, Neil Brown <[EMAIL
On Mon, 22 Jan 2007 18:17:38 +0300, Sergei Shtylyov <[EMAIL PROTECTED]> wrote:
> > + cbiosize=nn[KMG]The fixed amount of bus space which is
> > + reserved for the CardBus bridges IO window.
>
> It shoyld be "bridge's"...
Thanks. Updated again.
Björn Steinbrink wrote:
Running a kernel with the return statement replace by a line that prints
the irq_stat instead.
Currently I'm seeing lots of 0x10 on ata1 and 0x0 on ata2.
40 minutes stress test now and no exception yet. What's interesting is
that ata1 saw exactly one interrupt with
On Mon, Jan 22, 2007 at 01:35:36PM +0100, Michael Noisternig wrote:
> Sure, but what I meant to say was that the user, when creating a
> directory, did not request creation of such sub-directories, so I see
> them as created by the kernel.
Ahh, but userspace did! It's part of the
On 2006-12-21, Robert P. J. Day wrote:
[]
> in any event, even *i* am not going to go near this kind of cleanup,
> but is there anything actually worth doing about it? just curious.
Moscow wasn't built at once...
You may notice as some others are doing little by little steps:
- source
On Tue, 23 Jan 2007 11:37:09 +1100
Donald Douwsma <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> >> On Sun, 21 Jan 2007 14:27:34 -0500 (EST) Justin Piszcz <[EMAIL PROTECTED]>
> >> wrote:
> >> Why does copying an 18GB on a 74GB raptor raid1 cause the kernel to invoke
> >> the OOM killer and
On Mon, Jan 22, 2007 at 09:07:23AM +0100, Stefan Priebe - FH wrote:
> Hi!
>
> The update of the IDE layer was in 2.6.19. I don't think it is a
> hardware bug cause all these 5 machines runs fine since a few years with
> 2.6.16.X and before. We switch to 2.6.18.6 on monday last week and all
>
On Mon, 22 Jan 2007 14:12:02 -0800, David Brownell <[EMAIL PROTECTED]> wrote:
> > Here is a revised version. The children list of spi_master_class
> > contains only spi_master class so we can just compare bus_num member
> > instead of class_id string.
>
> Looks just a bit iffy ... though, thanks
Andreas Schwab <[EMAIL PROTECTED]> writes:
> But other than the sector size there is no natural power of 2 connected to
> disk size. A disk can have any odd number of sectors.
But the manufacturers don't count in sectors.
It should be consistent, though. "How many GB of disk space do you
need
On Mon, 22 Jan 2007 11:28:32 -0800, Junio C Hamano wrote:
> Thanks for your comments;
You're welcome.
> the attached probably needs proofreading.
In general, I like it. The git-branch documentation already talks
about "remote-tracking branches" so I've rewritten a couple of
sentence below to
At Tue, 23 Jan 2007 00:42:31 +0100,
Richard Knutsson wrote:
>
> Michal Piotrowski wrote:
> > How about this script?
> >
> > "d) Ensure that your patch does not add new trailing whitespace. The
> > below
> > script will fix up your patch by stripping off such whitespace.
> >
> > #!/bin/sh
On Tue, Jan 23, 2007 at 01:10:46AM +0100, Niki Hammler wrote:
> Dear Linux Developers/Enthusiasts,
>
> For a course at my university I'm implementing parts of an operating
> system where I get most ideas from the Linux Kernel (which I like very
> much). One book I gain information from is [1].
>
Andrew Morton wrote:
>> On Sun, 21 Jan 2007 14:27:34 -0500 (EST) Justin Piszcz <[EMAIL PROTECTED]>
>> wrote:
>> Why does copying an 18GB on a 74GB raptor raid1 cause the kernel to invoke
>> the OOM killer and kill all of my processes?
>
> What's that? Software raid or hardware raid? If the
When 'repair' finds a block that is different one the various
parts of the mirror. it is meant to write a chosen good version
to the others. However it currently writes out the original data
to each. The memcpy to make all the data the same is missing.
Signed-off-by: Neil Brown <[EMAIL
Now that we sometimes step the array events count backwards
(when transitioning dirty->clean where nothing else interesting
has happened - so that we don't need to write to spares all the time),
it is possible for the event count to return to zero, which is
potentially confusing and triggers and
In most cases we check the size of the bitmap file before
reading data from it. However when reading the superblock,
we always read the first PAGE_SIZE bytes, which might not
always be appropriate. So limit that read to the size of the
file if appropriate.
Also, we get the count of available
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./MAINTAINERS |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff .prev/MAINTAINERS ./MAINTAINERS
--- .prev/MAINTAINERS 2007-01-23 11:14:14.0 +1100
+++ ./MAINTAINERS 2007-01-23 11:23:03.0
Following are 4 patches suitable for inclusion in 2.6.20.
Thanks,
NeilBrown
[PATCH 001 of 4] md: Update email address and status for MD in MAINTAINERS.
[PATCH 002 of 4] md: Make 'repair' actually work for raid1.
[PATCH 003 of 4] md: Make sure the events count in an md array never returns
to
1 - 100 of 667 matches
Mail list logo
