On 12/28/06, Russell King [EMAIL PROTECTED] wrote:
Fixing Linus' test program to pass nr 255 to memset results in clean
passes on 2.6.9 on TheCus N2100 (IOP8032x) and 2.6.16.9 StrongARM
machines (as would be expected.)
Thanks for the fix, Russell.
I can now trigger the (real) problem by
On 12/28/06, Dor Laor [EMAIL PROTECTED] wrote:
Are you sure the kvm_intel kvm modules are loaded?
Yes.
Maybe you're bios does not support virtualization.
Configured in the bios on Dell 745.
Please check your dmesg.
I'll double-check dmesg when I get to the office tomorrow. But I'm
Jeff Chua wrote:
It's a dynamic misc device, you don't need to create it.
But it'll be nice to be able to manually create the device as I
normally mount / as read-only?
udev is the best solution here. It works with read-only root as it
mounts tmpfs on /dev.
--
error compiling
* Russell King [EMAIL PROTECTED] [2006-12-28 10:49]:
By the way, I just tried it with TARGETSIZE (100 12) on a different
ARM machine (a Thecus N2100 based on an IOP32x chip with 128 MB of
memory) and I see similar results to that from Gordon:
Work around the glibc memset() problem by
Hi all,
I am writing a kernel module that creates a kernel thread on a SMP
platform.
How to get the ID of the processor the kernel thread run on? Have any
kernel API? THX
Raymond
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
I set a qemu environment to test kernels: http://guichaz.free.fr/linux-bug/
I have corruption with every Fedora release kernel except the first, that is
2.4.22 works, but 2.6.5, 2.6.9, 2.6.11, 2.6.15 and 2.6.18-1.2798 exhibit
some
corruption.
Command line to test:
qemu root_fs -snapshot
I am writing a kernel module that creates a kernel thread on a SMP
platform.
How to get the ID of the processor the kernel thread run on? Have any
kernel API? THX
Raymond
try smp_processor_id() it returns an unsigned int.
Thanks,
jerry
-
To unsubscribe from this list: send the line
On Thu, Dec 28, 2006 at 02:42:37AM -0800, Andrew Morton wrote:
...
Changes since 2.6.20-rc1-mm1:
...
git-dvb.patch
...
git trees
...
This patch fixes the following compile error:
-- snip --
...
LD drivers/media/video/built-in.o
On 12/28/06, Avi Kivity [EMAIL PROTECTED] wrote:
udev is the best solution here. It works with read-only root as it
mounts tmpfs on /dev.
Thanks for the suggestion and I'll look into it. As for now, my system
works well without udev, and I just wanted to test kvm without the
dynamic /dev/kvm
Jeff Chua wrote:
On 12/28/06, Avi Kivity [EMAIL PROTECTED] wrote:
udev is the best solution here. It works with read-only root as it
mounts tmpfs on /dev.
Thanks for the suggestion and I'll look into it. As for now, my system
works well without udev, and I just wanted to test kvm without
* Gordon Farquharson [EMAIL PROTECTED] [2006-12-28 07:15]:
Thanks for the fix, Russell.
I can now trigger the (real) problem by using a 25 MB file (100 18)
and the Linksys NSLU2 (ARM, IXP420 processor, 32 MB RAM).
Me too (using 100 18). Interestingly, I don't seem to get any
corruption on
[sorry for delay with answer]
On Wed, Dec 20, 2006 at 09:35:55PM -0800, Andrew Morton wrote:
I know nothing of UFS, but here goes..
Looks like this is the problem, which point Al Viro some time ago:
when we allocate block(in this situation 16K) we mark as new
only one fragment(in this
On Thu, 2006-12-28 at 13:31 +, Alan wrote:
Seems to me anyone really desperate to put PCI devices into a low
power mode, without driver support at the ifdown level, would be
able just rmmod driver; setpci.
Incorrect for very obvious reasons - there may be two devices driven by
the
On Thu Dec 28 15:09 , Guillaume Chazarain sent:
I set a qemu environment to test kernels: http://guichaz.free.fr/linux-bug/
I have corruption with every Fedora release kernel except the first, that is
2.4.22 works, but 2.6.5, 2.6.9, 2.6.11, 2.6.15 and 2.6.18-1.2798 exhibit
some corruption.
On Wed, 2006-12-27 at 13:54 -0600, Loye Young wrote:
I, a humble pilgrim in the Land of Tux, have spent over a year seeking
a simple answer to what seems to me a simple question: How do I expose
my RS232 barcode scanner to the input layer so that the scanned
information shows up in
On 22-12-2006 15:28, Eric Sesterhenn wrote:
hi,
while running my usual stuff on 2.6.20-rc1-git5, sfuzz
(http://www.digitaldwarf.be/products/sfuzz.c)
did the following, to produce the lockdep warning below:
...
Here is the stacktrace:
[ 313.239556]
Pluse possible naming updates discussed in the last mail. Also do we
really need to pass current-io_wait here? Isn't the waitqueue in
the kiocb always guaranteed to be the same? Now that all pagecache
I/O goes through the -aio_read/-aio_write routines I'd prefer to
get rid of the
On Thu, Dec 28, 2006 at 11:55:10AM +, Christoph Hellwig wrote:
On Thu, Dec 28, 2006 at 02:11:49PM +0530, Suparna Bhattacharya wrote:
-extern void FASTCALL(lock_page_slow(struct page *page));
+extern int FASTCALL(__lock_page_slow(struct page *page, wait_queue_t
*wait));
extern void
Jeff Layton wrote:
Benny Halevy wrote:
It seems like the posix idea of unique st_dev, st_ino doesn't
hold water for modern file systems and that creates real problems for
backup apps which rely on that to detect hard links.
Why not? Granted, many of the filesystems in the Linux kernel
On Thu, Dec 28, 2006 at 11:57:47AM +, Christoph Hellwig wrote:
+ if (in_aio()) {
+ /* Avoid repeat readahead */
+ if (kiocbTryRestart(io_wait_to_kiocb(current-io_wait)))
+ next_index = last_index;
+ }
Every place we use kiocbTryRestart in
Arjan van de Ven wrote:
It seems like the posix idea of unique st_dev, st_ino doesn't
hold water for modern file systems
are you really sure?
Well Jan's example was of Coda that uses 128-bit internal file ids.
and if so, why don't we fix *THAT* instead
Hmm, sometimes you can't fix the
Benny Halevy wrote:
Jeff Layton wrote:
Benny Halevy wrote:
It seems like the posix idea of unique st_dev, st_ino doesn't
hold water for modern file systems and that creates real problems for
backup apps which rely on that to detect hard links.
Why not? Granted, many of the filesystems in the
* Evgeniy Polyakov [EMAIL PROTECTED] wrote:
Generic event handling mechanism.
it would be /very/ helpful to state against which kernel tree the
patch-queue is. It does not apply to 2.6.20-rc1 nor to -rc2 nor to
2.6.19. At which point i gave up ...
Ingo
-
To unsubscribe from this
* Evgeniy Polyakov [EMAIL PROTECTED] wrote:
Generic event handling mechanism.
i see it covers alot of event sources, but i cannot see block IO
notifications. Am i missing something?
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On Dec 28 2006 11:57, Christoph Hellwig wrote:
+
+if ((error = __lock_page(page, current-io_wait))) {
+goto readpage_error;
+}
This should be
error = __lock_page(page, current-io_wait);
if (error)
On Dec 28 2006 10:54, Jeff Layton wrote:
Sorry, I should qualify that statement. A lot of filesystems don't have
permanent i_ino values (mostly pseudo filesystems -- pipefs, sockfs, /proc
stuff, etc). For those, the idea is to try to make sure we use 32 bit values
for them and to ensure that
Hi,
while writing a netfilter match module I found that, when run,
skb-h.th is not set to the TCP header (it is assured that the packet
_is_ TCP), as this printk shows me:
skb: h.th=cb5bc4dc nh.iph=cb5bc4dc mac.raw=cb5bc4ce head=cb5bc400
data=cb5bc4dc tail=cb5bc510 end=cb5bc580
Is it
On Wed, 27 Dec 2006, Gordon Farquharson wrote:
100kB and 200kB files always succeed on the ARM system. 400kB and
larger always seem to fail.
Oh, wow. Yeah, I've just repressed how tiny 32MB is. And especially if you
lowered the /proc/sys/vm/dirty_ratio to a smaller percentage, I guess
On Wed, 27 Dec 2006, Chen, Kenneth W wrote:
Running the test code, git bisect points its finger at this commit.
Reverting
this commit on top of 2.6.20-rc2 doesn't trigger the bug from the test code.
[PATCH] mm: balance dirty pages
Now that we can detect writers of
Jiri Slaby [EMAIL PROTECTED] writes:
Jiri Slaby [EMAIL PROTECTED] writes:
Could you test the patch below, if something changes?
Just tested with low_latency commented out. Still oopses:
BUG: unable to handle kernel NULL pointer dereference at virtual address
0008
printing eip:
On Thu, 28 Dec 2006, Zhang, Yanmin wrote:
The test program is a process to write/read data. pdflush might write data
to disk asynchronously. After pdflush writes a page to disk, it will call
(either by
softirq) clear_page_dirty to clear the dirty bit after getting the interrupt
Hi,
The following patch adds a config option to get rid of the DMA zone on i386.
Architectures with devices that have no addressing limitations (eg. PPC)
already work this way.
This is useful for custom kernel builds where the developer is certain that
there are no address limitations.
For
On Thu, 28 Dec 2006, Russell King wrote:
and if you look at glibc's memset() function, you'll notice that's exactly
what you expect if you pass a non-8bit value to it. Ergo, what you're
seeing is utterly expected given glibc's memset() implementation on ARM.
Guys, you _really_ should fix
On Thu, Dec 28, 2006 at 03:03:02PM -0200, Marcelo Tosatti wrote:
The following patch adds a config option to get rid of the DMA zone on i386.
Architectures with devices that have no addressing limitations (eg. PPC)
already work this way.
This is useful for custom kernel builds where the
On Thu, 2006-12-28 at 15:03 -0200, Marcelo Tosatti wrote:
Hi,
The following patch adds a config option to get rid of the DMA zone on i386.
Architectures with devices that have no addressing limitations (eg. PPC)
already work this way.
This is useful for custom kernel builds where the
On Tue, Dec 19, 2006 at 09:51:49AM +0100, Marc Haber wrote:
On Sun, Dec 17, 2006 at 09:43:08PM -0800, Andrew Morton wrote:
Six hours here of fsx-linux plus high memory pressure on SMP on 1k
blocksize ext3, mainline. Zero failures. It's unlikely that this testing
would pass, yet people
Jan Engelhardt wrote:
while writing a netfilter match module I found that, when run,
skb-h.th is not set to the TCP header (it is assured that the packet
_is_ TCP), as this printk shows me:
skb: h.th=cb5bc4dc nh.iph=cb5bc4dc mac.raw=cb5bc4ce head=cb5bc400
data=cb5bc4dc tail=cb5bc510
From: Thomas Hisch [EMAIL PROTECTED]
Signed-off-by: Thomas Hisch [EMAIL PROTECTED]
Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED]
---
Documentation/filesystems/fuse.txt |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/Documentation/filesystems/fuse.txt
+++
Arjan van de Ven wrote:
Hi,
since one gets random corruption if a user gets this wrong, at least
make things like floppy and all CONFIG_ISA stuff conflict with this
option without that your patch feels like a walking time bomb...
(and please include all PCI drivers that only can do 24 bit
On Thu, 2006-12-28 at 12:34 -0600, Robert Hancock wrote:
Hi,
since one gets random corruption if a user gets this wrong, at least
make things like floppy and all CONFIG_ISA stuff conflict with this
option without that your patch feels like a walking time bomb...
(and please include
On Dec 28 2006 15:03, Marcelo Tosatti wrote:
Comments?
+config NO_DMA_ZONE
^^
+ bool DMA zone support
^^^
+ default n
^
+ help
+ This disables support for the 16MiB DMA zone. Only enable this
+ option if you are certain that
Hello all!
I sent a patch with this content:
- for (i = 0; i MAX_PIRQS; i++)
- pirq_entries[i] = -1;
+ memset(pirq_entries, -1, sizeof(pirq_entries));
I'd like to know if you have any comments to this change. It was of
course my intention to make the code shorter,
On Thu, Dec 28, 2006 at 09:27:12AM -0800, Linus Torvalds wrote:
On Thu, 28 Dec 2006, Russell King wrote:
and if you look at glibc's memset() function, you'll notice that's exactly
what you expect if you pass a non-8bit value to it. Ergo, what you're
seeing is utterly expected given glibc's
On Thu, 2006-12-28 at 19:41 +0100, Daniel Marjamäki wrote:
Hello all!
I sent a patch with this content:
- for (i = 0; i MAX_PIRQS; i++)
- pirq_entries[i] = -1;
+ memset(pirq_entries, -1, sizeof(pirq_entries));
I'd like to know if you have any comments to this
On Thu, 28 Dec 2006, Marc Haber wrote:
After being up for ten days, I have now encountered the file
corruption of pkgcache.bin for the first time again. The 256 MB i386
box is like 26M in swap, is under very moderate load.
I am running plain vanilla 2.6.19.1. Is there a patch that I
On Thu, 28 Dec 2006, Russell King wrote:
Yup, but I have nothing to do with glibc because I refuse to do that
silly copyright assignment FSF thing. Hopefully someone else can
resolve it, but...
Yeah, me too.
_is_ a fix whether _you_ like it or not to work around the issue so
people can
On Thu, Dec 28, 2006 at 11:00:46AM -0800, Linus Torvalds wrote:
And I have a test-program that shows the corruption _much_ easier (at
least according to my own testing, and that of several reporters that back
me up), and that seems to show the corruption going way way back (ie going
back to
On Wed, Dec 27, 2006 at 10:32:53PM +0100, Rene Herman wrote:
Good day.
The bug where the kernel repetitively emits atkbd.c: Spurious ACK on
isa0060/serio0. Some program might be trying access hardware directly
(sic) on a panic, thereby scrolling away the information that would help
Guillaume Chazarain a écrit :
I get this kind of corruption:
http://guichaz.free.fr/linux-bug/corruption.png
Actually in qemu, I get three different behaviours:
- no corruption at all : with linux-2.4
- corruption only on the first chunks: before [PATCH] mm: balance dirty
pages as identified
On Thu, 28 Dec 2006, Petri Kaukasoina wrote:
me up), and that seems to show the corruption going way way back (ie going
back to Linux-2.6.5 at least, according to one tester).
That was a Fedora kernel. Has anyone seen the corruption in vanilla 2.6.18
(or older)?
Well, that was a really
On Thu, 28 Dec 2006, Guillaume Chazarain wrote:
The attached patch fixes the corruption for me.
Well, that's a good hint, but it's really just a symptom. You effectively
just made the test-program not even try to flush the data to disk, so the
page cache would stay in memory, and you'd not
On Thu, Dec 28, 2006 at 11:21:21AM -0800, Linus Torvalds wrote:
On Thu, 28 Dec 2006, Petri Kaukasoina wrote:
me up), and that seems to show the corruption going way way back (ie
going
back to Linux-2.6.5 at least, according to one tester).
That was a Fedora kernel. Has
On Thu, 28 Dec 2006 11:28:52 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
On Thu, 28 Dec 2006, Guillaume Chazarain wrote:
The attached patch fixes the corruption for me.
Well, that's a good hint, but it's really just a symptom. You effectively
just made the test-program not
Hi Tejun,
After the patch was applied (using 2.6.19.1 instead of 2.6.19, hope
you don't mind) I could play a DVD once. Unfortunately this was not
reproducible, using the same DVD. I have attached the requested log
files for the good and the last bad session. Hope this helps.
Which version of the
ext Pierre Ossman wrote:
[EMAIL PROTECTED] wrote:
Did you see this patch at V9 series? This bug is fixed.
I also fixed this code according the latest Russel's comments and will send
again at V9, just this patch.
The V9 you sent me on the 15th was before Russell pointed out the
Daniel Marjamäki [EMAIL PROTECTED] wrote:
I sent a patch with this content:
- for (i = 0; i MAX_PIRQS; i++)
- pirq_entries[i] = -1;
+ memset(pirq_entries, -1, sizeof(pirq_entries));
I'd like to know if you have any comments to this change. It was of
course my
On Thu, 2006-12-28 at 14:39 -0500, Dave Jones wrote:
On Thu, Dec 28, 2006 at 11:21:21AM -0800, Linus Torvalds wrote:
On Thu, 28 Dec 2006, Petri Kaukasoina wrote:
me up), and that seems to show the corruption going way way back (ie
going
back to Linux-2.6.5 at least,
Arjan van de Ven wrote:
...but Marcelo's patch doesn't implement anything of that kind
In addition, many ISA bus drivers do not use the DMA API *at all*
currently. If you want to fix them all up, great! But somehow I doubt
those will get fixed in the next decade.. they've been like this for
On Thu, 28 Dec 2006, Andrew Morton wrote:
It would be interesting to convert your app to do fsync() before
FADV_DONTNEED. That would take WB_SYNC_NONE out of the picture as well
(apart from pdflush activity).
I get corruption - but the whole point is that it's very much pdflush that
On Thu, 28 Dec 2006 17:22:07 +0100 (MET) Jan Engelhardt wrote:
On Dec 28 2006 11:57, Christoph Hellwig wrote:
+
+ if ((error = __lock_page(page, current-io_wait))) {
+ goto readpage_error;
+ }
This should be
error =
From: Jan Andersson [EMAIL PROTECTED]
Add sg-offset to sg-dvma_address in pci_map_sg() on sparc32. Without
the offset, transfers to buffers that do not begin on a page boundary
will not work as expected.
Signed-off-by: Jan Andersson [EMAIL PROTECTED]
---
diff -uprN
On Thu, 28 Dec 2006, Arjan van de Ven wrote:
It seems like the posix idea of unique st_dev, st_ino doesn't
hold water for modern file systems
are you really sure?
and if so, why don't we fix *THAT* instead, rather than adding racy
syscalls and such that just can't really be used right...
This sounds like a bug to me. It seems like we should have a one to one
correspondence of filehandle - inode. In what situations would this not be the
case?
Well, the NFS protocol allows that [see rfc1813, p. 21: If two file handles
from
the same server are equal, they must refer to the same
It seems like the posix idea of unique st_dev, st_ino doesn't
hold water for modern file systems
are you really sure?
Well Jan's example was of Coda that uses 128-bit internal file ids.
and if so, why don't we fix *THAT* instead
Hmm, sometimes you can't fix the world,
Mikulas Patocka wrote:
This sounds like a bug to me. It seems like we should have a one to one
correspondence of filehandle - inode. In what situations would this not be
the
case?
Well, the NFS protocol allows that [see rfc1813, p. 21: If two file handles
from
the same server are
After Al Viro (finally) succeeded in removing the sched.h #include in
module.h recently, it makes sense again to remove other superfluous
sched.h includes.
To ease the pain, this time I did not fiddle with any header files and
only removed #includes from .c-files, which tend to cause less
After fiddling with this patch for so long, I forgot to mention an
important thing:
This time the patch only includes things that need no fixups at all (most
of these already went in last time).
So all hunks are independent, and you can just drop anything that does not
apply or causes any
On Sun, Dec 17, 2006 at 10:05:42PM -0500, Dave Jones wrote:
On Mon, Dec 18, 2006 at 03:57:10AM +0100, Adrian Bunk wrote:
On Thu, Dec 14, 2006 at 04:02:15PM -0500, Dave Jones wrote:
Hmm. Puzzling.
CONFIG_PCI_MULTITHREAD_PROBE=y ?
I pondered that too, and set a kernel building
On Thu, 28 Dec 2006 21:27:40 +0100 (CET)
Tim Schmielau [EMAIL PROTECTED] wrote:
After Al Viro (finally) succeeded in removing the sched.h #include in
module.h recently, it makes sense again to remove other superfluous
sched.h includes.
Why are they superfluous? Because those compilation
Phillip: is this the final version, then? It's missing
a signed-off-by line, so I can't do anything appropriate.
Nico, your signoff here would be a Good Thing too if it
meets your technical review. (My only comment, ISTR, was
that gpio_set_value macro should probably test for whether
the value
On Wednesday 27 December 2006 9:53 am, Pavel Machek wrote:
Hi!
Arch-neutral GPIO calls for PXA.
From: Philipp Zabel [EMAIL PROTECTED]
Missing s-o-b?
Yes, still ...
+static inline int gpio_direction_input(unsigned gpio)
+{
+ if (gpio PXA_LAST_GPIO)
+ return
Hi!
From: Philipp Zabel [EMAIL PROTECTED]
Missing s-o-b?
Yes, still ...
+static inline int gpio_direction_input(unsigned gpio)
+{
+ if (gpio PXA_LAST_GPIO)
+ return -EINVAL;
+ pxa_gpio_mode(gpio | GPIO_IN);
+}
Missing return 0?
+static inline int
On Thu 2006-12-28 21:50:55, Pavel Machek wrote:
Hi!
From: Philipp Zabel [EMAIL PROTECTED]
Missing s-o-b?
Yes, still ...
+static inline int gpio_direction_input(unsigned gpio)
+{
+ if (gpio PXA_LAST_GPIO)
+ return -EINVAL;
+
On Thu, Dec 28, 2006 at 09:40:03PM +0100, Adrian Bunk wrote:
On Sun, Dec 17, 2006 at 10:05:42PM -0500, Dave Jones wrote:
On Mon, Dec 18, 2006 at 03:57:10AM +0100, Adrian Bunk wrote:
On Thu, Dec 14, 2006 at 04:02:15PM -0500, Dave Jones wrote:
Hmm. Puzzling.
On Thu, 28 Dec 2006, Andrew Morton wrote:
On Thu, 28 Dec 2006 21:27:40 +0100 (CET)
Tim Schmielau [EMAIL PROTECTED] wrote:
After Al Viro (finally) succeeded in removing the sched.h #include in
module.h recently, it makes sense again to remove other superfluous
sched.h includes.
Why
On Thu, 28 Dec 2006 12:46:44 -0800 Andrew Morton wrote:
On Thu, 28 Dec 2006 21:27:40 +0100 (CET)
Tim Schmielau [EMAIL PROTECTED] wrote:
After Al Viro (finally) succeeded in removing the sched.h #include in
module.h recently, it makes sense again to remove other superfluous
sched.h
Hi Andrew,
dev_to_node() does not work as expected on x86 and x86_64 as pointed out
earlier here:
http://lkml.org/lkml/2006/11/7/10
Following patch fixes it, please apply. (Note: The fix depends on support
for PCI domains for x86/x86_64)
Thanks,
Kiran
dev_to_node does not work as expected on
On Thu, Dec 28, 2006 at 09:58:17PM +0100, Tim Schmielau wrote:
On Thu, 28 Dec 2006, Andrew Morton wrote:
On Thu, 28 Dec 2006 21:27:40 +0100 (CET)
Tim Schmielau [EMAIL PROTECTED] wrote:
After Al Viro (finally) succeeded in removing the sched.h #include in
module.h recently, it
On Thu, 28 Dec 2006, Randy Dunlap wrote:
I'm half done with a patch to remove includes of smp_lock.h.
For the files that I have patched, I checked each source file
for all interfaces in smp_lock.h to verify that none of them
are used, so the #include is just waste.
Yes, that's what I also
Ravikiran G Thirumalai wrote:
Hi Andrew,
dev_to_node() does not work as expected on x86 and x86_64 as pointed out
earlier here:
http://lkml.org/lkml/2006/11/7/10
Following patch fixes it, please apply. (Note: The fix depends on support
for PCI domains for x86/x86_64)
Thanks, I'll merge into
On Thu, 28 Dec 2006, Al Viro wrote:
Uh-huh. How much of build coverage have you got with it?
Well, as said in the patch description, I compiled alpha, arm, i386, ia64,
mips, powerpc, and x86_64 with allnoconfig, defconfig, allmodconfig, and
allyesconfig as well as a few randconfigs on
On Thu, 28 Dec 2006, Linus Torvalds wrote:
What we need now is actually looking at the source code, and people who
understand the VM, I'm afraid. I'm gathering traces now that I have a good
test-case. I'll post my trace tools once I've tested that they work, in
case others want to help.
Le 28.12.2006 11:42, Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc2/2.6.20-rc2-mm1/
Hello,
got this with 2.6.20-rc2-mm1, reverting
gregkh-driver-driver-core-fix-race-in-sysfs-between-sysfs_remove_file-and-read-write.patch
made it disappear.
On Thu, Dec 28, 2006 at 10:18:12PM +0100, Tim Schmielau wrote:
On Thu, 28 Dec 2006, Al Viro wrote:
Uh-huh. How much of build coverage have you got with it?
Well, as said in the patch description, I compiled alpha, arm, i386, ia64,
mips, powerpc, and x86_64 with allnoconfig, defconfig,
On Thu, Dec 28, 2006 at 01:24:30PM -0800, Linus Torvalds wrote:
On Thu, 28 Dec 2006, Linus Torvalds wrote:
What we need now is actually looking at the source code, and people who
understand the VM, I'm afraid. I'm gathering traces now that I have a good
test-case. I'll post my trace
On Thu, 28 Dec 2006 21:34:38 + Russell King wrote:
On Thu, Dec 28, 2006 at 10:18:12PM +0100, Tim Schmielau wrote:
On Thu, 28 Dec 2006, Al Viro wrote:
Uh-huh. How much of build coverage have you got with it?
Well, as said in the patch description, I compiled alpha, arm, i386,
On Thu, 28 Dec 2006, Russell King wrote:
To cover these, you need to build at least rpc_defconfig, lubbock_defconfig,
netwinder_defconfig, badge4_defconfig, cerf_defconfig, ...etc...
OK, I'll try to do that.
Do I need to build all the configs in arch/arm/configs?
The whole all*config idea on
On Thursday 28 December 2006 03:16, Jon Smirl wrote:
BUG: scheduling while atomic: hald-addon-stor/0x2000/5078
[c02b0289] __sched_text_start+0x5f9/0xb00
[c024a623] net_rx_action+0xb3/0x180
[c01210f2] __do_softirq+0x72/0xe0
[c0105205] do_IRQ+0x45/0x80
This doesn't seem to be related
Dave Jones wrote:
On Wed, Dec 27, 2006 at 10:32:53PM +0100, Rene Herman wrote:
The bug where the kernel repetitively emits atkbd.c: Spurious ACK
on isa0060/serio0. Some program might be trying access hardware
directly (sic) on a panic, thereby scrolling away the information
that would help
On Thu, Dec 28, 2006 at 01:32:46PM -0800, Randy Dunlap wrote:
On Thu, 28 Dec 2006 21:34:38 + Russell King wrote:
The whole all*config idea on ARM is utterly useless - you can _not_
get build coverage that way.
Uh, can J. Random Developer submit patches to the ARM build system
for
Hello Alan, Jeff,
Reading a paper on this new libata, I just want to try but failled yet for what said this
thread ATAPI CDROM ;_(.
I first test the latest stable 2.6.19.1 without luck, so I also want to try latest 2.6.20-rc2 unfortunately without more
success.
Here it was the test of new
CAP_LINUX_IMMUTABLE currently makes it impossible both to chattr +i or
chattr -i.
I think it would be convenient if there was someone to make it only
illegal for chattr -i. So that I could still make files unchangeable,
while not allowing myself to ever make them changeable again without
the
On Thu, 28 Dec 2006, Russell King wrote:
Given that it takes about 8 to 12 hours to do a build cycle, that's
My build cycle takes about 2 hours for 4 configs, on a decent AMD64
system (running completely in tmpfs). Am I doing something wrong or are
you talking about native builds?
Tim
-
To
On Wednesday 27 December 2006 9:49 am, Pavel Machek wrote:
Hi!
Good afternoon. :)
+Identifying GPIOs
+-
+GPIOs are identified by unsigned integers in the range 0..MAX_INT. That
+reserves negative numbers for other purposes like marking signals as
+not available on
On Thursday 28 December 2006 2:05 am, Arjan van de Ven wrote:
Hmm, then maybe it'd be worth updating that patch I just sent so that
the only change is to switch #includes for the extern decl ... i.e. to
export it only to other statically linked kernel code, rather than to
modules. I'll
On Tue, Dec 26, 2006 at 01:15:38AM +0100, Berthold Cogel wrote:
Hello!
Hi Berthold!
'shutdown -h now' doesn't work for my system (Acer Extensa 3002 WLMi)
with linux-2.6.20-rc kernels. The system reboots instead.
I've checked linux-2.6.19.1 with an almost identical .config file
(differences
On Thu, Dec 28, 2006 at 10:53:44PM +0100, Tim Schmielau wrote:
On Thu, 28 Dec 2006, Russell King wrote:
Given that it takes about 8 to 12 hours to do a build cycle, that's
My build cycle takes about 2 hours for 4 configs, on a decent AMD64
system (running completely in tmpfs). Am I doing
On Thu, 28 Dec 2006, Russell King wrote:
I'm talking about cross-builds... I don't know the spec of the machine,
only that it's x86 based (I don't run it.)
The last report at the beginning of this month said: 11 1/2 hours per
git snapshot, which is apparantly for building a total of about
Do we have a right to reverse engineer hardware, or they are protected by
patents or something similar that would prevent you from
publishing results
adn/or drivers (open source).
As I understand the issues, you have the right to reverse engineer hardware
except where the DMCA applies. I
On Thu, 2006-12-28 at 11:45 -0800, Andrew Morton wrote:
On Thu, 28 Dec 2006 11:28:52 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
On Thu, 28 Dec 2006, Guillaume Chazarain wrote:
The attached patch fixes the corruption for me.
Well, that's a good hint, but it's really
401 - 500 of 539 matches
Mail list logo
