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 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)
> > > > +
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
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)
> > +
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 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
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
On Thu, 28 Dec 2006 11:55:04 -0800 Paul E. McKenney wrote:
> list.h | 58 ++
> 1 file changed, 58 insertions(+)
>
> diff -urpNa -X dontdiff linux-2.6.19/include/linux/list.h
> linux-2.6.19-lpr/include/linux/list.h
> ---
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
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
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
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, 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
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
>>
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
>
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
> >> It seems like the posix idea of unique 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,
On Thu, Dec 28, 2006 at 06:31:01PM +, Christoph Hellwig wrote:
> > + if (list_empty(>cmd_rcvrs))
> > + INIT_LIST_HEAD();
> > + else {
> > + list.next = intf->cmd_rcvrs.next;
> > + list.prev = intf->cmd_rcvrs.prev;
> > + INIT_LIST_HEAD(>cmd_rcvrs);
>
from: Martin Williges <[EMAIL PROTECTED]>
This patch gets the Kyocera FS-820 working with cups 1.2 via usb again. It
adds the printer to the list of "quirky" printers. The printer seems not
answer to ID requests some seconds after plugging in. Patch is based on
linux-2.6.19.1.
Signed-off-by:
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
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
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
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
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
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 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
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
>
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
>
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
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
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
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 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
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
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
Paul E. McKenney wrote:
On Fri, Dec 01, 2006 at 10:24:22PM -0600, Corey Minyard wrote:
This patch removes the arbitrary limit of number of IPMI interfaces.
This has been tested with 8 interfaces.
I got a bit lost in this patch, so applied it to 2.6.19-rc6 and looked
over the resulting
> + if (list_empty(>cmd_rcvrs))
> + INIT_LIST_HEAD();
> + else {
> + list.next = intf->cmd_rcvrs.next;
> + list.prev = intf->cmd_rcvrs.prev;
> + INIT_LIST_HEAD(>cmd_rcvrs);
> +
> + /*
> + * At this point the list body
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
+++
Fix some RCU problem pointed out by Paul McKenney of IBM. These are:
The wholesale move of the command receivers list into a new list was
not safe because the list will point to the new tail during a
traversal, so the traversal will never end on a reader if this happens
during a read.
Memory
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
On Thu, 28 Dec 2006, Arjan van de Ven wrote:
It seems like the posix idea of unique 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...
Why don't you
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
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
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, 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
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
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
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, 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
>
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
>>
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
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 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
> >
> >
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 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
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 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 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.
* 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
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
* 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
[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
Benny Halevy wrote:
Jeff Layton wrote:
Benny Halevy wrote:
It seems like the posix idea of unique 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
* 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
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
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"
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
Arjan van de Ven wrote:
>> It seems like the posix idea of unique 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,
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 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
Jeff Layton wrote:
> Benny Halevy wrote:
>> It seems like the posix idea of unique 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 don't
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
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
* 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()
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
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));
> >
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
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
> 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
Location:
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/
git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
RSS feed of the git tree:
http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=rss
Changes since 2.6.16.36:
Adrian Bunk (5):
Loye Young wrote:
>>Take for example the AT keyboard which is
>>one of the most common keyboards in the world. I have seen and
>>used it attached to a PC via parport, serial port and the standard
>>PS/2 port. So to handle cases like this the input layer created a
>>serio interface.
>
>
> If
>On linux-26..20-rc2, "modprobe kvm-intel" loaded the module
>successful, but running qemu returns a error ...
>
>/usr/local/kvm/bin/qemu -hda vdisk.img -cdrom cd.iso -boot d -m 128
>open /dev/kvm: No such file or directory
>Could not initialize KVM, will disable KVM support
Are you sure the
Ingo Molnar wrote:
I've got a security related question as well: vcpu_load() sets up a
physical CPU's VM registers/state, and vcpu_put() drops that. But
vcpu_put() only does a put_cpu() call - it does not tear down any VM
state that has been loaded into the CPU. Is it guaranteed that (hostile)
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> >Subject: [patch] kvm: fix GFP_KERNEL allocation in atomic section in
> >kvm_dev_ioctl_create_vcpu()
> >From: Ingo Molnar <[EMAIL PROTECTED]>
> >
> >fix an GFP_KERNEL allocation in atomic section:
> >kvm_dev_ioctl_create_vcpu()
Benny Halevy wrote:
It seems like the posix idea of unique 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 don't enforce that
they have unique
> 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 same driver one up and one down.
Alan
-
To
Hi,
I am working on a testing framework for file systems focusing on
repair and recovery areas. Right now, I have been timing fsck and
trying to determine the effectiveness of fsck. The idea that I have is
below.
In abstract terms, I create a file system (ideal state), corrupt it,
run fsck on
This is an experiment on how an SD/MMC card could be used in the MTD layer.
I don't currently have a system set up to test this, so this driver is
completely _untested_ and therefore you should consider it _broken_.
You can get similar functionality by using the mmc_block driver together
with
mxser_new, clean request_irq call
We always set ASYNC_SHARE_IRQ, so do not test against this flag and request
shared irq directly. Also remove nonsense comment.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit ab35af25a3d01f1e07fc8de5b96f484b93a8ad2a
tree
mxser, obsolete old, nonexperimental new
Mark v 1.x as obsolete and v 2.x as non-experimental in Kconfig.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit ce3d140accc090dee75676a4db2b1ddf7b39843e
tree a4322efa3ce3a55abd76340d769ec8e365a43b38
parent
mxser_new, remove tty_wakeup bottomhalf
It's safe to call tty_wakeup from irq context. Do not schedule it for later
calling.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit ec5dee09bf3e78d886d61168625e63280c715739
tree ec09e7afa162b4901d4304d89e588a12df77e494
parent
mxser_new, remove unused stuff
- nobody waits on close_wait
- ASYNC_SPLIT_TERMIOS is not set by anybody, so do not test this flag
- process session and pgrp are useless information
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit 8fc2346d2eab1a1780c319ddd77d818a270aba02
tree
Ingo Molnar wrote:
Subject: [patch] kvm: fix GFP_KERNEL allocation in atomic section in
kvm_dev_ioctl_create_vcpu()
From: Ingo Molnar <[EMAIL PROTECTED]>
fix an GFP_KERNEL allocation in atomic section:
kvm_dev_ioctl_create_vcpu() called kvm_mmu_init(), which calls
alloc_pages(), while
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Yes it does. It calls nonpaging_init_context() which calls
> > vmx_set_cr3() which promptly trashes address space of the VM that
> > previously ran on that vcpu (or, if there were none, logs a vmwrite
> > error).
>
> ok, i missed that.
On linux-26..20-rc2, "modprobe kvm-intel" loaded the module
successful, but running qemu returns a error ...
/usr/local/kvm/bin/qemu -hda vdisk.img -cdrom cd.iso -boot d -m 128
open /dev/kvm: No such file or directory
Could not initialize KVM, will disable KVM support
/dev/kvm does not
Jesper Juhl wrote:
I get this message in my webservers (with NFS mounted homedirs) logs once
in a while :
kernel: VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a
nice day...
It doesn't seem to have any bad effect on anything, but it would be nice
to know if there is
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> >fix a GFP_KERNEL allocation in atomic section bug:
> >kvm_dev_ioctl_create_vcpu() called kvm_mmu_init(), which calls
> >alloc_pages(), while holding the vcpu. The fix is to set up the MMU
> >state earlier, it does not require a loaded CPU state.
>
>
Ingo Molnar wrote:
Subject: [patch] kvm: fix GFP_KERNEL allocation in atomic section in
kvm_dev_ioctl_create_vcpu()
From: Ingo Molnar <[EMAIL PROTECTED]>
fix a GFP_KERNEL allocation in atomic section bug:
kvm_dev_ioctl_create_vcpu() called kvm_mmu_init(), which calls
alloc_pages(), while
Subject: [patch] kvm: fix GFP_KERNEL allocation in atomic section in
kvm_dev_ioctl_create_vcpu()
From: Ingo Molnar <[EMAIL PROTECTED]>
fix a GFP_KERNEL allocation in atomic section bug:
kvm_dev_ioctl_create_vcpu() called kvm_mmu_init(), which calls
alloc_pages(), while holding the vcpu. The
Ingo Molnar wrote:
Subject: [patch] kvm: fix GFP_KERNEL alloc in atomic section bug
From: Ingo Molnar <[EMAIL PROTECTED]>
KVM does kmalloc() in an atomic section while having preemption disabled
via vcpu_load(). Fix this by moving the ->*_msr setup from the
vcpu_setup method to the
101 - 200 of 539 matches
Mail list logo
