twitter: linux.kernel - 25 new messages in 12 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* Simple gesture support query - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/169da9fbf7dbf6c0?hl=en
* X doesn't work with 2.6.33 (can't find any input devices) - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/1ee262eda73e4cc2?hl=en
* drm request 3 - 4 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/714ed3b32a64e42a?hl=en
* v3 kconfig: place git SHA1 in .config output if in SCM - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/0e00be2180077408?hl=en
* [v6] PV extension of HVM (Hybrid) for Xen - 8 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ceadb17507e53f67?hl=en
* Linux kernel - Libata bad block error handling to user mode program - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/43729a69ccf0463d?hl=en
* -next March 3: Boot failure on x86 (Oops) - 3 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0e17a94297635a64?hl=en
* perf_event: Fix oops triggered by cpu offline/online - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/25a6ed6ecb1bcfdc?hl=en
* msi-laptop: Support some MSI 3G netbook that is need load SCM - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/6f9c3ab54f6e9989?hl=en
* dump/restore not supported for ext4 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/e455dce6f733987b?hl=en
* perf, x86: PEBS infrastructure - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/996956232d954b7c?hl=en
* slab: add memory hotplug support - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a8beda1232363b5e?hl=en

==============================================================================
TOPIC: Simple gesture support query
http://groups.google.com/group/linux.kernel/t/169da9fbf7dbf6c0?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 4 2010 9:20 pm
From: Sriram V

Hi,
I have a couple of queries in gesture support:

1) How are they handled in a touch driver - how are they is reported
back to the application?
2) Are there any standard test utilities for verifying this.

Regards,
sriram
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: X doesn't work with 2.6.33 (can't find any input devices)
http://groups.google.com/group/linux.kernel/t/1ee262eda73e4cc2?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 4 2010 9:20 pm
From: Dave Airlie

On Thu, Mar 4, 2010 at 1:17 AM, <tytso@mit.edu> wrote:
> After working around lvm breakage so I could at least boot 2.6.33, I'm
> now finding the next problem --- X doesn't work. If I let X come up,
> it doesn't find any mouse or keyboard devices, so my machine becomes
> useless and I have to power cycle it unless I can log in remotely and
> reboot it.
>
> It worked just *fine* using 2.6.33-rc4. I have no xorg.conf file (X
> is autoconfiguring itself) and I'm using an Ubuntu 9.10 userspace.
>
> I've enclosed the dmesg output (which shows the input devices
> correctly being detected by the kernel) and the Xorg.0.log file from
> the previous boot, where X does not come up.
>
> At this point, I'm not going to be able to dogfood test my ext4
> patches I plan to push to Linus, since 2.6.33 is completely useless to
> me. Hopefully running the regression tests under KVM is going to have
> to be good enough.
>

Are you using 32 on 64 or anything like that?

15e184afa83a45cf8bafdb9dc906b97a8fbc974f is the only thing I can
see that might be close to changing something.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: drm request 3
http://groups.google.com/group/linux.kernel/t/714ed3b32a64e42a?hl=en
==============================================================================

== 1 of 4 ==
Date: Thurs, Mar 4 2010 9:20 pm
From: Linus Torvalds

On Fri, 5 Mar 2010, Dave Airlie wrote:
>
> wget http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-nouveau/0.0.16/2.20100218git2964702.fc13/src/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm
> rebuild + install.

This one doesn't work on F12.

It wants xorg-x11-server-devel > 1.7.99.3-3.

Is there some limited set of rpm's I can get from the f13 archive?

Linus

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 4 ==
Date: Thurs, Mar 4 2010 9:30 pm
From: Dave Airlie

On Fri, Mar 5, 2010 at 3:17 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Fri, 5 Mar 2010, Dave Airlie wrote:
>>
>> wget http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-nouveau/0.0.16/2.20100218git2964702.fc13/src/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm
>> rebuild + install.
>
> This one doesn't work on F12.
>
> It wants xorg-x11-server-devel > 1.7.99.3-3.
>
> Is there some limited set of rpm's I can get from the f13 archive?

If by limited you mean the whole X server + udev updates that would work,

if not then:
http://people.fedoraproject.org/~airlied/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.test.src.rpm

That src rpm should be rebuildable on F12, I just removed the requires
on F13 stuff.

== 3 of 4 ==
Date: Thurs, Mar 4 2010 9:40 pm
From: Linus Torvalds

On Fri, 5 Mar 2010, Dave Airlie wrote:
>
> if not then:
> http://people.fedoraproject.org/~airlied/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.test.src.rpm
>
> That src rpm should be rebuildable on F12, I just removed the requires
> on F13 stuff.

Well, that wants the new kernel, but I can force it with --nodeps..

I'll reboot and test.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 4 of 4 ==
Date: Thurs, Mar 4 2010 9:50 pm
From: Linus Torvalds

On Thu, 4 Mar 2010, Linus Torvalds wrote:
> On Fri, 5 Mar 2010, Dave Airlie wrote:
> >
> > if not then:
> > http://people.fedoraproject.org/~airlied/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.test.src.rpm
> >
> > That src rpm should be rebuildable on F12, I just removed the requires
> > on F13 stuff.
>
> Well, that wants the new kernel, but I can force it with --nodeps..
>
> I'll reboot and test.

Bingo.

Could this be done as a real F12 binary package (maybe call it
"force-nouveau-0.0.16" or something) for testers to use? I had most of the
X devel tools set up anyway since I used to build intel drivers from git
for one of my experimental machines. And I guess most kernel devs can
generally easily do the rpm build, but I'd hate to lose any more plain
testers than I absolutely have to.

And it would make it way easier for people to try out their kernel, notice
that X doesn't work, and then let them know that something like a simple

yum install force-nouveau-0.0.16

makes it work. Compared to having them install X builds, do a "rpm -Uvh
--nodeps" etc etc.

Anyway, this at least makes me feel like I don't have to revert that
commit just to be able to test current -git again. Thanks,

==============================================================================
TOPIC: v3 kconfig: place git SHA1 in .config output if in SCM
http://groups.google.com/group/linux.kernel/t/0e00be2180077408?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Mar 4 2010 9:30 pm
From: "Paul E. McKenney"

On Fri, Mar 05, 2010 at 04:43:27AM +0100, Frans Pop wrote:
> On Friday 05 March 2010, Paul E. McKenney wrote:
> > o Added the KBUILD_CONFIG_NO_CHECK_DIRTY environment variable,
> > and modified scripts/setlocalversion to check it, as suggested
> > by James Cloos.
>
> Just to state the obvious: this will also affect CONFIG_LOCALVERSION_AUTO.
>
> > @@ -450,12 +457,52 @@ int conf_write(const char *name)
> > if (env && *env)
> > use_timestamp = 0;
> >
> > + strcpy(localversion, "-?-nopath");
> > + path = getenv(SRCTREE);
> > + if (path && *path) {
> > + strcpy(localversion, "-?-pipe()-failed");
> > + if (pipe(pipefd) != 0)
> > + goto nolocalversion;
> > + env = getenv("KBUILD_CONFIG_NO_CHECK_DIRTY");
>
> Is this line actually needed? AFAICT the variable is unused here and should
> pass down through the environment to the setlocalversion script without
> needing any help.

No, it is not needed. This is a holdover from an earlier version that
tried passing in just that one environment variable.

Good eyes, will fix!

> > + sprintf(cmdline, "%s/scripts/setlocalversion", path);
> > + strcpy(localversion, "-?-fork()-failed");
> > + pid = fork();
>
> Do I read correctly that you're also postfixing error conditions to the
> kernel version? Don't think that's a great idea TBH. Errors should be
> printed to STDERR as they occur, not as pseudo version strings.

That is the intent.

> Users coming across them in config files would be very unlikely to be able
> to make any sense of them. IMO, if no VCS version can be determined,
> nothing should be printed.

Hmmm... I guess I can leave stderr untouched through to the child and
add the code needed to reap the children and report any error codes.

But let's work out what the error strategy should be. The below are my
initial guesses, I of course must defer to those more familiar with
kbuild and kconfig than am I.

1. Oddball SCM conditions should not cause the build to fail.
"Arrrgh!!! What dot-file do I need to remove in order for
my builds to start succeeding???"

2. Errors should leave some hint in the .config file, rather
than simply mysteriously omitting the version/dirty information.

Yes, stderr can be captured, but if it doesn't break the build,
it is likely to be ignored.

3. It is OK to dump to stderr (I think), but the format should be
something that typical error-check scripts catch.

What would that be? How about the following pattern that every
build-error-check script must pay attention to?

scripts/confdata.c:nnnn error: <perror output>

4. Should the splat in the .config file identify the file and
line number? For example: "-error: scripts/confdata.c:nnnn"

5. Anything else that I have missed?

After this is done, I am going to return to something easier to
understand, like the Linux kernel's RCU implementation. ;-)

Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Thurs, Mar 4 2010 10:20 pm
From: Mike Galbraith

On Thu, 2010-03-04 at 18:54 -0800, Paul E. McKenney wrote:
> This patch appends the localversion string to the Linux kernel version.
> For example, in a git tree with uncommitted changes, the .config file
> might start as follows (but with leading hash marks):
>
> Automatically generated make config: don't edit
> Linux kernel version: 2.6.33-01836-g90a6501-dirty
> Mon Mar 1 17:05:59 2010
>
> The "-01836-g90a6501-dirty" string is added by this patch.

I really like this. This gives me the advantages of non-volatile build
info without the mess that makes if it's appended to file names/paths.

-Mike

Eventually someone will make bisect stop stepping on random kernels, and
generally making a mess, and life will be grand ;-)

==============================================================================
TOPIC: [v6] PV extension of HVM (Hybrid) for Xen
http://groups.google.com/group/linux.kernel/t/ceadb17507e53f67?hl=en
==============================================================================

== 1 of 8 ==
Date: Thurs, Mar 4 2010 10:10 pm
From: Sheng Yang

Hi, Jeremy

Here is the sixth version of patchset to enable PV extension of HVM support
in Linux kernel of Xen.

The PV extension of HVM is started from real mode like HVM guest, but also with a
a range of PV features(e.g. PV timer, event channel, as well as PV
drivers). So guest with this feature can takes the advantages of both H/W
virtualization and Para-Virtualization.

The first two of the patchset imported several header file from Jeremy's tree
and Xen tree, respect to Jeremy and Keir's works.

The whole patchset based on Linux upstream.

You need a line like:

cpuid = [ '0x40000002:edx=0x3' ]

in HVM configuration file to expose hybrid feature to guest, and

CONFIG_XEN

in the guest kernel configuration file to enable the hybrid support.

And the compiled image can be used as native/pv domU/hvm guest/pv feature hvm kernel.

Current the patchset support x86_64 only.

Current base is on Linux 2.6.33.

Change from v5:
Update the comments from Jeremy.

Change from v4:
1. Add a new CONFIG_XEN_HVM_PV to enable the feature in kernel
2. Separate the related code form enlighted.c to hvmpv.c
3. Separate the feature "PV clocksource" from evtchn. Now we can support HVM
guest with PV clocksource. This would be enabled by default.
4. Drop PV halt and pv drivers in this edition. We can work on that
later.
5. Update the patchset following Jeremy's comments.

Change from v3:
1. Rebase to Linux 2.6.33 release.
2. change the name to "PV extension of HVM"
3. Some minor coding polishing.

Change from v2:
1. change the name "hybrid" to "PV featured HVM".
2. Unified the PV driver's judgement of xen_domain() to xen_evtchn_enabled().
3. Move the function(evtchn) initialize hypercall near the real enabling place,
rather than a unified place before function enabled.
4. Remove the reserved E820 region for grant table. Use QEmu Xen platform
device's MMIO instead.

The major change from v1:
1. SMP support.
2. Modify the entrance point to avoid most of genernic kernel modification.
3. Binding PV timer with event channel mechanism.

--
regards
Yang, Sheng

arch/x86/include/asm/xen/cpuid.h | 73 +++++++++++
arch/x86/include/asm/xen/hypercall.h | 6 +
arch/x86/include/asm/xen/hypervisor.h | 6 +
arch/x86/kernel/setup.c | 4 +
arch/x86/xen/Kconfig | 4 +
arch/x86/xen/Makefile | 1 +
arch/x86/xen/enlighten.c | 6 +-
arch/x86/xen/hvmpv.c | 214 +++++++++++++++++++++++++++++++++
arch/x86/xen/irq.c | 28 +++++
arch/x86/xen/smp.c | 76 +++++++++++-
arch/x86/xen/time.c | 12 ++-
arch/x86/xen/xen-ops.h | 17 +++
drivers/block/xen-blkfront.c | 2 +-
drivers/input/xen-kbdfront.c | 2 +-
drivers/net/xen-netfront.c | 2 +-
drivers/video/xen-fbfront.c | 2 +-
drivers/xen/events.c | 74 +++++++++++-
drivers/xen/grant-table.c | 2 +-
drivers/xen/xenbus/xenbus_probe.c | 4 +-
include/xen/events.h | 4 +
include/xen/hvm.h | 28 +++++
include/xen/interface/hvm/hvm_op.h | 80 ++++++++++++
include/xen/interface/hvm/params.h | 111 +++++++++++++++++
include/xen/interface/xen.h | 6 +-
include/xen/xen.h | 11 ++
25 files changed, 753 insertions(+), 22 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 8 ==
Date: Thurs, Mar 4 2010 10:10 pm
From: Sheng Yang

From: Keir Fraser <keir.fraser@citrix.com>

Which would be used by CPUID detection later

Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
Signed-off-by: Sheng Yang <sheng@linux.intel.com>
---
arch/x86/include/asm/xen/cpuid.h | 68 ++++++++++++++++++++++++++++++++++++++
1 files changed, 68 insertions(+), 0 deletions(-)
create mode 100644 arch/x86/include/asm/xen/cpuid.h

diff --git a/arch/x86/include/asm/xen/cpuid.h b/arch/x86/include/asm/xen/cpuid.h
new file mode 100644
index 0000000..8787f03
--- /dev/null
+++ b/arch/x86/include/asm/xen/cpuid.h
@@ -0,0 +1,68 @@
+/******************************************************************************
+ * arch/include/asm/xen/cpuid.h
+ *
+ * CPUID interface to Xen.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2007 Citrix Systems, Inc.
+ *
+ * Authors:
+ * Keir Fraser <keir.fraser@citrix.com>
+ */
+
+#ifndef __ASM_X86_XEN_CPUID_H__
+#define __ASM_X86_XEN_CPUID_H__
+
+/* Xen identification leaves start at 0x40000000. */
+#define XEN_CPUID_FIRST_LEAF 0x40000000
+#define XEN_CPUID_LEAF(i) (XEN_CPUID_FIRST_LEAF + (i))
+
+/*
+ * Leaf 1 (0x40000000)
+ * EAX: Largest Xen-information leaf. All leaves up to an including @EAX
+ * are supported by the Xen host.
+ * EBX-EDX: "XenVMMXenVMM" signature, allowing positive identification
+ * of a Xen host.
+ */
+#define XEN_CPUID_SIGNATURE_EBX 0x566e6558 /* "XenV" */
+#define XEN_CPUID_SIGNATURE_ECX 0x65584d4d /* "MMXe" */
+#define XEN_CPUID_SIGNATURE_EDX 0x4d4d566e /* "nVMM" */
+
+/*
+ * Leaf 2 (0x40000001)
+ * EAX[31:16]: Xen major version.
+ * EAX[15: 0]: Xen minor version.
+ * EBX-EDX: Reserved (currently all zeroes).
+ */
+
+/*
+ * Leaf 3 (0x40000002)
+ * EAX: Number of hypercall transfer pages. This register is always guaranteed
+ * to specify one hypercall page.
+ * EBX: Base address of Xen-specific MSRs.
+ * ECX: Features 1. Unused bits are set to zero.
+ * EDX: Features 2. Unused bits are set to zero.
+ */
+
+/* Does the host support MMU_PT_UPDATE_PRESERVE_AD for this guest? */
+#define _XEN_CPUID_FEAT1_MMU_PT_UPDATE_PRESERVE_AD 0
+#define XEN_CPUID_FEAT1_MMU_PT_UPDATE_PRESERVE_AD (1u<<0)
+
+

twitter

Thursday, March 4, 2010

linux.kernel - 25 new messages in 12 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts