Hi!
I have no experience with kernel debugging, but so far, I have found
no log entry giving me a hint and the screen is blank after the crash
Could you disable console blanking (setterm -blank 0).
We really need a hint where it crashed.
Over the easter weekend I took some time for
1. Kernel crash w/out error message or logfile entry
2. A Fileserver with an ABIT Hotrod 66 (htp366) controller will crash within
5-60 minutes after boot with a 2.4.x kernel. 2.2.x works fine. No other
exotic hardware. Another possibility might be Reiserfs, which I use for all
partitions except
On Mon, 16 April 2007 01:33:17 +0200, Arnd Bergmann wrote:
There is also still some need for performance testing. Jörn
brought up the point that if a specific card can't have multiple
open erase block simulateously, it's rather pointless for
logfs. It might still be useful to use jffs2 on
On Mon, 16 April 2007 17:46:50 +0200, Tomasz Kłoczko wrote:
On Mon, 16 Apr 2007, Christoph Hellwig wrote:
Numbers, please. So far in all interesting benchmarks it actually
was slower. But when they're faster than XFS somewhere I'd defintly
be interesting in looking at why this is true and
On Tue, 24 April 2007 15:21:05 -0700, [EMAIL PROTECTED] wrote:
This patchset modifies the Linux kernel so that larger block sizes than
page size can be supported. Larger block sizes are handled by using
compound pages of an arbitrary order for the page cache instead of
single pages with
On Mon, 12 February 2007 18:49:39 +0100, Jan Engelhardt wrote:
On Feb 12 2007 10:40, Dave Jones wrote:
The one problem with noatime is that mutt's 'new mail arrived' breaks
Just why does not it use mtime then to check for New Mail Arrived, like
bash does?
Just a guess: because it has to
On Mon, 12 February 2007 17:51:30 +0100, Andi Kleen wrote:
From: Andrew Morton [EMAIL PROTECTED]
That stupid non-inlined-static function in bugs.h causes:
include/asm/bugs.h:186: warning: 'check_bugs' defined but not used
But fortunately the include isn't needed.
Cc: Andi Kleen
On Tue, 13 February 2007 11:27:58 +, Alan wrote:
isn't yet a heavily optimised libata path. Secondly erase block size
matters with flash drives so the bigger each I/O the better erase block
behaviour we should get.
Although that should max out somewhere between 16KiB and 128KiB,
On Tue, 13 February 2007 11:29:18 +0100, Martin A. Fink wrote:
Please Read Carefully! I talk about flash disk, not normal harddisks. There
are no mechanical parts in flash disks, only flash memory. And therefore
48MB/s is excellent (compared to all other available disks)
[...]
Well.
On Thu, 15 February 2007 00:40:31 -0800, v j wrote:
Oh, I am sorry. Seems like the German courts have spoken. I am not
sure about what, but they have spoken. Sorry for the confusion.
In short, there seem to be two classes of closed-source drivers:
1. ATI and nVidia. Both are well-known, in
On Thu, 15 February 2007 19:38:14 +0100, Juan Piernas Canovas wrote:
The patch for 2.6.11 is not still stable enough to be released. Be patient
;-)
While I don't want to discourage you, this is about the point in
development where most log structured filesystems stopped. Doing a
little web
On Thu, 15 February 2007 23:59:14 +0100, Juan Piernas Canovas wrote:
Actually, the version of DualFS for Linux 2.4.19 implements a cleaner. In
our case, the cleaner is not really a problem because there is not too
much to clean (the meta-data device only contains meta-data blocks which
On Fri, 16 February 2007 18:47:48 -0500, Bill Davidsen wrote:
Actually I am interested in the common case, where the machine is not
out of space, or memory, or CPU, but when it is appropriately sized to
the workload. Not that I lack interest in corner cases, but the running
flat out case
On Sat, 17 February 2007 13:10:23 -0500, Bill Davidsen wrote:
I missed that. Which corner case did you find triggers this in DualFS?
This is not specific to DualFS, it applies to any log-structured
filesystem.
Garbage collection always needs at least one spare segment to collect
valid data
On Sat, 17 February 2007 15:47:01 -0500, Sorin Faibish wrote:
DualFS can probably get around this corner case as it is up to the user
to select the size of the MD device size. If you want to prevent this
corner case you can always use a device bigger than 10% of the data device
which is
Maybe this is a decent approach to deal with the problem. First some
definitions. T is the target segment to be cleaned, S is the spare
segment that valid data is written to, O are other segments that contain
indirect blocks I for valid data D in T.
Have two different GC mechanisms to choose
On Tue, 20 February 2007 00:57:50 +0100, Juan Piernas Canovas wrote:
I understand the problem that you describe with respect to the GC, but
let me explain why I think that it has a small impact on DualFS.
Actually, the GC may become a problem when the number of free segments is
50% or
On Mon, 19 March 2007 14:10:38 -0700, Andrew Morton wrote:
Would prefer to do:
static inline void kmem_cache_free_if_not_null(struct kmem_cache *cachep,
void *objp)
{
if (objp)
kmem_cache_free(cachep, objp);
}
so that
On Tue, 20 March 2007 01:42:46 +0100, Thomas Gleixner wrote:
On Mon, 2007-03-19 at 17:32 -0500, Matt Mackall wrote:
4. JFFS2 has its own wear-leving scheme, as do several other
filesystems, so they probably want to bypass this piece of the stack.
JFFS2 on top of UBI delegates
On Wed, 21 March 2007 12:25:34 +0100, Thomas Gleixner wrote:
On Wed, 2007-03-21 at 12:05 +0100, Jörn Engel wrote:
Ok, now we have reached the absurd. UBI quite fundamentally cannot do
wear leveling as good as LogFS can. Simply because UBI has zero
knowledge of the _contents_ of its
On Wed, 21 March 2007 12:57:42 +0100, Thomas Gleixner wrote:
On Wed, 2007-03-21 at 12:35 +0100, Jörn Engel wrote:
Even if such flashes still contain a bootloader and a kernel, that will
occupy less than 1% of the device. Wear leveling across the device is
fairly pointless here
*sigh*
I really did not want to become involved in this. So please be nice and
leave the flamethrower in your weapon closet or I will disappear again
before you can say fire.
On Tue, 20 March 2007 21:32:40 +, David Woodhouse wrote:
On Tue, 2007-03-20 at 10:58 -0800, David Lang wrote:
On Wed, 21 March 2007 08:30:27 -0800, Andrew Morton wrote:
On Wed, 21 Mar 2007 16:41:19 +0200 Pekka Enberg [EMAIL PROTECTED] wrote:
Yeah, I'll try to sneak a patch past Andrew.
That would be sneaky.
Thing is, such a patch would amount to adding a test-for-NULL to codepaths
which we
On Wed, 21 March 2007 12:25:34 +0100, Thomas Gleixner wrote:
On Wed, 2007-03-21 at 12:05 +0100, Jörn Engel wrote:
Also LogFS currently requires erasesizes of 2^n.
Last time I talked to you about that, you said it would be possible and
fixable.
Actually, no. LogFS is not broken
On Sun, 25 March 2007 16:58:05 +0200, Adrian Bunk wrote:
block2mtd_paramline[] is used in the non-__init block2mtd_setup()
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-By: Jörn Engel [EMAIL PROTECTED]
Adrian, can you put me on Cc: next time?
---
--- linux-2.6.21-rc4-mm1/drivers/mtd
On Sun, 25 March 2007 13:49:58 -0800, David Lang wrote:
On Sun, 25 Mar 2007, Jörn Engel wrote:
Logical volume management can just as easily move its management
information into a table, instead of having it spread across all blocks.
Blocks can keep their original size. Since you have
On Mon, 26 March 2007 00:46:33 +0100, David Woodhouse wrote:
On Mon, 2007-03-26 at 00:55 +0200, Jörn Engel wrote:
although, since you can flip bits to 1 without requireing an erase you
[ vice versa. you can flip bits to 0 without erasing. ]
And on NAND flash you can't just do
On Mon, 26 March 2007 01:21:25 +0100, David Woodhouse wrote:
On Mon, 2007-03-26 at 02:01 +0200, Jörn Engel wrote:
You can on NAND. ECC is done in software. And for a data structure as
simple as the 'tally', foregoing ECC is not a huge problem - most
bitflips are easily detected
On Mon, 26 March 2007 10:45:57 +0100, David Woodhouse wrote:
No, on NAND flash it's a limitation of the hardware. The number of write
cycles you can perform to a given page is limited. Exceed it and the
contents of that page become undefined due to leakage, until you next
erase it.
Are you
On Mon, 26 March 2007 13:49:06 +0300, Artem Bityutskiy wrote:
On Sun, 2007-03-25 at 22:08 +0200, Jörn Engel wrote:
Logical volume management can just as easily move its management
information into a table, instead of having it spread across all blocks.
Blocks can keep their original size
On Sun, 8 April 2007 11:11:20 -0700, H. Peter Anvin wrote:
Well, the question is if you can keep the seekdir/telldir cookie around
as a pointer -- preferrably in userspace, of course. You would
presumably garbage-collect them on closedir() -- there is no other point
at which you could.
On Sun, 8 April 2007 21:44:26 -0400, Theodore Tso wrote:
Well, Joern thought that rm -rf might relying on the telldir cookie
being valid in precisely that circumstance. If that is true, I'd
argue that this is a BUG in GNU coreutils that should be fixed...
I heard it and accepted that claim
On Mon, 9 April 2007 23:01:42 +1000, Paul Mackerras wrote:
Jörn Engel writes:
Wouldn't that work be confined to fallocate()? If I understand Heiko
correctly, the alternative would slow s390 down for every syscall,
including more performance-critical ones.
The alternative that Jakub
On Mon, 9 April 2007 12:21:15 -0500, Eric Sandeen wrote:
Phillip Susi wrote:
When the filesystem is told to mount the disk read only, that means it
should not write to it.
It means the filesystem should not be writeable when it is mounted.
This is not the same as saying that the
On Tue, 10 April 2007 07:27:18 -0400, Theodore Tso wrote:
I suppose what you could do is to read in the journal, and use it to
create an remapping table so that when you want to read block #5126,
and block number 5126 is in the journal, to read the journal version
of the block instead of the
On Tue, 10 April 2007 22:56:38 -0700, Andrew Morton wrote:
And I'm surprised that this:
+static inline void memclear_highpage_flush(struct page *page, unsigned int
offset, unsigned int size)
+{
+ return zero_user_page(page, offset, size);
+}
compiled. zero_user_page() returns
On Wed, 11 April 2007 16:23:21 -0700, H. Peter Anvin wrote:
David Lang wrote:
On Thu, 12 Apr 2007, Neil Brown wrote:
For the second.
You say that you would need at least 96 bits in order to make that
guarantee; 64 bits of hash, plus a 32-bit count value in the hash
collision chain. I
On Thu, 12 April 2007 11:46:41 +1000, Neil Brown wrote:
I could argue that nfs came before ext3+dirindex, so ext3 should have
been designed to work properly with NFS. You could argue that fixing
it in nfsd fixes it for all filesystems. But I'm not sure either of
those arguments are likely
On Thu, 12 April 2007 15:57:41 +1000, Neil Brown wrote:
However, the collision chain gives me quite a bit of headache. One
would have to store each entry's position on the chain, deal with older
entries getting deleted, newer entries getting removed, etc. All this
requires a lot of
On Wed, 21 February 2007 05:36:22 +0100, Juan Piernas Canovas wrote:
I don't see how you can guarantee 50% free segments. Can you explain
that bit?
It is quite simple. If 50% of your segments are busy, and the other 50%
are free, and the file system needs a new segment, the cleaner starts
On Tue, 20 February 2007 17:46:13 -0800, Vijay Sampath wrote:
The files cfi_cmdset_0002.c and cfi_cmdset_0020.c do not initialize
their wait queues like is done in cfi_cmdset_0001.c. This causes an
oops when the wait queue is accessed. I have copied the code from
cfi_cmdset_0001.c that is
On Wed, 21 February 2007 19:31:40 +0100, Juan Piernas Canovas wrote:
I do not understand. Do you mean that if I have 10 segments, 5 busy and 5
free, after cleaning I could need 6 segments? How? Where the extra blocks
come from?
This is a fairly complicated subject and I have trouble
On Thu, 22 February 2007 05:30:03 +0100, Juan Piernas Canovas wrote:
DualFS writes meta-blocks in variable-sized chunks that we call partial
segments. The meta-data device, however, is divided into segments, which
have the same size. A partial segment can be as large a a segment, but a
On Thu, 22 February 2007 20:57:12 +0100, Juan Piernas Canovas wrote:
I do not agree with this picture, because it does not show that all the
indirect blocks which point to a direct block are along with it in the
same segment. That figure should look like:
Segment 1: [some data] [ DA D1'
On Sat, 24 February 2007 09:32:49 -0800, Christoph Lameter wrote:
If that is a problem for particular object pools then we may be able to
except those from the merging.
How much of a gain is the merging anyway? Once you start having
explicit whitelists or blacklists of pools that can be
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
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 slightly
On Sun, 4 March 2007 14:38:13 -0800, Ulrich Drepper wrote:
When you do it like this, who can the kernel/filesystem *guarantee* that
when the data is written there actually is room on the harddrive?
What you described seems like using truncate/ftruncate to increase the
file's size. That is
On Mon, 5 March 2007 01:36:36 +0100, Arnd Bergmann wrote:
Using the current glibc implementation on a compressed file system ideally
should be a very expensive no-op because you won't actually allocate much
space for a file when writing zeroes to it. You also don't benefit of a
contiguous
On Mon, 5 March 2007 00:32:14 +, Anton Altaparmakov wrote:
I don't know how your compression algorithm works [...]
LogFS is designed for flash media, so it does not have to worry much
about reducing disk seeks. It is log-structured, which simplifies
compression further.
When writing a
On Mon, 5 March 2007 07:08:03 -0800, Ulrich Drepper wrote:
Jörn Engel wrote:
Does the allocation have to be persistent beyond lifetime of the file
descriptor?
Of course. You call posix_fallocate once for the lifetime of the file
when it is created to ensure that all future uses will work
On Wed, 7 March 2007 09:51:35 +0100, Jan Kara wrote:
I'll probably first write some userspace fs-reorganizer to find out how
much these changes in layout are able to give you in performance (i.e.
whether it's worth the effort of more complicated kernel online
defragmenter).
Have tried
On Tue, 27 March 2007 21:24:20 +, Pavel Machek wrote:
From: Miklos Szeredi [EMAIL PROTECTED]
This patch adds support for finding out the current file position,
open flags and possibly other info in the future.
These new entries are added:
/proc/PID/fdinfo/FD
On Fri, 30 March 2007 19:15:58 +1000, Paul Mackerras wrote:
Heiko Carstens writes:
If possible I'd prefer the six-32-bit-args approach.
It does mean extra unnecessary work for 64-bit platforms, though...
Wouldn't that work be confined to fallocate()? If I understand Heiko
correctly, the
On Sun, 1 April 2007 20:15:42 +0200, Jan Engelhardt wrote:
+static inline void putstr(const char *s) {
+printk(%s, s);
+return;
+}
+
static int __init crd_load(int in_fd, int out_fd)
{
int result;
@@ -418,7 +423,7 @@ static int __init crd_load(int in_fd, in
On Tue, 3 April 2007 23:10:14 +0200, Eric Dumazet wrote:
mmap()/brk() must give fresh NULL pages, but maybe madvise(MADV_DONTNEED)
can relax this requirement (if the pages were reclaimed, then a page fault
could bring a new page with random content)
...provided that it doesn't leak
On Mon, 7 January 2008 11:05:26 +0100, Peter Zijlstra wrote:
Would something like this work for people?
Looks a lot better than what I thought of. However, does the #ifdef
within is_module_address() make sense when afaict lockdep is the only
caller of that function? Looks as if the whole
On Mon, 7 January 2008 13:25:09 +0100, Frantisek Rysanek wrote:
let me start with a simple example. The following commands:
cp /dev/zero /dev/hda
dd if=/dev/zero of=/dev/hda [bs=512]
both have one common side-effect: apart from the disk being properly
overwritten with zeroes, the
On Mon, 7 January 2008 15:23:00 -0800, Andrew Morton wrote:
On Sun, 6 Jan 2008 14:56:01 +0100
J__rn Engel [EMAIL PROTECTED] wrote:
You found a new one! That make a round dozen, I believe.
http://logfs.org/logfs/joern
- * Copyright (C) 2004-2006 Jörn Engel [EMAIL PROTECTED]
+ * Copyright
On Thu, 10 January 2008 11:49:25 -0600, Matt Mackall wrote:
b) grouping objects of the same -type- (not size) together should mean
they have similar lifetimes and thereby keep fragmentation low
(b) is known to be false, you just have to look at our dcache and icache
pinning.
(b) is
On Sun, 16 September 2007 00:30:32 +0200, Andrea Arcangeli wrote:
Movable? I rather assume all slab allocations aren't movable. Then
slab defrag can try to tackle on users like dcache and inodes. Keep in
mind that with the exception of updatedb, those inodes/dentries will
be pinned and you
On Sat, 15 September 2007 01:44:49 -0700, Andrew Morton wrote:
On Tue, 11 Sep 2007 14:12:26 +0200 Jörn Engel [EMAIL PROTECTED] wrote:
While I agree with your concern, those numbers are quite silly. The
chances of 99.8% of pages being free and the remaining 0.2% being
perfectly spread
On Sun, 16 September 2007 11:15:36 -0700, Linus Torvalds wrote:
On Sun, 16 Sep 2007, Jörn Engel wrote:
I have been toying with the idea of having seperate caches for pinned
and movable dentries. Downside of such a patch would be the number of
memcpy() operations when moving dentries
On Mon, 17 September 2007 00:06:24 +0200, Goswin von Brederlow wrote:
How probable is it that the dentry is needed again? If you copy it and
it is not needed then you wasted time. If you throw it out and it is
needed then you wasted time too. Depending on the probability one of
the two is
On Tue, 18 September 2007 11:00:40 +0100, Mel Gorman wrote:
We still lack data on what sort of workloads really benefit from large
blocks
Compressing filesystems like jffs2 and logfs gain better compression
ratio with larger blocks. Going from 4KiB to 64KiB gave somewhere
around 10% benefit
On Mon, 12 November 2007 20:41:10 -0800, Christoph Lameter wrote:
On Mon, 12 Nov 2007, Ray Lee wrote:
Discontig obviously needs to die. However, FlatMem is consistently
faster, averaging about 2.1% better overall for your numbers above. Is
the page allocator not, erm, a fast path, where
On Tue, 13 November 2007 15:18:07 -0500, Mark Lord wrote:
I just find it weird that something can be known broken for several -rc*
kernels before I happen to install it, discover it's broken on my own
machine,
and then I track it down, fix it, and submit the patch, generally all
within a
On Tue, 13 November 2007 13:56:58 -0800, Andrew Morton wrote:
It's relatively common that a regression in subsystem A will manifest as a
failure in subsystem B, and the report initially lands on the desk of the
subsystem B developers.
But that's OK. The subsystem B people are the ones
On Tue, 13 November 2007 13:52:17 -0800, Christoph Lameter wrote:
Could you run your own test to verify?
You bastard! You know I'm too lazy to do that. ;)
As long as the order-0 number is stable across multiple runs I don't
mind. The numbers just looked suspiciously as if they were not
On Thu, 15 November 2007 13:26:51 +0100, Rene Herman wrote:
Can you please just shelve this crap? You have a way of knowing that ALSA
will accept you and that is knowing or assuming that the ALSA project
doesn't consist of drooling retards.
Well, my experience with moderation has been that
After some archeology (see http://logfs.org/logfs/inode_state_bits) I
finally figured out what the three I_DIRTY bits do. Maybe others would
prefer less effort to reach this insight.
Signed-off-by: Jörn Engel [EMAIL PROTECTED]
---
include/linux/fs.h |8
1 file changed, 4
On Fri, 16 November 2007 10:30:12 -0800, H. Peter Anvin wrote:
This, by the way, has been discussed on and off -- often in the context
of undelete (which is an identical problem.) The problem usually is
that performance of real storage users suffer because of locality
issues. However,
On Fri, 23 November 2007 00:15:53 +, Daniel Drake wrote:
What's the definition of an unaligned access?
=
Unaligned memory accesses occur when you try to read N bytes of data starting
from an address that is not evenly divisible by N (i.e.
On Fri, 30 November 2007 14:43:12 +0100, Ingo Molnar wrote:
http://redhat.com/~mingo/latency-tracing-patches/latency-tracing-v2.6.24-rc3.combo.patch
does it work any better?
It compiles. It boots with a 512M RAM (384M was too little with all
the other debug options on). But it seems
On Thu, 15 November 2007 20:36:12 +0100, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
pick up the latest latency tracer patch from:
sorry, wrong URLs, the correct links are:
http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.24-rc2-git5-combo.patch
On Fri, 30 November 2007 14:35:46 +0100, Ingo Molnar wrote:
* Jörn Engel [EMAIL PROTECTED] wrote:
kernel/sched.c:3384: warning: ‘struct prio_array’ declared inside parameter
list
kernel/sched.c:3384: warning: its scope is only this definition or
declaration, which is probably
On Fri, 30 November 2007 19:46:25 +0100, Ingo Molnar wrote:
* Jörn Engel [EMAIL PROTECTED] wrote:
It compiles. It boots with a 512M RAM (384M was too little with all
the other debug options on). But it seems to lock up when running
trace-cmd. On a rerun it locks up again
On Sat, 1 December 2007 19:32:56 +0100, Ingo Molnar wrote:
* Jörn Engel [EMAIL PROTECTED] wrote:
I have to change my qemu setup a little to see the top of those
dumps...
btw., if you start qemu like this:
qemu -cdrom ./cdrom.iso -hda ./hda.img -boot c -full-screen -kernel
~/bzImage
On Sat, 1 December 2007 21:54:56 +0100, Ingo Molnar wrote:
* J??rn Engel [EMAIL PROTECTED] wrote:
stopped custom tracer.
BUG: spinlock recursion on CPU#0, sh/953
lock: c030f280, .magic: dead4ead, .owner: sh/953, .owner_cpu: 0
Pid: 953, comm: sh Not tainted 2.6.24-rc3-ge1cca7e8-dirty
On Sun, 2 December 2007 09:56:08 +0100, Ingo Molnar wrote:
* Jörn Engel [EMAIL PROTECTED] wrote:
ah. You should mark pit_read() function as notrace. PIT clocksource
is rare. (add the 'notrace' word to the function prototype)
Hardly a change at all. Apart from some offsets
On Sun, 2 December 2007 12:31:43 +0100, Jörn Engel wrote:
This time not even the offsets have changed. Dump is identical.
After another ten or so notrace annotations throughout the spinlock
code, the latency tracer appears to work. Not sure how many useful
information is missing through all
On Sun, 2 December 2007 14:57:11 +0100, Ingo Molnar wrote:
hm, do you have CONFIG_FRAME_POINTERS=y, i.e. are the dumps reliable?
I do. Went through 10odd runs and annotated the function right below
mcount each time. Seems to work now.
Trouble is that it doesn't solve my real problem at
On Sun, 2 December 2007 13:31:25 +0100, Jörn Engel wrote:
After another ten or so notrace annotations throughout the spinlock
code, the latency tracer appears to work. Not sure how many useful
information is missing through all the annotations, though.
And here is a patch with the needed
On Sun, 2 December 2007 16:47:46 +0100, Ingo Molnar wrote:
well what does the trace say, where do the delays come from? To get a
quick overview you can make tracing lighter weight by doing:
echo 0 /proc/sys/kernel/mcount_enabled
echo 1 /proc/sys/kernel/trace_syscalls
I mistyped and
On Sat, 1 December 2007 21:59:31 +0200, Avi Kivity wrote:
Object orientation in C leaves much to be desired; see the huge number
of void pointers and container_of()s in the kernel.
While true, this isn't such a bad problem. A language really sucks when
it tries to disallow something useful.
On Sun, 2 December 2007 21:07:22 +0100, Ingo Molnar wrote:
* Jörn Engel [EMAIL PROTECTED] wrote:
Result looked like a livelock and finally convinced me to abandon the
latency tracer. Sorry, but it appears to be the right tool for the
wrong job.
hm, we routinely use it in -rt
On Sun, 2 December 2007 21:45:59 +0100, Ingo Molnar wrote:
to capture a 1 second trace of what the system is doing. I think your
troubles are due to running it within a qemu guest - that is not a
typical utilization so you are on unchartered waters.
Looks like it. Guess I'll switch to
On Sun, 2 December 2007 21:45:59 +0100, Ingo Molnar wrote:
to capture that trace i did not use -rt, i just patched latest -git
with:
http://people.redhat.com/mingo/latency-tracing-patches/latency-tracing-v2.6.24-rc3.combo.patch
(this has your fixes included already)
have done:
On Sun, 2 December 2007 22:19:00 +0100, Ingo Molnar wrote:
* Jörn Engel [EMAIL PROTECTED] wrote:
Maybe one more thing: can you send me the config you used for the
setup above? I'd like to know whether qemu or my config is to blame.
sure - attached.
After an eternity of compile time
On Mon, 3 December 2007 01:57:02 +0100, Jörn Engel wrote:
After an eternity of compile time, this config does generate some useful
output. qemu is not to blame.
Or is it? The output definitely looks suspicious. Large amounts of
code get processed within a microsecond, while
On Tue, 4 December 2007 13:54:21 -0800, Jared Hulbert wrote:
Maybe I'm missing something but I don't see it. We want a block
interface for these devices, we just need a faster slimmer interface.
Maybe a new mtdblock interface that doesn't do erase would be the
place for?
Doesn't do erase?
On Thu, 3 January 2008 14:19:25 +0300, Cyrill Gorcunov wrote:
@@ -232,7 +232,8 @@ void audit_log_lost(const char *message)
if (print) {
printk(KERN_WARNING
-audit: audit_lost=%d audit_rate_limit=%d
audit_backlog_limit=%d\n,
+
to
cause trouble until the end of this century.
Signed-off-by: Jörn Engel [EMAIL PROTECTED]
---
MAINTAINERS | 10 --
drivers/mtd/devices/block2mtd.c |4 ++--
drivers/mtd/devices/phram.c |4 ++--
drivers/mtd/maps/mtx-1_flash.c |2 +-
scripts/checkstack.pl
On Sun, 6 January 2008 14:11:47 -0500, Erez Zadok wrote:
The problem appears to be an interaction of two components--module loading
and lockdep--that's perhaps why it wasn't given enough attention.
Correct. For modules lockdep depends on initializations done after
module_init has finished.
David, will you take this patch?
Signed-off-by: Dave Jones [EMAIL PROTECTED]
Signed-off-by: Joern Engel [EMAIL PROTECTED]
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 8f9c3ba..246d451 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -300,7 +300,7
On Fri, 19 October 2007 13:53:40 -0400, Erez Zadok wrote:
I've been having this problem for some time with mtd, which I use to mount
jffs2 images (for unionfs testing). I've seen it in several recent major
kernels, including 2.6.24. Here's the sequence of ops I perform:
Since when roughly?
On Fri, 19 October 2007 19:26:35 +0200, Samuel Tardieu wrote:
---
drivers/mtd/devices/doc2000.c |4 ++--
drivers/mtd/devices/doc2001plus.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
Acked-by: Joern Engel [EMAIL PROTECTED]
I assume you don't actually use this
On Fri, 19 October 2007 16:04:10 -0400, Erez Zadok wrote:
In message [EMAIL PROTECTED], =?utf-8?B?SsO2cm4=?= Engel writes:
Since when roughly? 2.6.20ish? Before?
Yeah, I guess around that time. If you want, I could go back and test each
of my backports and see if it has the lockdep
On Fri, 19 October 2007 20:31:29 +0200, Peter Zijlstra wrote:
BUG: key f88e1340 not in .data!
WARNING: at kernel/lockdep.c:2331 lockdep_init_map()
[c0102bc2] show_trace_log_lvl+0x1a/0x2f
[c0103692] show_trace+0x12/0x14
[c01037b2] dump_stack+0x15/0x17
[c0125432]
On Tue, 12 February 2008 13:47:51 +, Stephane Chazelas wrote:
this patch addresses a number of small issues mainly regarding
the output made by this driver to dmesg:
- Some of the blkmtd's had not been changed to block2mtd
which caused display problem
- the parse_err() macro was
1 - 100 of 1168 matches
Mail list logo
