[PATCH 2/2] Input: fix use-after-free introduced with dynamic minor changes
Commit 7f8d4cad1e4e11a45d02bd6e024cc2812963c38a made evdev, joydev and mousedev to embed struct cdev into their respective structures representing input devices. Unfortunately character device structure may outlive the parent structure unless we do not set it up as parent of character device so that it will stay pinned until character device is freed. Also, now that parent structure is pinned while character device exists we do not need to pin and unpin it every time user opens or closes it. Reported-by: Dave Jones Signed-off-by: Dmitry Torokhov --- drivers/input/evdev.c| 3 +-- drivers/input/joydev.c | 3 +-- drivers/input/mousedev.c | 3 +-- 3 files changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c index 6ae2ac4..49d9e34 100644 --- a/drivers/input/evdev.c +++ b/drivers/input/evdev.c @@ -292,7 +292,6 @@ static int evdev_release(struct inode *inode, struct file *file) kfree(client); evdev_close_device(evdev); - put_device(&evdev->dev); return 0; } @@ -331,7 +330,6 @@ static int evdev_open(struct inode *inode, struct file *file) file->private_data = client; nonseekable_open(inode, file); - get_device(&evdev->dev); return 0; err_free_client: @@ -1001,6 +999,7 @@ static int evdev_connect(struct input_handler *handler, struct input_dev *dev, goto err_free_evdev; cdev_init(&evdev->cdev, &evdev_fops); + evdev->cdev.parent = &evdev->dev; error = cdev_add(&evdev->cdev, evdev->dev.devt, 1); if (error) goto err_unregister_handle; diff --git a/drivers/input/joydev.c b/drivers/input/joydev.c index 63e5916..00c3537 100644 --- a/drivers/input/joydev.c +++ b/drivers/input/joydev.c @@ -262,7 +262,6 @@ static int joydev_release(struct inode *inode, struct file *file) kfree(client); joydev_close_device(joydev); - put_device(&joydev->dev); return 0; } @@ -289,7 +288,6 @@ static int joydev_open(struct inode *inode, struct file *file) file->private_data = client; nonseekable_open(inode, file); - get_device(&joydev->dev); return 0; err_free_client: @@ -877,6 +875,7 @@ static int joydev_connect(struct input_handler *handler, struct input_dev *dev, goto err_free_joydev; cdev_init(&joydev->cdev, &joydev_fops); + joydev->cdev.parent = &joydev->dev; error = cdev_add(&joydev->cdev, joydev->dev.devt, 1); if (error) goto err_unregister_handle; diff --git a/drivers/input/mousedev.c b/drivers/input/mousedev.c index a1b4c37..b65d476 100644 --- a/drivers/input/mousedev.c +++ b/drivers/input/mousedev.c @@ -523,7 +523,6 @@ static int mousedev_release(struct inode *inode, struct file *file) kfree(client); mousedev_close_device(mousedev); - put_device(&mousedev->dev); return 0; } @@ -558,7 +557,6 @@ static int mousedev_open(struct inode *inode, struct file *file) file->private_data = client; nonseekable_open(inode, file); - get_device(&mousedev->dev); return 0; err_free_client: @@ -892,6 +890,7 @@ static struct mousedev *mousedev_create(struct input_dev *dev, } cdev_init(&mousedev->cdev, &mousedev_fops); + mousedev->cdev.parent = &mousedev->dev; error = cdev_add(&mousedev->cdev, mousedev->dev.devt, 1); if (error) goto err_unregister_handle; -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] char_dev: allow setting up and pinning parent devices
In certain cases (for example when a cdev structure is embedded into
another object whose lifetime is controlled by a separate device object)
it is beneficial to tie lifetime of another struct device to the lifetime
of character device so that related object is not freed until after
char_dev object is freed. To achieve this allow setting a "parent" device
for character devices and pin them when doing cdev_add() and unpin when
last reference to cdev structure is being released.
Signed-off-by: Dmitry Torokhov
---
Sorry, messed up the first attempt to send...
So, how about these 2? I enabled kmemleak and added some debug printks and
it looks like we dropping references and freeing object at right times and
in proper order.
Thanks!
fs/char_dev.c| 18 +-
include/linux/cdev.h | 1 +
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/fs/char_dev.c b/fs/char_dev.c
index 3f152b9..f8c44cc 100644
--- a/fs/char_dev.c
+++ b/fs/char_dev.c
@@ -471,9 +471,19 @@ static int exact_lock(dev_t dev, void *data)
*/
int cdev_add(struct cdev *p, dev_t dev, unsigned count)
{
+ int error;
+
p->dev = dev;
p->count = count;
- return kobj_map(cdev_map, dev, count, NULL, exact_match, exact_lock, p);
+
+ error = kobj_map(cdev_map, dev, count, NULL,
+exact_match, exact_lock, p);
+ if (error)
+ return error;
+
+ get_device(p->parent);
+
+ return 0;
}
static void cdev_unmap(dev_t dev, unsigned count)
@@ -498,14 +508,20 @@ void cdev_del(struct cdev *p)
static void cdev_default_release(struct kobject *kobj)
{
struct cdev *p = container_of(kobj, struct cdev, kobj);
+ struct device *parent = p->parent;
+
cdev_purge(p);
+ put_device(parent);
}
static void cdev_dynamic_release(struct kobject *kobj)
{
struct cdev *p = container_of(kobj, struct cdev, kobj);
+ struct device *parent = p->parent;
+
cdev_purge(p);
kfree(p);
+ put_device(parent);
}
static struct kobj_type ktype_cdev_default = {
diff --git a/include/linux/cdev.h b/include/linux/cdev.h
index fb45919..eba8251 100644
--- a/include/linux/cdev.h
+++ b/include/linux/cdev.h
@@ -12,6 +12,7 @@ struct module;
struct cdev {
struct kobject kobj;
struct module *owner;
+ struct device *parent;
const struct file_operations *ops;
struct list_head list;
dev_t dev;
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION] nouveau: Severe screen corruption on (0xaf, nv50)
On Thu, Oct 18, 2012 at 11:58:09AM +0200, Henrik Rydberg wrote: > Hi Ben, > > 3.7-rc1 messed up the screen on my MacBookAir3,1 (nv50, 0xaf) pretty > badly. Not surprisingly, > > commit 3863c9bc887e9638a9d905d55f6038641ece78d6 > Author: Ben Skeggs > Date: Sat Jul 14 19:09:17 2012 +1000 > > drm/nouveau/instmem: completely new implementation, as a subdev module > > is the first bad commit. Standing on that commit, booting and then > starting X yields the output below. Hints are especially appreciated, > considering the patch is almost 8000 lines. Going through one suspend/resume cycle makes the corruption go away, and there are no more errors in dmesg. Oddly enough, I have seen something very similar when using i915 on the MBP10. Builtin modules and systemd in both cases. Maybe this is a general drm issue. Any thoughts? Thanks, Henrik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Request for review] Revised delete_module(2) manual page
Ping! Rusty (et al.) I'm pretty sure the new page text is okay, but I would like someone knowledgeable to confirm. Thanks, Michael -- Forwarded message -- From: Michael Kerrisk (man-pages) Date: Fri, Oct 12, 2012 at 10:47 AM Subject: Re: [Request for review] Revised delete_module(2) manual page Hi Rusty, Thanks for taking a look at this page. In the light of your comments, I've substantially reworked the page, and further review would not go amiss, in case I made a misstep along the way. On Thu, Oct 11, 2012 at 5:02 AM, Rusty Russell wrote: > "Michael Kerrisk (man-pages)" writes: > >> Hello Kees, Rusty, >> >> The current delete_module(2) page is severely out of date (basically, >> its content corresponds to 2.4 days, and was even pretty thin in >> covering that). So, I took a shot at revising the page to Linux 2.6+ >> reality. Would it be possible that you could review it? > > OK. Main suggestion is that I discussed with Lucas removing the > !O_NONBLOCK case. It's not supported by modprobe -r, and almost > unheard-of for rmmod (it's --wait). > > In practice, people want the unload-or-fail semantics, or the > force-unload semantics. Okay -- I've substantially reworked the page to reflect these idea. >> Otherwise, by default, >> .BR delete_module () >> marks a module so that no new references are permitted. >> If the module's reference count >> (i.e., the number of processes currently using the module) is nonzero, >> it then places the caller in an uninterruptible sleep >> state until all reference count is zero, >> at which point the call unblocks. >> When the reference count reaches zero, the module is unloaded. > > So this should be inverted: > > Otherwise (assuming O_NONBLOCK, see flags below), if the > module's reference count (i.e., the number of processes > currently using the module) is nonzero, the call fails. Got it. See my reworked text. [...] > NOTES: > > If O_NONBLOCK is not set, then the kernel may enter uninterruptible > sleep until the module reference count reaches zero. This is not > generally desirable, so this flag may be compulsory in future kernel > configurations. I've added some text under NOTES. Okay, below (and attached) is the new version of the page. Let me know of any concerns. Cheers, Michael .\" Copyright (C) 2012 Michael Kerrisk .\" .\" Permission is granted to make and distribute verbatim copies of this .\" manual provided the copyright notice and this permission notice are .\" preserved on all copies. .\" .\" Permission is granted to copy and distribute modified versions of this .\" manual under the conditions for verbatim copying, provided that the .\" entire resulting derived work is distributed under the terms of a .\" permission notice identical to this one. .\" .\" Since the Linux kernel and libraries are constantly changing, this .\" manual page may be incorrect or out-of-date. The author(s) assume no .\" responsibility for errors or omissions, or for damages resulting from .\" the use of the information contained herein. The author(s) may not .\" have taken the same level of care in the production of this manual, .\" which is licensed free of charge, as they might when working .\" professionally. .\" .\" Formatted or processed versions of this manual, if unaccompanied by .\" the source, must acknowledge the copyright and authors of this work. .\" .TH DELETE_MODULE 2 2012-10-12 "Linux" "Linux Programmer's Manual" .SH NAME delete_module \- unload a kernel module .SH SYNOPSIS .nf .BI "int delete_module(const char *" name ", int " flags ); .fi .IR Note : There is no glibc wrapper for this system call; see NOTES. .SH DESCRIPTION The .BR delete_module () system call attempts to remove the unused loadable module entry identified by .IR name . If the module has an .I exit function, then that function is executed before unloading the module. The .IR flags argument is used to modify the behavior of the system call, as described below. This system call requires privilege. Module removal is attempted according to the following rules: .IP 1. 4 If there are other loaded modules that depend on (i.e., refer to symbols defined in) this module, then the call fails. .IP 2. Otherwise, if the reference count for the module (i.e., the number of processes currently using the module) is zero, then the module is immediately unloaded. .IP 3. If a module has a nonzero reference count, then the behavior depends on the bits set in .IR flags . In normal usage (see NOTES), the .BR O_NONBLOCK flag is always specified, and the .BR O_TRUNC flag may additionally be specified. .\" O_TRUNC == KMOD_REMOVE_FORCE in kmod library .\" O_NONBLOCK == KMOD_REMOVE_NOWAIT in kmod library The various combinations for .I flags have the following effect: .RS 4 .TP .B flags == O_NONBLOCK The call returns immediately, with an error. .TP .B flags == (O_NONBLOCK | O_TRUNC) The module is unloaded immediately, regardless of whether it has a non
Re: [PATCH 1/2] char_dev: allow setting up and pinning parent devices
On Sun, Oct 21, 2012 at 12:24:30AM -0700, Dmitry Torokhov wrote: > In certain cases (for example when a cdev structure is embedded into > another object whose lifetime is controlled by a separate device object) > it is beneficial to tie lifetime of another struct device to the lifetime > of character device so that related object is not freed until after > char_dev object is freed. To achieve this allow setting a "parent" device > for character devices and pin them when doing cdev_add() and unpin when > last reference to cdev structure is being released. Why struct device and not simply struct kobject? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: question about context switch on arm Linux
On Sun, Oct 21, 2012 at 02:02:42PM +0800, caiyuqing wrote: > hi, all. > I have some questions about context switch on arm Linux (my target is > ARMv7-a). > 1. Does arm linux support FCSE to handle the context switch? No, mainline Linux does not support FCSE. However, you can use Gilles' unoffical (but working) FCSE branches at http://git.xenomai.org/?p=ipipe-gch.git;a=summary > 2. If using FCSE, that means the processes number limit is 128 and the > memory limit is 32MB per process, is that right? Yes and no. Gilles' patches offer a "strict mode" and a "best effort" mode. The strict mode does have the limitation, but the best effort mode does not. HTH, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] firmware loader: misc changes
On Tue, Oct 9, 2012 at 12:01 PM, Ming Lei wrote: > Hi, > > The first two are fixes' patch, the 3rd one is to enable > caching firmware for direct loading, and the last one is > a cleanup patch. > > drivers/base/firmware_class.c | 266 > +++-- > 1 file changed, 151 insertions(+), 115 deletions(-) Hi Greg, Could you push the patchset or at least the first 3 fix patches onto 3.7-rc? BTW: 3/4 is still a fix, since linus's direct loading breaks firmware cache which has been used by some drivers(such as: ath9k) Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] char_dev: allow setting up and pinning parent devices
On Sun, Oct 21, 2012 at 08:39:28AM +0100, Al Viro wrote: > On Sun, Oct 21, 2012 at 12:24:30AM -0700, Dmitry Torokhov wrote: > > In certain cases (for example when a cdev structure is embedded into > > another object whose lifetime is controlled by a separate device object) > > it is beneficial to tie lifetime of another struct device to the lifetime > > of character device so that related object is not freed until after > > char_dev object is freed. To achieve this allow setting a "parent" device > > for character devices and pin them when doing cdev_add() and unpin when > > last reference to cdev structure is being released. > > Why struct device and not simply struct kobject? It was more convenient for my uses and I also think that parents of character devices will be struct devices... I however will not insist and if you prefer using more generic kobject I can change it, Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: question about context switch on arm Linux
于 2012年10月21日 15:44, Richard Cochran 写道: On Sun, Oct 21, 2012 at 02:02:42PM +0800, caiyuqing wrote: hi, all. I have some questions about context switch on arm Linux (my target is ARMv7-a). 1. Does arm linux support FCSE to handle the context switch? No, mainline Linux does not support FCSE. However, you can use Gilles' unoffical (but working) FCSE branches at http://git.xenomai.org/?p=ipipe-gch.git;a=summary 2. If using FCSE, that means the processes number limit is 128 and the memory limit is 32MB per process, is that right? Yes and no. Gilles' patches offer a "strict mode" and a "best effort" mode. The strict mode does have the limitation, but the best effort mode does not. HTH, Richard Richard, thanks for your reply. mainline Linux doesn't support FCSE, if so, when kernel switch a process to another(these two process share the same virtual memory space), that means the vitrual-to-physical address should be remaped, TLB shuold be invalid, CACHE should be flushed, right? qing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH] ALSA: snd-usb: remove unused variable in init_pitch_v2()
At Thu, 18 Oct 2012 22:46:23 +0800,
Wei Yongjun wrote:
>
> From: Wei Yongjun
>
> The variable ep is initialized but never used
> otherwise, so remove the unused variable.
>
> dpatch engine is used to auto generate this patch.
> (https://github.com/weiyj/dpatch)
>
> Signed-off-by: Wei Yongjun
Thanks, applied now.
Takashi
> ---
> sound/usb/pcm.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
> index 55e19e1..f77b87a 100644
> --- a/sound/usb/pcm.c
> +++ b/sound/usb/pcm.c
> @@ -171,11 +171,8 @@ static int init_pitch_v2(struct snd_usb_audio *chip, int
> iface,
> {
> struct usb_device *dev = chip->dev;
> unsigned char data[1];
> - unsigned int ep;
> int err;
>
> - ep = get_endpoint(alts, 0)->bEndpointAddress;
> -
> data[0] = 1;
> if ((err = snd_usb_ctl_msg(dev, usb_sndctrlpipe(dev, 0), UAC2_CS_CUR,
> USB_TYPE_CLASS | USB_RECIP_ENDPOINT |
> USB_DIR_OUT,
>
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On 21.10.2012, Marcin Slusarz wrote: > On 3.6 kernel? (It doesn't exist on 3.7) > Note that it may be in other directory than "0". [root@wildsau linux-3.6.2]# cat .config | grep -i "nouveau" CONFIG_DRM_NOUVEAU=m CONFIG_DRM_NOUVEAU_BACKLIGHT=y CONFIG_DRM_NOUVEAU_DEBUG=y I grepped the whole disk, there's no vbios.rom at all. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] drm: fb: cma: Fail gracefully on allocation failure
On Sat, Oct 20, 2012 at 12:32:47PM +0200, Thierry Reding wrote: > The drm_gem_cma_create() function never returns NULL but rather an error > encoded in the return value using the ERR_PTR() macro. Callers therefore > need to check for errors using the IS_ERR() macro. This change allows > drivers to handle contiguous DMA allocation failures gracefully. > > Signed-off-by: Thierry Reding Acked-by: Sascha Hauer Sascha > --- > drivers/gpu/drm/drm_fb_cma_helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c > b/drivers/gpu/drm/drm_fb_cma_helper.c > index d6c80a3..fd9d0af 100644 > --- a/drivers/gpu/drm/drm_fb_cma_helper.c > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c > @@ -220,7 +220,7 @@ static int drm_fbdev_cma_create(struct drm_fb_helper > *helper, > > size = mode_cmd.pitches[0] * mode_cmd.height; > obj = drm_gem_cma_create(dev, size); > - if (!obj) > + if (IS_ERR(obj)) > return -ENOMEM; > > fbi = framebuffer_alloc(0, dev->dev); > -- > 1.7.12.4 > > -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Initial report on F2FS filesystem performance
On Oct 20, 2012, at 11:22 PM, Pavel Machek wrote: > On Tue 2012-10-16 13:07:03, Sooman Jeong wrote: >> >> This is a brief summary of our initial filesystem performance study of f2fs >> against existing two filesystems in linux: EXT4, NILFS2, and f2fs. >> > > Hmm, flashes are actually optimized for VFAT, right? Can you compare > against that? > Do you mean SD-cards? Because, as I can understand, "raw" flash (I mean NAND chip) hasn't any special filesystem-related optimization. Moreover, as I know, this optimization takes place in the begin of device (because FAT metadata is placed in the volume's begin). But if you have several partition on a device then you haven't any optimizations for second and next FAT partitions. So, in-place modified metadata of f2fs is placed in the begin of the volume also. Or, maybe, do you mean some another special optimization for VFAT? > What about something more complex like "untar of kernel tree"? > Yes, it is very interesting use-case. Maybe, kernel compilation can be complimentary synthetic benchmark. :-) With the best regards, Vyacheslav Dubeyko. > Ouch and... thanks for doing this. > Pavel > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On 21.10.2012, Paweł Sikora wrote: > with these both patches applied my laptop boots and gui works fine. The same here. The two patches together, applied to 3.7-rc1 let my machine boot again. Here's the relevant dmesg cut: [3.702671] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1 [3.704643] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8) [3.707003] nouveau [ DEVICE][:01:00.0] Family : NV50 [3.711393] nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... [3.712793] nouveau [ VBIOS][:01:00.0] ... signature not found [3.714147] nouveau [ VBIOS][:01:00.0] checking PROM for image... [3.715578] nouveau [ VBIOS][:01:00.0] ... signature not found [3.716969] nouveau [ VBIOS][:01:00.0] checking ACPI for image... [4.207512] nouveau [ VBIOS][:01:00.0] ... appears to be valid [4.209711] nouveau [ VBIOS][:01:00.0] using image from ACPI [4.212469] nouveau [ VBIOS][:01:00.0] BIT signature found [4.214855] nouveau [ VBIOS][:01:00.0] version 70.18.5d.00 [4.217554] nouveau [ DEVINIT][:01:00.0] adaptor not initialised [4.219922] nouveau [ VBIOS][:01:00.0] running init tables [4.342202] nouveau [ MXM][:01:00.0] no VBIOS data, nothing to do [4.343590] nouveau [ PFB][:01:00.0] RAM type: DDR3 [4.344916] nouveau [ PFB][:01:00.0] RAM size: 1024 MiB [4.991887] vga_switcheroo: enabled [4.993495] [TTM] Zone kernel: Available graphics memory: 1917720 kiB [4.994911] [TTM] Initializing pool allocator [4.996228] [TTM] Initializing DMA pool allocator [4.998915] nouveau [ DRM] VRAM: 1024 MiB [5.000251] nouveau [ DRM] GART: 512 MiB [5.001579] nouveau [ DRM] BIT BIOS found [5.002904] nouveau [ DRM] Bios version 70.18.5d.00 [5.004229] nouveau [ DRM] TMDS table version 2.0 [5.005545] nouveau [ DRM] DCB version 4.0 [5.006810] nouveau [ DRM] DCB outp 00: 02014300 [5.008115] nouveau [ DRM] DCB conn 00: 0040 [5.009441] nouveau [ DRM] DCB conn 01: 00410146 [5.010745] nouveau [ DRM] DCB conn 02: 1261 [5.012019] nouveau [ DRM] DCB conn 03: 2330 [5.013255] nouveau [ DRM] DCB conn 04: 0400 [5.014452] nouveau [ DRM] DCB conn 05: 0560 [5.052344] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [5.053486] [drm] No driver support for vblank timestamp query. [5.054590] nouveau [ DRM] ACPI backlight interface available,not registering our own [5.356822] nouveau [ DRM] 3 available performance level(s) [5.358682] nouveau [ DRM] 0: core 135MHz shader 270MHz memory 135MHz voltage 850mV [5.360442] nouveau [ DRM] 1: core 405MHz shader 810MHz memory 405MHz voltage 850mV [5.362215] nouveau [ DRM] 3: core 606MHz shader 1468MHz memory 667MHz voltage 1000mV [5.363998] nouveau [ DRM] c: core 405MHz shader 810MHz memory 405MHz [5.404143] nouveau [ DRM] MM: using COPY for buffer copies [5.481593] No connectors reported connected with modes [5.482667] [drm] Cannot find any crtc or sizes - going 1024x768 [5.517932] nouveau [ DRM] allocated 1024x768 fb: 0x7, bo 88013a6d3400 [5.519236] fb1: nouveaufb frame buffer device [5.520368] [drm] Initialized nouveau 1.1.0 20120801 for :01:00.0 on minor 1 [5.527378] dracut: Starting plymouth daemon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kvm, async_pf: exit idleness when handling KVM_PV_REASON_PAGE_NOT_PRESENT
On Fri, Oct 19, 2012 at 12:11:55PM -0400, Sasha Levin wrote:
> KVM_PV_REASON_PAGE_NOT_PRESENT kicks cpu out of idleness, but we haven't
> marked that spot as an exit from idleness.
>
> Not doing so can cause RCU warnings such as:
>
> [ 732.788386] ===
> [ 732.789803] [ INFO: suspicious RCU usage. ]
> [ 732.790032] 3.7.0-rc1-next-20121019-sasha-2-g6d8d02d-dirty #63
> Tainted: GW
> [ 732.790032] ---
> [ 732.790032] include/linux/rcupdate.h:738 rcu_read_lock() used illegally
> while idle!
> [ 732.790032]
> [ 732.790032] other info that might help us debug this:
> [ 732.790032]
> [ 732.790032]
> [ 732.790032] RCU used illegally from idle CPU!
> [ 732.790032] rcu_scheduler_active = 1, debug_locks = 1
> [ 732.790032] RCU used illegally from extended quiescent state!
> [ 732.790032] 2 locks held by trinity-child31/8252:
> [ 732.790032] #0: (&rq->lock){-.-.-.}, at: []
> __schedule+0x178/0x8f0
> [ 732.790032] #1: (rcu_read_lock){.+.+..}, at: []
> cpuacct_charge+0xe/0x200
> [ 732.790032]
> [ 732.790032] stack backtrace:
> [ 732.790032] Pid: 8252, comm: trinity-child31 Tainted: GW
> 3.7.0-rc1-next-20121019-sasha-2-g6d8d02d-dirty #63
> [ 732.790032] Call Trace:
> [ 732.790032] [] lockdep_rcu_suspicious+0x10b/0x120
> [ 732.790032] [] cpuacct_charge+0x90/0x200
> [ 732.790032] [] ? cpuacct_charge+0xe/0x200
> [ 732.790032] [] update_curr+0x1a3/0x270
> [ 732.790032] [] dequeue_entity+0x2a/0x210
> [ 732.790032] [] dequeue_task_fair+0x45/0x130
> [ 732.790032] [] dequeue_task+0x89/0xa0
> [ 732.790032] [] deactivate_task+0x1e/0x20
> [ 732.790032] [] __schedule+0x879/0x8f0
> [ 732.790032] [] ? trace_hardirqs_off+0xd/0x10
> [ 732.790032] [] ? kvm_async_pf_task_wait+0x1d5/0x2b0
> [ 732.790032] [] schedule+0x55/0x60
> [ 732.790032] [] kvm_async_pf_task_wait+0x1f4/0x2b0
> [ 732.790032] [] ? abort_exclusive_wait+0xb0/0xb0
> [ 732.790032] [] ? prepare_to_wait+0x25/0x90
> [ 732.790032] [] do_async_page_fault+0x56/0xa0
> [ 732.790032] [] async_page_fault+0x28/0x30
>
> Signed-off-by: Sasha Levin
Acked-by: Gleb Natapov
> ---
> arch/x86/kernel/kvm.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index b3e5e51..4180a87 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -247,7 +247,10 @@ do_async_page_fault(struct pt_regs *regs, unsigned long
> error_code)
> break;
> case KVM_PV_REASON_PAGE_NOT_PRESENT:
> /* page is swapped out by the host. */
> + rcu_irq_enter();
> + exit_idle();
> kvm_async_pf_task_wait((u32)read_cr2());
> + rcu_irq_exit();
> break;
> case KVM_PV_REASON_PAGE_READY:
> rcu_irq_enter();
> --
> 1.7.12.3
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] menuconfig: Replace CIRCLEQ by list_head-style lists.
From: Benjamin Poirier
sys/queue.h and CIRCLEQ in particular have proven to cause portability
problems (reported on Debian Sarge, Cygwin and FreeBSD)
Reported-by: Tetsuo Handa
Tested-by: Tetsuo Handa
Tested-by: Yaakov Selkowitz
Signed-off-by: Benjamin Poirier
Signed-off-by: "Yann E. MORIN"
---
Changes v1-v2:
* integrate the patch/suggestion from Yann to fix problems related to the
usage of list.h with xconfig/c++
* "new" keyword
* offsetof redefinition
* silly #endif placement mistake
Thanks to Tetsuo, Yann and Yaakov for thorough testing.
scripts/kconfig/expr.h |5 +--
scripts/kconfig/list.h | 91 +++
scripts/kconfig/lkc_proto.h |4 +-
scripts/kconfig/mconf.c |6 +--
scripts/kconfig/menu.c | 14 ---
5 files changed, 106 insertions(+), 14 deletions(-)
create mode 100644 scripts/kconfig/list.h
diff --git a/scripts/kconfig/expr.h b/scripts/kconfig/expr.h
index bd2e098..cdd4860 100644
--- a/scripts/kconfig/expr.h
+++ b/scripts/kconfig/expr.h
@@ -12,7 +12,7 @@ extern "C" {
#include
#include
-#include
+#include "list.h"
#ifndef __cplusplus
#include
#endif
@@ -175,12 +175,11 @@ struct menu {
#define MENU_ROOT 0x0002
struct jump_key {
- CIRCLEQ_ENTRY(jump_key) entries;
+ struct list_head entries;
size_t offset;
struct menu *target;
int index;
};
-CIRCLEQ_HEAD(jk_head, jump_key);
#define JUMP_NB9
diff --git a/scripts/kconfig/list.h b/scripts/kconfig/list.h
new file mode 100644
index 000..0ae730b
--- /dev/null
+++ b/scripts/kconfig/list.h
@@ -0,0 +1,91 @@
+#ifndef LIST_H
+#define LIST_H
+
+/*
+ * Copied from include/linux/...
+ */
+
+#undef offsetof
+#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
+
+/**
+ * container_of - cast a member of a structure out to the containing structure
+ * @ptr:the pointer to the member.
+ * @type: the type of the container struct this is embedded in.
+ * @member: the name of the member within the struct.
+ *
+ */
+#define container_of(ptr, type, member) ({ \
+ const typeof( ((type *)0)->member ) *__mptr = (ptr);\
+ (type *)( (char *)__mptr - offsetof(type,member) );})
+
+
+struct list_head {
+ struct list_head *next, *prev;
+};
+
+
+#define LIST_HEAD_INIT(name) { &(name), &(name) }
+
+#define LIST_HEAD(name) \
+ struct list_head name = LIST_HEAD_INIT(name)
+
+/**
+ * list_entry - get the struct for this entry
+ * @ptr: the &struct list_head pointer.
+ * @type: the type of the struct this is embedded in.
+ * @member:the name of the list_struct within the struct.
+ */
+#define list_entry(ptr, type, member) \
+ container_of(ptr, type, member)
+
+/**
+ * list_for_each_entry - iterate over list of given type
+ * @pos: the type * to use as a loop cursor.
+ * @head: the head for your list.
+ * @member:the name of the list_struct within the struct.
+ */
+#define list_for_each_entry(pos, head, member) \
+ for (pos = list_entry((head)->next, typeof(*pos), member); \
+&pos->member != (head);\
+pos = list_entry(pos->member.next, typeof(*pos), member))
+
+/**
+ * list_empty - tests whether a list is empty
+ * @head: the list to test.
+ */
+static inline int list_empty(const struct list_head *head)
+{
+ return head->next == head;
+}
+
+/*
+ * Insert a new entry between two known consecutive entries.
+ *
+ * This is only for internal list manipulation where we know
+ * the prev/next entries already!
+ */
+static inline void __list_add(struct list_head *_new,
+ struct list_head *prev,
+ struct list_head *next)
+{
+ next->prev = _new;
+ _new->next = next;
+ _new->prev = prev;
+ prev->next = _new;
+}
+
+/**
+ * list_add_tail - add a new entry
+ * @new: new entry to be added
+ * @head: list head to add it before
+ *
+ * Insert a new entry before the specified head.
+ * This is useful for implementing queues.
+ */
+static inline void list_add_tail(struct list_head *_new, struct list_head
*head)
+{
+ __list_add(_new, head->prev, head);
+}
+
+#endif
diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index 1d1c085..ef1a738 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -21,9 +21,9 @@ P(menu_get_root_menu,struct menu *,(struct menu *menu));
P(menu_get_parent_menu,struct menu *,(struct menu *menu));
P(menu_has_help,bool,(struct menu *menu));
P(menu_get_help,const char *,(struct menu *menu));
-P(get_symbol_str, void, (struct gstr *r, struct symbol *sym, struct jk_head
+P(get_symbol_str, void, (struct gstr *r, struct symbol *sym, struct list_head
*head));
-P(get_relations_str, struct gstr, (struct symbol **sym_arr, struct jk_head
+P(get_relations_str, s
Re: [dm-crypt] cryptsetup not working under 3.6 - regression from 3.4?
On 10/20/2012 10:44 PM, Tvrtko Ursulin wrote: > But I repeat, even if I load the required modules before hand things do > not work. I would say you are still missing some modules. > Kernel says this: > device-mapper: table: 252:1: crypt: Error allocating crypto tfm > device-mapper: ioctl: error adding target to table It complains about aes-cbc-essiv:sha256. It can be missing CBC od SHA256, but according the message I bet you have no "cbc" block cipher mode module compiled. Can you grep your final .config for CONFIG_CRYPTO_CBC and CONFIG_CRYPTO_SHA256 a paste it here? Milan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] Thermal: do bind operation after thermal zone or cooling device register returns.
Hi, On 10/16/2012 01:44 PM, hongbo.zhang wrote: > From: "hongbo.zhang" > > In the previous bind function, cdev->get_max_state(cdev, &max_state) is called > before the registration function finishes, but at this moment, the parameter > cdev at thermal driver layer isn't ready--it will get ready only after its > registration, so the the get_max_state callback cannot tell the max_state > according to the cdev input. > This problem can be fixed by separating the bind operation out of registration > and doing it when registration completely finished. When thermal_cooling_device_register() is called, the thermal framework assumes the cooling device is "ready", i.e. all of its ops callbacks return meaningful results. If the cooling device is not ready at this point, then this is a bug in the code that registers it. Specifically, the faulty code in your case is in the cpufreq cooling implementation, where the cooling device is registered before being added to the internal list of cpufreq cooling devices. So, IMHO the fix is needed there. -- Francesco -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Initial report on F2FS filesystem performance
Hi! > >> This is a brief summary of our initial filesystem performance study of > >> f2fs against existing two filesystems in linux: EXT4, NILFS2, and f2fs. > >> > > > > Hmm, flashes are actually optimized for VFAT, right? Can you compare > > against that? > > > > Do you mean SD-cards? Because, as I can understand, "raw" flash (I mean NAND > chip) hasn't any special filesystem-related optimization. Moreover, as I > know, this optimization takes place in the begin of device (because FAT > metadata is placed in the volume's begin). But if you have several partition > on a device then you haven't any optimizations for second and next FAT > partitions. So, in-place modified metadata of f2fs is placed in the begin of > the volume also. > > Or, maybe, do you mean some another special optimization for VFAT? > I meant SD-card, sorry. Compare factory-formatted VFAT on SD card with f2fs running on the same partition. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On 21.10.2012 01:15, Artem S. Tashkinov wrote: > You don't get me - I have *no* VirtualBox (or any proprietary) modules running > - but I can reproduce this problem using *the same system running under* > VirtualBox > in Windows 7 64. > > It's almost definitely either a USB driver bug or video4linux driver bug: > > I'm CC'ing linux-media and linux-usb mailing lists, the problem is described > here: > https://lkml.org/lkml/2012/10/20/35 > https://lkml.org/lkml/2012/10/20/148 > > Here are the last lines from my dmesg (with usbmon loaded): > > [ 292.164833] hub 1-0:1.0: state 7 ports 8 chg evt 0002 > [ 292.168091] ehci_hcd :00:1f.5: GetStatus port:1 status 00100a 0 ACK > POWER sig=se0 PEC CSC > [ 292.172063] hub 1-0:1.0: port 1, status 0100, change 0003, 12 Mb/s > [ 292.174883] usb 1-1: USB disconnect, device number 2 > [ 292.178045] usb 1-1: unregistering device > [ 292.183539] usb 1-1: unregistering interface 1-1:1.0 > [ 292.197034] usb 1-1: unregistering interface 1-1:1.1 > [ 292.204317] usb 1-1: unregistering interface 1-1:1.2 > [ 292.234519] usb 1-1: unregistering interface 1-1:1.3 > [ 292.236175] usb 1-1: usb_disable_device nuking all URBs > [ 292.364429] hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status > 0x100 > [ 294.364279] hub 1-0:1.0: hub_suspend > [ 294.366045] usb usb1: bus auto-suspend, wakeup 1 > [ 294.367375] ehci_hcd :00:1f.5: suspend root hub > [ 296.501084] usb usb1: usb wakeup-resume > [ 296.508311] usb usb1: usb auto-resume > [ 296.509833] ehci_hcd :00:1f.5: resume root hub > [ 296.560149] hub 1-0:1.0: hub_resume > [ 296.562240] ehci_hcd :00:1f.5: GetStatus port:1 status 001003 0 ACK > POWER sig=se0 CSC CONNECT > [ 296.566141] hub 1-0:1.0: port 1: status 0501 change 0001 > [ 296.670413] hub 1-0:1.0: state 7 ports 8 chg 0002 evt > [ 296.673222] hub 1-0:1.0: port 1, status 0501, change , 480 Mb/s > [ 297.311720] usb 1-1: new high-speed USB device number 3 using ehci_hcd > [ 300.547237] usb 1-1: skipped 1 descriptor after configuration > [ 300.549443] usb 1-1: skipped 4 descriptors after interface > [ 300.552273] usb 1-1: skipped 2 descriptors after interface > [ 300.556499] usb 1-1: skipped 1 descriptor after endpoint > [ 300.559392] usb 1-1: skipped 2 descriptors after interface > [ 300.560960] usb 1-1: skipped 1 descriptor after endpoint > [ 300.562169] usb 1-1: skipped 2 descriptors after interface > [ 300.563440] usb 1-1: skipped 1 descriptor after endpoint > [ 300.564639] usb 1-1: skipped 2 descriptors after interface > [ 300.565828] usb 1-1: skipped 2 descriptors after endpoint > [ 300.567084] usb 1-1: skipped 9 descriptors after interface > [ 300.569205] usb 1-1: skipped 1 descriptor after endpoint > [ 300.570484] usb 1-1: skipped 53 descriptors after interface > [ 300.595843] usb 1-1: default language 0x0409 > [ 300.602503] usb 1-1: USB interface quirks for this device: 2 > [ 300.605700] usb 1-1: udev 3, busnum 1, minor = 2 > [ 300.606959] usb 1-1: New USB device found, idVendor=046d, idProduct=081d > [ 300.610298] usb 1-1: New USB device strings: Mfr=0, Product=0, > SerialNumber=1 > [ 300.613742] usb 1-1: SerialNumber: 48C5D2B0 > [ 300.617703] usb 1-1: usb_probe_device > [ 300.620594] usb 1-1: configuration #1 chosen from 1 choice > [ 300.639218] usb 1-1: adding 1-1:1.0 (config #1, interface 0) > [ 300.640736] snd-usb-audio 1-1:1.0: usb_probe_interface > [ 300.642307] snd-usb-audio 1-1:1.0: usb_probe_interface - got id > [ 301.050296] usb 1-1: adding 1-1:1.1 (config #1, interface 1) > [ 301.054897] usb 1-1: adding 1-1:1.2 (config #1, interface 2) > [ 301.056934] uvcvideo 1-1:1.2: usb_probe_interface > [ 301.058072] uvcvideo 1-1:1.2: usb_probe_interface - got id > [ 301.059395] uvcvideo: Found UVC 1.00 device (046d:081d) > [ 301.090173] input: UVC Camera (046d:081d) as > /devices/pci:00/:00:1f.5/usb1/1-1/1-1:1.2/input/input7 That seems to be a Logitech model. > [ 301.111289] usb 1-1: adding 1-1:1.3 (config #1, interface 3) > [ 301.131207] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us] > [ 301.137066] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us] > [ 301.156451] ehci_hcd :00:1f.5: reused qh f48d64c0 schedule > [ 301.158310] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us] > [ 301.160238] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us] > [ 301.196606] set resolution quirk: cval->res = 384 > [ 371.309569] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: RX > [ 390.729568] ehci_hcd :00:1f.5: reused qh f48d64c0 schedule > f5ade900 2296555[ 390.730023] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 > us] > 437 S Ii:1:003:7[ 390.736394] usb 1-1: unlink qh16-0001/f48d64c0 start 2 > [1/0 us] > -115:128 16 < > f5ade900 2296566256 C Ii:1:003:7 -2:128 0 > [ 391.100896] ehci_hcd :00:1f.5: reused qh f48d64c0 schedule > [ 391.103188] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us] > f5ade900 2296926929 S Ii:1:003:7[
Re: [PATCH 2/9] Staging: winbond: phy_calibration: Fixed coding style issue
On Fri 2012-10-12 09:53:19, Joe Perches wrote: > On Fri, 2012-10-12 at 22:07 +0530, Adil Mujeeb wrote: > > Removed checkpatch.pl script reported ERRORs > [] > > diff --git a/linux-3.6-rc7/drivers/staging/winbond/phy_calibration.c > > b/linux-3.6-rc7/drivers/staging/winbond/phy_calibration.c > [] > > -#define AG_CONST0.6072529350 > > +#define AG_CONST(0.6072529350) > > That one is unnecessary. > checkpatch is defective here. Agreed. > I wonder why there is any floating point > in the code at all though. Some kind of signal strength computations. I'm not an wifi expert... :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/9] Staging: winbond: wb35reg: Fixed coding style issues
On Fri 2012-10-12 22:07:11, Adil Mujeeb wrote:
> Fixed some of checkpatch.pl reported ERRORs and WARNING of similar types:
> 1. trailing statements should be on next line
> 2. no spaces at the start of a line
>
> Signed-off-by: Adil Mujeeb
NAK. This makes it worse, not better. The code is simple enough. That
making it longer makes it unreadable.
Pavel
> void Wb35Reg_Update(struct hw_data *pHwData, u16 RegisterNo, u32
> RegisterValue)
> {
> struct wb35_reg *reg = &pHwData->reg;
> switch (RegisterNo) {
> - case 0x3b0: reg->U1B0 = RegisterValue; break;
> - case 0x3bc: reg->U1BC_LEDConfigure = RegisterValue; break;
> - case 0x400: reg->D00_DmaControl = RegisterValue; break;
> - case 0x800: reg->M00_MacControl = RegisterValue; break;
> - case 0x804: reg->M04_MulticastAddress1 = RegisterValue; break;
> - case 0x808: reg->M08_MulticastAddress2 = RegisterValue; break;
> - case 0x824: reg->M24_MacControl = RegisterValue; break;
> - case 0x828: reg->M28_MacControl = RegisterValue; break;
> - case 0x82c: reg->M2C_MacControl = RegisterValue; break;
> - case 0x838: reg->M38_MacControl = RegisterValue; break;
> - case 0x840: reg->M40_MacControl = RegisterValue; break;
> - case 0x844: reg->M44_MacControl = RegisterValue; break;
> - case 0x848: reg->M48_MacControl = RegisterValue; break;
> - case 0x84c: reg->M4C_MacStatus = RegisterValue; break;
> - case 0x860: reg->M60_MacControl = RegisterValue; break;
> - case 0x868: reg->M68_MacControl = RegisterValue; break;
> - case 0x870: reg->M70_MacControl = RegisterValue; break;
> - case 0x874: reg->M74_MacControl = RegisterValue; break;
> - case 0x878: reg->M78_ERPInformation = RegisterValue; break;
> - case 0x87C: reg->M7C_MacControl = RegisterValue; break;
> - case 0x880: reg->M80_MacControl = RegisterValue; break;
> - case 0x884: reg->M84_MacControl = RegisterValue; break;
> - case 0x888: reg->M88_MacControl = RegisterValue; break;
> - case 0x898: reg->M98_MacControl = RegisterValue; break;
> - case 0x100c: reg->BB0C = RegisterValue; break;
> - case 0x102c: reg->BB2C = RegisterValue; break;
> - case 0x1030: reg->BB30 = RegisterValue; break;
> - case 0x103c: reg->BB3C = RegisterValue; break;
> - case 0x1048: reg->BB48 = RegisterValue; break;
> - case 0x104c: reg->BB4C = RegisterValue; break;
> - case 0x1050: reg->BB50 = RegisterValue; break;
> - case 0x1054: reg->BB54 = RegisterValue; break;
> - case 0x1058: reg->BB58 = RegisterValue; break;
> - case 0x105c: reg->BB5C = RegisterValue; break;
> - case 0x1060: reg->BB60 = RegisterValue; break;
> + case 0x3b0:
> + reg->U1B0 = RegisterValue;
> + break;
> + case 0x3bc:
> + reg->U1BC_LEDConfigure = RegisterValue;
> + break;
> + case 0x400:
> + reg->D00_DmaControl = RegisterValue;
> + break;
> + case 0x800:
> + reg->M00_MacControl = RegisterValue;
> + break;
> + case 0x804:
> + reg->M04_MulticastAddress1 = RegisterValue;
> + break;
> + case 0x808:
> + reg->M08_MulticastAddress2 = RegisterValue;
> + break;
> + case 0x824:
> + reg->M24_MacControl = RegisterValue;
> + break;
> + case 0x828:
> + reg->M28_MacControl = RegisterValue;
> + break;
> + case 0x82c:
> + reg->M2C_MacControl = RegisterValue;
> + break;
> + case 0x838:
> + reg->M38_MacControl = RegisterValue;
> + break;
> + case 0x840:
> + reg->M40_MacControl = RegisterValue;
> + break;
> + case 0x844:
> + reg->M44_MacControl = RegisterValue;
> + break;
> + case 0x848:
> + reg->M48_MacControl = RegisterValue;
> + break;
> + case 0x84c:
> + reg->M4C_MacStatus = RegisterValue;
> + break;
> + case 0x860:
> + reg->M60_MacControl = RegisterValue;
> + break;
> + case 0x868:
> + reg->M68_MacControl = RegisterValue;
> + break;
> + case 0x870:
> + reg->M70_MacControl = RegisterValue;
> + break;
> + case 0x874:
> + reg->M74_MacControl = RegisterValue;
> + break;
> + case 0x878:
> + reg->M78_ERPInformation = RegisterValue;
> + break;
> + case 0x87C:
> + reg->M7C_MacControl = RegisterValue;
> + break;
> + case 0x880:
> + reg->M80_MacControl = RegisterValue;
> + break;
> + case 0x884:
> + reg->M84_MacControl = RegisterValue;
> + break;
> + case 0x888:
> + reg->M88_MacControl = RegisterValue;
> + break;
> + case 0x898:
> +
Re: [PATCH 0/9] Staging: winbond: Fixed coding style issues
On Fri 2012-10-12 22:07:06, Adil Mujeeb wrote: > > winbond directory files have lots of coding style issues. The patch set tries to remove *most* (if not all) of the coding style issues. checkpatch.pl script is still complaining (like 80 characters limit) but major part of the serious coding style issues have been rectified. ACK on patches except 2 and 5. Plus if you could keep the printks, that would be great. When the driver is debugged and in wide use, we can remove them, but now they are useful... Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] eliminate possible double free
These patches fix cases where a called function frees some data and the
calling context frees the same data.
The complete semantic match is as follows: (http://coccinelle.lip6.fr/)
//
@r exists@
parameter list[n] ps;
type T;
identifier a;
expression e;
expression ret != 0;
identifier f,free;
position p1;
@@
f(ps,T a,...) {
... when any
when != a = e
if(...) { ... free@p1(a); ... return ret; }
... when any
}
@s exists@
identifier r.f,r.free;
expression x,a;
position p2,p3;
expression list[r.n] xs;
@@
x = f@p2(xs,a,...);
if (...) { ... free@p3(a); ... return ...; }
@script:python@
p1 << r.p1;
p2 << s.p2;
p3 << s.p3;
@@
cocci.print_main("",p1)
cocci.print_secs("",p2)
cocci.print_secs("",p3)
//
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] drivers/iio/industrialio-event.c: eliminate possible double free
From: Julia Lawall
The function __iio_add_event_config_attrs is only called once, by the
function iio_device_register_eventset. If the call fails,
iio_device_register_eventset calls __iio_remove_event_config_attrs. There
is thus no need for __iio_add_event_config_attrs to also call
__iio_remove_event_config_attrs on failure.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@r@
identifier f,free,a;
parameter list[n] ps;
type T;
expression e;
@@
f(ps,T a,...) {
... when any
when != a = e
if(...) { ... free(a); ... return ...; }
... when any
}
@@
identifier r.f,r.free;
expression x,a;
expression list[r.n] xs;
@@
* x = f(xs,a,...);
if (...) { ... free(a); ... return ...; }
//
Signed-off-by: Julia Lawall
---
__iio_remove_event_config_attrs kfrees the elements of a list, but doesn't
actually remove them from the list. Perhaps for safety this should be
cleaned up as well. Not tested.
drivers/iio/industrialio-event.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/iio/industrialio-event.c b/drivers/iio/industrialio-event.c
index fa6543b..78570c7 100644
--- a/drivers/iio/industrialio-event.c
+++ b/drivers/iio/industrialio-event.c
@@ -350,15 +350,10 @@ static inline int __iio_add_event_config_attrs(struct
iio_dev *indio_dev)
ret = iio_device_add_event_sysfs(indio_dev,
&indio_dev->channels[j]);
if (ret < 0)
- goto error_clear_attrs;
+ return ret;
attrcount += ret;
}
return attrcount;
-
-error_clear_attrs:
- __iio_remove_event_config_attrs(indio_dev);
-
- return ret;
}
static bool iio_check_for_dynamic_events(struct iio_dev *indio_dev)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] sound/isa/opti9xx/miro.c: eliminate possible double free
From: Julia Lawall
snd_miro_probe is a static function that is only called twice in the file
that defines it. At each call site, its argument is freed using
snd_card_free. Thus, there is no need for snd_miro_probe to call
snd_card_free on its argument on any of its error exit paths.
Because snd_card_free both reads the fields of its argument and kfrees its
argments, the results of the second snd_card_free should be unpredictable.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@r@
identifier f,free,a;
parameter list[n] ps;
type T;
expression e;
@@
f(ps,T a,...) {
... when any
when != a = e
if(...) { ... free(a); ... return ...; }
... when any
}
@@
identifier r.f,r.free;
expression x,a;
expression list[r.n] xs;
@@
* x = f(xs,a,...);
if (...) { ... free(a); ... return ...; }
//
Signed-off-by: Julia Lawall
---
Not tested.
sound/isa/opti9xx/miro.c |1 -
1 file changed, 1 deletion(-)
diff --git a/sound/isa/opti9xx/miro.c b/sound/isa/opti9xx/miro.c
index 3d1afb6..4a7ff4e 100644
--- a/sound/isa/opti9xx/miro.c
+++ b/sound/isa/opti9xx/miro.c
@@ -1286,7 +1286,6 @@ static int __devinit snd_miro_probe(struct snd_card *card)
error = snd_card_miro_aci_detect(card, miro);
if (error < 0) {
- snd_card_free(card);
snd_printk(KERN_ERR "unable to detect aci chip\n");
return -ENODEV;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] drivers/net/wireless/ti/wlcore/main.c: eliminate possible double power off
From: Julia Lawall
The function wl12xx_set_power_on is only called twice, once in
wl12xx_chip_wakeup and once in wl12xx_get_hw_info. On the failure of the
call in wl12xx_chip_wakeup, the containing function just returns, but on
the failure of the call in wl12xx_get_hw_info, the containing function
calls wl1271_power_off. This does not seem necessary, because if
wl12xx_set_power_on has set the power on and then fails, it has already
turned the power off.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@r@
identifier f,free,a;
parameter list[n] ps;
type T;
expression e;
@@
f(ps,T a,...) {
... when any
when != a = e
if(...) { ... free(a); ... return ...; }
... when any
}
@@
identifier r.f,r.free;
expression x,a;
expression list[r.n] xs;
@@
* x = f(xs,a,...);
if (...) { ... free(a); ... return ...; }
//
Signed-off-by: Julia Lawall
---
wl1271_power_off seems to be resistent to being called when the power is
not on, so this should not change the behavior. Not tested.
drivers/net/wireless/ti/wlcore/main.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wlcore/main.c
b/drivers/net/wireless/ti/wlcore/main.c
index 25530c8..0eb739b 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -5116,7 +5116,7 @@ static int wl12xx_get_hw_info(struct wl1271 *wl)
ret = wl12xx_set_power_on(wl);
if (ret < 0)
- goto out;
+ return ret;
ret = wlcore_read_reg(wl, REG_CHIP_ID_B, &wl->chip.id);
if (ret < 0)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] arch/powerpc/kernel/rtas_flash.c: eliminate possible double free
From: Julia Lawall
The function initialize_flash_pde_data is only called four times. All four
calls are in the function rtas_flash_init, and on the failure of any of the
calls, remove_flash_pde is called on the third argument of each of the
calls. There is thus no need for initialize_flash_pde_data to call
remove_flash_pde on the same argument. remove_flash_pde kfrees the data
field of its argument, and does not clear that field, so this amounts ot a
possible double free.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@r@
identifier f,free,a;
parameter list[n] ps;
type T;
expression e;
@@
f(ps,T a,...) {
... when any
when != a = e
if(...) { ... free(a); ... return ...; }
... when any
}
@@
identifier r.f,r.free;
expression x,a;
expression list[r.n] xs;
@@
* x = f(xs,a,...);
if (...) { ... free(a); ... return ...; }
//
Signed-off-by: Julia Lawall
---
Not tested.
arch/powerpc/kernel/rtas_flash.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/rtas_flash.c b/arch/powerpc/kernel/rtas_flash.c
index 20b0120..8329190 100644
--- a/arch/powerpc/kernel/rtas_flash.c
+++ b/arch/powerpc/kernel/rtas_flash.c
@@ -650,10 +650,8 @@ static int initialize_flash_pde_data(const char
*rtas_call_name,
int token;
dp->data = kzalloc(buf_size, GFP_KERNEL);
- if (dp->data == NULL) {
- remove_flash_pde(dp);
+ if (dp->data == NULL)
return -ENOMEM;
- }
/*
* This code assumes that the status int is the first member of the
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] ath6kl/wmi.c: eliminate possible double free
From: Julia Lawall
This makes two changes. In ath6kl_wmi_cmd_send, a call to dev_kfree_skb on
the skb argument is added to the initial sanity check to more completely
establish the invariant that ath6kl_wmi_cmd_send owns its skb argument.
Then, in ath6kl_wmi_sync_point, on failure of the call to
ath6kl_wmi_cmd_send, the clearing of the local skb variable is moved up, so
that the error-handling code at the end of the function does not free it
again.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@r@
identifier f,free,a;
parameter list[n] ps;
type T;
expression e;
@@
f(ps,T a,...) {
... when any
when != a = e
if(...) { ... free(a); ... return ...; }
... when any
}
@@
identifier r.f,r.free;
expression x,a;
expression list[r.n] xs;
@@
* x = f(xs,a,...);
if (...) { ... free(a); ... return ...; }
//
Signed-off-by: Julia Lawall
---
Not tested.
drivers/net/wireless/ath/ath6kl/wmi.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/wmi.c
b/drivers/net/wireless/ath/ath6kl/wmi.c
index c30ab4b..50f50e4 100644
--- a/drivers/net/wireless/ath/ath6kl/wmi.c
+++ b/drivers/net/wireless/ath/ath6kl/wmi.c
@@ -1677,8 +1677,10 @@ int ath6kl_wmi_cmd_send(struct wmi *wmi, u8 if_idx,
struct sk_buff *skb,
int ret;
u16 info1;
- if (WARN_ON(skb == NULL || (if_idx > (wmi->parent_dev->vif_max - 1
+ if (WARN_ON(skb == NULL || if_idx > (wmi->parent_dev->vif_max - 1))) {
+ dev_kfree_skb(skb);
return -EINVAL;
+ }
ath6kl_dbg(ATH6KL_DBG_WMI, "wmi tx id %d len %d flag %d\n",
cmd_id, skb->len, sync_flag);
@@ -2348,12 +2350,12 @@ static int ath6kl_wmi_sync_point(struct wmi *wmi, u8
if_idx)
ret = ath6kl_wmi_cmd_send(wmi, if_idx, skb, WMI_SYNCHRONIZE_CMDID,
NO_SYNC_WMIFLAG);
- if (ret)
- goto free_skb;
-
/* cmd buffer sent, we no longer own it */
skb = NULL;
+ if (ret)
+ goto free_skb;
+
for (index = 0; index < num_pri_streams; index++) {
if (WARN_ON(!data_sync_bufs[index].skb))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Linux KVM tool for v3.7-rc0
On Sun, Oct 21, 2012 at 01:07:31PM +1000, Dave Airlie wrote: > Why couldn't this script just be a wrapper around qemu It can be. Here is my ususual one: #!/bin/sh /opt/qemu/bin/qemu-system-x86_64 \ -m 1500 \ -enable-kvm \ -drive if=none,file=/home/hch/qemu-root.img,cache=none,id=root \ -device virtio-blk-pci,drive=root \ -append "root=/dev/vda console=tty0 console=ttyS0,38400n8 kgdboc=ttyS0,38400n8" \ -kernel arch/x86/boot/bzImage \ -nographic -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On Sun, Oct 21, 2012 at 01:57:21AM +, Artem S. Tashkinov wrote: > The freeze happens on my *host* Linux PC. For an experiment I decided > to check if I could reproduce the freeze under a virtual machine - it > turns out the Linux kernel running under it also freezes. I know that - but a freeze != oops - at least not necessarily. Which means it could very well be a different issue now that vbox is gone. Or, it could be the same issue with different incarnations: with vbox you get the corruptions and without it, you get the freezes. I'm assuming you do the same flash player thing in both cases? Here's a crazy idea: can you try to reproduce it in KVM? Thanks. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Linux KVM tool for v3.7-rc0
On Sun, Oct 21, 2012 at 01:07:31PM +1000, Dave Airlie wrote: > Why couldn't this script just be a wrapper around qemu? > > I get the kvm developers developing features that isn't ideal, but for > the quick boot a kernel tests, I don't see why a well maintained qemu > wrapper isn't superior. I hate constructing qemu command lines, but a > script in the kernel repo seems like a good idea. Well, Alex Graf had exactly that but I don't know what happened to it - I can't find it upstream at least. http://lists.gnu.org/archive/html/qemu-devel/2011-08/msg02728.html -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] Staging: winbond: Fixed coding style issues
Hi Pavel, On Sun, Oct 21, 2012 at 4:12 PM, Pavel Machek wrote: > On Fri 2012-10-12 22:07:06, Adil Mujeeb wrote: >> >> winbond directory files have lots of coding style issues. The patch > set tries to remove *most* (if not all) of the coding style > issues. checkpatch.pl script is still complaining (like 80 characters > limit) but major part of the serious coding style issues have been > rectified. > > ACK on patches except 2 and 5. Plus if you could keep the printks, > that would be great. When the driver is debugged and in wide use, we > can remove them, but now they are useful... Thanks Pavel for acknowledgement. I removed printk's as Joe and Greg recommended to remove "tracing" type debug calls. Let me know if I need to resubmit the patch. Regards, Adil > > Thanks, > Pavel > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Linux KVM tool for v3.7-rc0
On Sun, Oct 21, 2012 at 1:18 PM, Borislav Petkov wrote: > On Sun, Oct 21, 2012 at 01:07:31PM +1000, Dave Airlie wrote: >> Why couldn't this script just be a wrapper around qemu? >> >> I get the kvm developers developing features that isn't ideal, but for >> the quick boot a kernel tests, I don't see why a well maintained qemu >> wrapper isn't superior. I hate constructing qemu command lines, but a >> script in the kernel repo seems like a good idea. > > Well, Alex Graf had exactly that but I don't know what happened to it - > I can't find it upstream at least. > > http://lists.gnu.org/archive/html/qemu-devel/2011-08/msg02728.html Every kernel developer has his own wrapper script to make qemu usable. IMHO it's time to add such a script to the kernel tree. -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH resend] genalloc: stop crashing the system when destroying a pool
A gen_pool_chunk uses a bitmap to find what addresses ranges it has allocated and bugs when we destroy the pool and a chunk has some bits set. There is a problem when it allocates the bitmap. It allocates only the number of bytes needed for the bits that represent the size it's allocating. That is, if it needs 16 bits, it will allocate only 2 bytes, if it needs 31 bits, it will allocate 4 bytes. However, the bitops functions uses long types. And when the gen_pool_add allocates a bitmap, it only clears the bytes it has allocated. So, it's possible that we have a long word with the contents 0x, and only the first (most significant) bytes are cleared by memset. However, the destroy function is going to test for the least significant bits, which will not be clear as expected. Signed-off-by: Thadeu Lima de Souza Cascardo --- lib/genalloc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/genalloc.c b/lib/genalloc.c index ca208a9..5492043 100644 --- a/lib/genalloc.c +++ b/lib/genalloc.c @@ -178,7 +178,7 @@ int gen_pool_add_virt(struct gen_pool *pool, unsigned long virt, phys_addr_t phy struct gen_pool_chunk *chunk; int nbits = size >> pool->min_alloc_order; int nbytes = sizeof(struct gen_pool_chunk) + - (nbits + BITS_PER_BYTE - 1) / BITS_PER_BYTE; + BITS_TO_LONGS(nbits) * sizeof(long); chunk = kmalloc_node(nbytes, GFP_KERNEL | __GFP_ZERO, nid); if (unlikely(chunk == NULL)) -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dmaengine: imx-dma: fix missing unlock on error in imxdma_xfer_desc()
From: Wei Yongjun
Add the missing unlock on the error handling path in function
imxdma_xfer_desc().
Signed-off-by: Wei Yongjun
---
drivers/dma/imx-dma.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
index f11b5b2..7d9554c 100644
--- a/drivers/dma/imx-dma.c
+++ b/drivers/dma/imx-dma.c
@@ -474,8 +474,10 @@ static int imxdma_xfer_desc(struct imxdma_desc *d)
slot = i;
break;
}
- if (slot < 0)
+ if (slot < 0) {
+ spin_unlock_irqrestore(&imxdma->lock, flags);
return -EBUSY;
+ }
imxdma->slots_2d[slot].xsr = d->x;
imxdma->slots_2d[slot].ysr = d->y;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On 21.10.2012 12:34, Daniel Mack wrote: > On 21.10.2012 01:15, Artem S. Tashkinov wrote: >> You don't get me - I have *no* VirtualBox (or any proprietary) modules >> running >> - but I can reproduce this problem using *the same system running under* >> VirtualBox >> in Windows 7 64. >> >> It's almost definitely either a USB driver bug or video4linux driver bug: >> >> I'm CC'ing linux-media and linux-usb mailing lists, the problem is described >> here: >> https://lkml.org/lkml/2012/10/20/35 >> https://lkml.org/lkml/2012/10/20/148 >> >> Here are the last lines from my dmesg (with usbmon loaded): >> >> [ 292.164833] hub 1-0:1.0: state 7 ports 8 chg evt 0002 >> [ 292.168091] ehci_hcd :00:1f.5: GetStatus port:1 status 00100a 0 ACK >> POWER sig=se0 PEC CSC >> [ 292.172063] hub 1-0:1.0: port 1, status 0100, change 0003, 12 Mb/s >> [ 292.174883] usb 1-1: USB disconnect, device number 2 >> [ 292.178045] usb 1-1: unregistering device >> [ 292.183539] usb 1-1: unregistering interface 1-1:1.0 >> [ 292.197034] usb 1-1: unregistering interface 1-1:1.1 >> [ 292.204317] usb 1-1: unregistering interface 1-1:1.2 >> [ 292.234519] usb 1-1: unregistering interface 1-1:1.3 >> [ 292.236175] usb 1-1: usb_disable_device nuking all URBs >> [ 292.364429] hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms >> status 0x100 >> [ 294.364279] hub 1-0:1.0: hub_suspend >> [ 294.366045] usb usb1: bus auto-suspend, wakeup 1 >> [ 294.367375] ehci_hcd :00:1f.5: suspend root hub >> [ 296.501084] usb usb1: usb wakeup-resume >> [ 296.508311] usb usb1: usb auto-resume >> [ 296.509833] ehci_hcd :00:1f.5: resume root hub >> [ 296.560149] hub 1-0:1.0: hub_resume >> [ 296.562240] ehci_hcd :00:1f.5: GetStatus port:1 status 001003 0 ACK >> POWER sig=se0 CSC CONNECT >> [ 296.566141] hub 1-0:1.0: port 1: status 0501 change 0001 >> [ 296.670413] hub 1-0:1.0: state 7 ports 8 chg 0002 evt >> [ 296.673222] hub 1-0:1.0: port 1, status 0501, change , 480 Mb/s >> [ 297.311720] usb 1-1: new high-speed USB device number 3 using ehci_hcd >> [ 300.547237] usb 1-1: skipped 1 descriptor after configuration >> [ 300.549443] usb 1-1: skipped 4 descriptors after interface >> [ 300.552273] usb 1-1: skipped 2 descriptors after interface >> [ 300.556499] usb 1-1: skipped 1 descriptor after endpoint >> [ 300.559392] usb 1-1: skipped 2 descriptors after interface >> [ 300.560960] usb 1-1: skipped 1 descriptor after endpoint >> [ 300.562169] usb 1-1: skipped 2 descriptors after interface >> [ 300.563440] usb 1-1: skipped 1 descriptor after endpoint >> [ 300.564639] usb 1-1: skipped 2 descriptors after interface >> [ 300.565828] usb 1-1: skipped 2 descriptors after endpoint >> [ 300.567084] usb 1-1: skipped 9 descriptors after interface >> [ 300.569205] usb 1-1: skipped 1 descriptor after endpoint >> [ 300.570484] usb 1-1: skipped 53 descriptors after interface >> [ 300.595843] usb 1-1: default language 0x0409 >> [ 300.602503] usb 1-1: USB interface quirks for this device: 2 >> [ 300.605700] usb 1-1: udev 3, busnum 1, minor = 2 >> [ 300.606959] usb 1-1: New USB device found, idVendor=046d, idProduct=081d >> [ 300.610298] usb 1-1: New USB device strings: Mfr=0, Product=0, >> SerialNumber=1 >> [ 300.613742] usb 1-1: SerialNumber: 48C5D2B0 >> [ 300.617703] usb 1-1: usb_probe_device >> [ 300.620594] usb 1-1: configuration #1 chosen from 1 choice >> [ 300.639218] usb 1-1: adding 1-1:1.0 (config #1, interface 0) >> [ 300.640736] snd-usb-audio 1-1:1.0: usb_probe_interface >> [ 300.642307] snd-usb-audio 1-1:1.0: usb_probe_interface - got id >> [ 301.050296] usb 1-1: adding 1-1:1.1 (config #1, interface 1) >> [ 301.054897] usb 1-1: adding 1-1:1.2 (config #1, interface 2) >> [ 301.056934] uvcvideo 1-1:1.2: usb_probe_interface >> [ 301.058072] uvcvideo 1-1:1.2: usb_probe_interface - got id >> [ 301.059395] uvcvideo: Found UVC 1.00 device (046d:081d) >> [ 301.090173] input: UVC Camera (046d:081d) as >> /devices/pci:00/:00:1f.5/usb1/1-1/1-1:1.2/input/input7 > > That seems to be a Logitech model. > >> [ 301.111289] usb 1-1: adding 1-1:1.3 (config #1, interface 3) >> [ 301.131207] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us] >> [ 301.137066] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us] >> [ 301.156451] ehci_hcd :00:1f.5: reused qh f48d64c0 schedule >> [ 301.158310] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us] >> [ 301.160238] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us] >> [ 301.196606] set resolution quirk: cval->res = 384 >> [ 371.309569] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow >> Control: RX >> [ 390.729568] ehci_hcd :00:1f.5: reused qh f48d64c0 schedule >> f5ade900 2296555[ 390.730023] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 >> us] >> 437 S Ii:1:003:7[ 390.736394] usb 1-1: unlink qh16-0001/f48d64c0 start 2 >> [1/0 us] >> -115:128 16 < >> f5ade900 2296566256 C Ii:1:003:7 -2:128 0 >> [ 391.100896] ehci_hcd :00:1
Re: Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On Oct 21, 2012, Borislav Petkov wrote: > > On Sun, Oct 21, 2012 at 01:57:21AM +, Artem S. Tashkinov wrote: > > The freeze happens on my *host* Linux PC. For an experiment I decided > > to check if I could reproduce the freeze under a virtual machine - it > > turns out the Linux kernel running under it also freezes. > > I know that - but a freeze != oops - at least not necessarily. Which > means it could very well be a different issue now that vbox is gone. > > Or, it could be the same issue with different incarnations: with vbox > you get the corruptions and without it, you get the freezes. I'm > assuming you do the same flash player thing in both cases? > > Here's a crazy idea: can you try to reproduce it in KVM? OK, dismiss VBox altogether - it has a very buggy USB implementation, thus it just hangs when trying to access my webcam. What I've found out is that my system crashes *only* when I try to enable usb-audio (from the same webcam) - I still have no idea how to capture a panic message, but I ran "while :; do dmesg -c; done" in xterm, then I got like thousands of messages and I photographed my monitor: http://imageshack.us/a/img685/9452/panicz.jpg list_del corruption. prev->next should be ... but was ... I cannot show you more as I have no serial console to use :( and the kernel doesn't have enough time to push error messages to rsyslog and fsync /var/log/messages -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: question about context switch on arm Linux
On Sun, Oct 21, 2012 at 04:19:50PM +0800, caiyuqing wrote: > Richard, thanks for your reply. > mainline Linux doesn't support FCSE, if so, when kernel switch a > process to another(these two process share the same virtual memory > space), that means the vitrual-to-physical address should be > remaped, TLB shuold be invalid, CACHE should be flushed, right? Yes, and that is why you can measure quite a long context switching time when running Linux on ARMv4/5. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-crypt] cryptsetup not working under 3.6 - regression from 3.4?
Hi, On 21/10/12 10:53, Milan Broz wrote: On 10/20/2012 10:44 PM, Tvrtko Ursulin wrote: But I repeat, even if I load the required modules before hand things do not work. I would say you are still missing some modules. Kernel says this: device-mapper: table: 252:1: crypt: Error allocating crypto tfm device-mapper: ioctl: error adding target to table It complains about aes-cbc-essiv:sha256. It can be missing CBC od SHA256, but according the message I bet you have no "cbc" block cipher mode module compiled. Can you grep your final .config for CONFIG_CRYPTO_CBC and CONFIG_CRYPTO_SHA256 a paste it here? I both working 3.4 and non-working 3.6 situation is the same: CONFIG_CRYPTO_CBC=y CONFIG_CRYPTO_SHA256=m Tvrtko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On 21.10.2012 13:59, Artem S. Tashkinov wrote: > On Oct 21, 2012, Borislav Petkov wrote: >> >> On Sun, Oct 21, 2012 at 01:57:21AM +, Artem S. Tashkinov wrote: >>> The freeze happens on my *host* Linux PC. For an experiment I decided >>> to check if I could reproduce the freeze under a virtual machine - it >>> turns out the Linux kernel running under it also freezes. >> >> I know that - but a freeze != oops - at least not necessarily. Which >> means it could very well be a different issue now that vbox is gone. >> >> Or, it could be the same issue with different incarnations: with vbox >> you get the corruptions and without it, you get the freezes. I'm >> assuming you do the same flash player thing in both cases? >> >> Here's a crazy idea: can you try to reproduce it in KVM? > > OK, dismiss VBox altogether - it has a very buggy USB implementation, thus > it just hangs when trying to access my webcam. Ok. > What I've found out is that my system crashes *only* when I try to enable > usb-audio (from the same webcam) - I still have no idea how to capture a > panic message, but I ran > > "while :; do dmesg -c; done" in xterm, then I got like thousands of messages > and I photographed my monitor: > > http://imageshack.us/a/img685/9452/panicz.jpg A hint at least. How did you enable the audio record exactly? Can you reproduce this with arecord? What chipset are you on? Please provide both "lspci -v" and "lsusb -v" dumps. As I said, I fail to reproduce that issue on any of my machines. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Black screen with gma500_gfx on 3.6.2
Hi, when switching from psb_gfx (3.2) to 3.6.2 (or 3.7 as of 2474542f64432398f503373f53bdf620491bcfa8) I'm getting a black screen on a Axiomtek SBC84826 board with a HP 2310ti attached via VGA. When using CONFIG_STUB_POULSBO=y I do get a console but when I unbind the driver and attach gma500_gfx like echo \:02\:00.0 > /sys/bus/pci/devices/\:02\:00.0/driver/unbind echo \:02\:00.0 > /sys/bus/pci/drivers/gma500/bind the display stays black. dmesg has: [ 688.779860] gma500 :00:02.0: setting latency timer to 64 [ 688.805968] acpi device:04: registered as cooling_device0 [ 688.806976] acpi device:05: registered as cooling_device1 [ 688.807140] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 688.807553] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input13 [ 688.809053] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 688.809065] [drm] No driver support for vblank timestamp query. [ 689.950596] gma500 :00:02.0: Backlight lvds set brightness 7a127a12 [ 689.950627] [drm] Initialized gma500 1.0.0 2011-06-06 for :00:02.0 on minor 0 Besides the VGA the driver detects a LVDS as well although there's none attached (the board does have a connector for it though): # grep -l ^connected /sys/devices/pci:00/:00:02.0/drm/card0/card0-*/status /sys/devices/pci:00/:00:02.0/drm/card0/card0-LVDS-1/status /sys/devices/pci:00/:00:02.0/drm/card0/card0-VGA-1/status It also states that both ports are disabled: # cat /sys/devices/pci:00/:00:02.0/drm/card0/card0-*/enabled disabled disabled I didn't find a way to enable any of these ports via sysfs and X.org's modesetting driver fails either. Any pointers on howto debug this further are greatly appreciated. Cheers, -- Guido P.S.: This is the cards lspci information: 00:02.0 VGA compatible controller: Intel Corporation System Controller Hub (SCH Poulsbo) Graphics Controller (rev 07) (prog-if 00 [VGA controller]) Subsystem: Device 8100:8086 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- [disabled] Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [b0] Vendor Specific Information: Len=07 Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit- Address: Data: Kernel driver in use: gma500 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sun, Oct 21, 2012 at 08:58:07AM +0200, Paweł Sikora wrote:
> On Sunday 21 of October 2012 00:19:48 Marcin Slusarz wrote:
> > On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> > > On 20.10.2012, Marcin Slusarz wrote:
> > >
> > > > Try this one.
> > >
> > > It works, now I can boot again. However, nouveau seems to be dead now.
> > > The dmesg output with your patch on top of 3.7-rc1 is:
> > >
> > > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
> > > minor 0
> > > [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1
> > > [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> > > [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50
> > > [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for
> > > image...
> > > [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for
> > > image...
> > > [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for
> > > image...
> > > [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is
> > > beyond end of region [VROM] (length 24) (20120913/exfldio-210)
> > > [3.704139] ACPI Error: Method parse/execution
> > > failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8),
> > > AE_AML_REGION_LIMIT (20120913/psparse-536)
> > > [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> > > [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for
> > > image...
> > > [3.724111] nouveau :01:00.0: Invalid ROM contents
> > > [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable
> > > image
> > > [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create
> > > 0x1001, -22
> > > [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> > > [3.736097] nouveau: probe of :01:00.0 failed with error -22
> > > [3.740523] dracut: Starting plymouth daemon
> >
> > Hmm, maybe we can't fetch 3 bytes only...
> >
> > Let's check this:
> >
> > ---
> > diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > index 824eea0..8bd71aa 100644
> > --- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > +++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > @@ -192,14 +192,16 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
> > {
> > struct pci_dev *pdev = nv_device(bios)->pdev;
> > int ret, cnt, i;
> > - u8 data[3];
> > + u8 *data;
> >
> > if (!nouveau_acpi_rom_supported(pdev))
> > return;
> >
> > bios->size = 0;
> > - if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
> > + data = kmalloc(4096, GFP_KERNEL);
> > + if (data && nouveau_acpi_get_bios_chunk(data, 0, 4096) >= 3)
> > bios->size = data[2] * 512;
> > + kfree(data);
> > if (!bios->size)
> > return;
>
> with these both patches applied my laptop boots and gui works fine.
> here's dmesg:
>
> (...)
> [8.751795] nouveau [ VBIOS][:01:00.0] ... appears to be valid
> [8.751798] nouveau [ VBIOS][:01:00.0] using image from ACPI
> [8.751895] nouveau [ VBIOS][:01:00.0] BIT signature found
> [8.751898] nouveau [ VBIOS][:01:00.0] version 70.08.45.00
> [8.752366] nouveau [ DEVINIT][:01:00.0] adaptor not initialised
> [8.752368] nouveau [ VBIOS][:01:00.0] running init tables
> [8.867660] nouveau [ MXM][:01:00.0] no VBIOS data, nothing to do
> [8.867690] nouveau [ PFB][:01:00.0] RAM type: DDR3
> [8.867692] nouveau [ PFB][:01:00.0] RAM size: 512 MiB
> [8.901523] vga_switcheroo: enabled
> [8.901979] [TTM] Zone kernel: Available graphics memory: 6104282 kiB
> [8.901980] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
> [8.901982] [TTM] Initializing pool allocator
> [8.902014] [TTM] Initializing DMA pool allocator
> [8.902180] mtrr: type mismatch for c000,1000 old: write-back new:
> write-combining
> [8.902184] nouveau [ DRM] VRAM: 512 MiB
> [8.902185] nouveau [ DRM] GART: 512 MiB
> [8.902188] nouveau [ DRM] BIT BIOS found
> [8.902190] nouveau [ DRM] Bios version 70.08.45.00
> [8.902192] nouveau [ DRM] TMDS table version 2.0
> [8.902194] nouveau [ DRM] DCB version 4.0
> [8.902196] nouveau [ DRM] DCB outp 00: 02011300
> [8.902198] nouveau [ DRM] DCB conn 01: 0100
> [8.903540] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [8.903541] [drm] No driver support for vblank timestamp query.
> [8.903545] nouveau [ DRM] ACPI backlight
Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On 21.10.2012 13:59, Artem S. Tashkinov wrote: > On Oct 21, 2012, Borislav Petkov wrote: >> >> On Sun, Oct 21, 2012 at 01:57:21AM +, Artem S. Tashkinov wrote: >>> The freeze happens on my *host* Linux PC. For an experiment I decided >>> to check if I could reproduce the freeze under a virtual machine - it >>> turns out the Linux kernel running under it also freezes. >> >> I know that - but a freeze != oops - at least not necessarily. Which >> means it could very well be a different issue now that vbox is gone. >> >> Or, it could be the same issue with different incarnations: with vbox >> you get the corruptions and without it, you get the freezes. I'm >> assuming you do the same flash player thing in both cases? >> >> Here's a crazy idea: can you try to reproduce it in KVM? > > OK, dismiss VBox altogether - it has a very buggy USB implementation, thus > it just hangs when trying to access my webcam. > > What I've found out is that my system crashes *only* when I try to enable > usb-audio (from the same webcam) It would also be interesting to know whether you have problems with *only* the video capture, with some tool like "cheese". It might be you're hitting a host controller issue here, and then isochronous input packets on the video interface would most likely also trigger such am effect. Actually, knowing whether that's the case would be crucial for further debugging. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] sound/isa/opti9xx/miro.c: eliminate possible double free
At Sun, 21 Oct 2012 12:52:03 +0200,
Julia Lawall wrote:
>
> From: Julia Lawall
>
> snd_miro_probe is a static function that is only called twice in the file
> that defines it. At each call site, its argument is freed using
> snd_card_free. Thus, there is no need for snd_miro_probe to call
> snd_card_free on its argument on any of its error exit paths.
>
> Because snd_card_free both reads the fields of its argument and kfrees its
> argments, the results of the second snd_card_free should be unpredictable.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> //
> @r@
> identifier f,free,a;
> parameter list[n] ps;
> type T;
> expression e;
> @@
>
> f(ps,T a,...) {
> ... when any
> when != a = e
> if(...) { ... free(a); ... return ...; }
> ... when any
> }
>
> @@
> identifier r.f,r.free;
> expression x,a;
> expression list[r.n] xs;
> @@
>
> * x = f(xs,a,...);
> if (...) { ... free(a); ... return ...; }
> //
>
> Signed-off-by: Julia Lawall
Thanks, applied.
Takashi
>
> ---
> Not tested.
>
> sound/isa/opti9xx/miro.c |1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/sound/isa/opti9xx/miro.c b/sound/isa/opti9xx/miro.c
> index 3d1afb6..4a7ff4e 100644
> --- a/sound/isa/opti9xx/miro.c
> +++ b/sound/isa/opti9xx/miro.c
> @@ -1286,7 +1286,6 @@ static int __devinit snd_miro_probe(struct snd_card
> *card)
>
> error = snd_card_miro_aci_detect(card, miro);
> if (error < 0) {
> - snd_card_free(card);
> snd_printk(KERN_ERR "unable to detect aci chip\n");
> return -ENODEV;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 0/3] Add clock framework for armada 370/XP
On 10/17/2012 05:39 PM, Jason Cooper wrote: > Mike, > > On Mon, Oct 15, 2012 at 02:18:16PM +0200, Gregory CLEMENT wrote: >> Hello Mike, >> >> The v3.7-rc1 was released yesterday. So here it is the updated version >> of my patch set. The rebase was flawless. An I have just fixed a typo >> in the device tree and warnings from checkpatch. I built and test it >> for the Armada 370 and Armada XP evaluation board. >> >> The purpose of this patch set is to add support for clock framework >> for Armada 370 and Armada XP SoCs. All the support is done under the >> directory drivers/clk/mvebu/ as the support for other mvebu SoCs was >> in mind during the writing of the code. >> >> Two kinds of clocks are added: >> >> - The CPU clocks are only for Armada XP (which is multi-core) >> >> - The core clocks are clocks which have their rate fixed during >> reset. >> >> Many thanks to Thomas Petazzoni and Sebastian Hesselbarth for their >> review and feedback. The device tree bindings were really improved >> with the advices of Sebastian. >> >> Changelog: >> V2 -> V3: >> - Rebased on top of v3.7-rc1 >> - Fixed a typo in device trees >> - Fixed warning from checkpatch >> >> V1 -> V2: >> >> - Improved the spelling and the wording of the documentation and the >> 1st commit log >> - Removed the "end_of_list" name which are unused here. >> - Fix the cpu clock by using of_clk_src_onecell_get in the same way it >> was used for the core clocks >> >> Regards, >> >> >> Gregory CLEMENT (3): >> clk: mvebu: add armada-370-xp specific clocks >> clk: armada-370-xp: add support for clock framework >> clocksource: time-armada-370-xp converted to clk framework >> >> .../devicetree/bindings/clock/mvebu-core-clock.txt | 40 +++ >> .../devicetree/bindings/clock/mvebu-cpu-clock.txt | 21 ++ >> arch/arm/boot/dts/armada-370-db.dts|4 - >> arch/arm/boot/dts/armada-370-xp.dtsi |1 + >> arch/arm/boot/dts/armada-370.dtsi | 12 + >> arch/arm/boot/dts/armada-xp.dtsi | 48 +++ >> arch/arm/mach-mvebu/Kconfig|5 + >> arch/arm/mach-mvebu/armada-370-xp.c|8 +- >> arch/arm/mach-mvebu/common.h |1 + >> drivers/clk/Makefile |1 + >> drivers/clk/mvebu/Makefile |2 + >> drivers/clk/mvebu/clk-core.c | 312 >> >> drivers/clk/mvebu/clk-core.h | 19 ++ >> drivers/clk/mvebu/clk-cpu.c| 155 ++ >> drivers/clk/mvebu/clk-cpu.h| 19 ++ >> drivers/clk/mvebu/clk.c| 36 +++ >> drivers/clocksource/time-armada-370-xp.c | 11 +- >> 17 files changed, 685 insertions(+), 10 deletions(-) >> create mode 100644 >> Documentation/devicetree/bindings/clock/mvebu-core-clock.txt >> create mode 100644 >> Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt >> create mode 100644 drivers/clk/mvebu/Makefile >> create mode 100644 drivers/clk/mvebu/clk-core.c >> create mode 100644 drivers/clk/mvebu/clk-core.h >> create mode 100644 drivers/clk/mvebu/clk-cpu.c >> create mode 100644 drivers/clk/mvebu/clk-cpu.h >> create mode 100644 drivers/clk/mvebu/clk.c > > Would it be okay if we took this through the mvebu tree? It looks like > the only potential merge conflict we would have would be in > drivers/clk/Makefile. It would make dependency tracking easier. > It will also be easier for me if it was possible, because I have patch series awaiting which will depend on the support of the clock framework for mvebu. > Otherwise is fine as well, just let me know which you prefer. > > Assuming, of course, everything looks good to you. > > thx, > > Jason. > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: question on NUMA page migration
* Rik van Riel wrote:
> On 10/19/2012 09:23 PM, Ingo Molnar wrote:
> >
> >* Rik van Riel wrote:
> >
> >>On 10/19/2012 01:53 PM, Peter Zijlstra wrote:
> >>>On Fri, 2012-10-19 at 13:13 -0400, Rik van Riel wrote:
> >>
> Another alternative might be to do the put_page inside
> do_prot_none_numa(). That would be analogous to do_wp_page
> disposing of the old page for the caller.
> >>>
> >>>It'd have to be inside migrate_misplaced_page(), can't do before
> >>>isolate_lru_page() or the page might disappear. Doing it after is
> >>>(obviously) too late.
> >>
> >>Keeping an extra refcount on the page might _still_
> >>result in it disappearing from the process by some
> >>other means, in-between you grabbing the refcount
> >>and invoking migration of the page.
> >>
> I am not real happy about NUMA migration introducing its own
> migration mode...
> >>>
> >>>You didn't seem to mind too much earlier, but I can remove it if you
> >>>want.
> >>
> >>Could have been reviewing fatigue :)
> >
> >:-)
> >
> >>And yes, it would have been nice to not have a special
> >>migration mode for sched/numa.
> >>
> >>Speaking of, when do you guys plan to submit a (cleaned up)
> >>version of the sched/numa patch series for review on lkml?
> >
> >Which commit(s) worry you specifically?
>
> One of them would be the commit that introduces MIGRATE_FAULT.
MIGRATE_FAULT is still used.
> Adding it in one patch, and removing it into a next just makes
> things harder on the reviewers.
Yes.
> 03a040f6c17ab81659579ba6abe267c0562097e4
It's still used:
comet:~/tip> git grep MIGRATE_FAULT
include/linux/migrate_mode.h: * MIGRATE_FAULT called from the fault path to
migrate-on-fault for mempolicy
include/linux/migrate_mode.h: MIGRATE_FAULT,
mm/migrate.c: if (mode != MIGRATE_ASYNC && mode != MIGRATE_FAULT) {
mm/migrate.c: if (mode == MIGRATE_FAULT) {
mm/migrate.c:* MIGRATE_FAULT has an extra reference on the page and
mm/migrate.c: if ((mode == MIGRATE_ASYNC || mode == MIGRATE_FAULT) && head &&
mm/migrate.c: if (mode != MIGRATE_ASYNC && mode != MIGRATE_FAULT)
mm/migrate.c: if (!force || mode == MIGRATE_ASYNC || mode ==
MIGRATE_FAULT)
mm/migrate.c: ret = __unmap_and_move(page, newpage, 0, 0, MIGRATE_FAULT);
> If the changesets with NUMA syscalls are still in your tree's
> history, they should not be submitted as part of the patch
> series, either.
No, the syscalls have not been there for quite some time.
If you have trouble with any specific commit, please quote the
specific SHA1 so that I can have a look and resolve any specific
concerns.
Otherwise, lets continue with the integration?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On Oct 21, 2012, Daniel Mack wrote: > A hint at least. How did you enable the audio record exactly? Can you > reproduce this with arecord? > > What chipset are you on? Please provide both "lspci -v" and "lsusb -v" > dumps. As I said, I fail to reproduce that issue on any of my machines. All other applications can read from the USB audio without problems, it's just something in the way Adobe Flash polls my audio input which causes a crash. Just video capture (without audio) works just fine in Adobe Flash. Only and only when I choose to use USB Device 0x46d:0x81d my system crashes in Adobe Flash. See the screenshot: https://bugzilla.kernel.org/attachment.cgi?id=84151 My hardware information can be fetched from here: https://bugzilla.kernel.org/show_bug.cgi?id=49181 On a second thought that can be even an ALSA crash or pretty much anything else. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: question on NUMA page migration
* Rik van Riel wrote: > On 10/20/2012 10:39 PM, Ni zhan Chen wrote: > >On 10/19/2012 11:53 PM, Rik van Riel wrote: > >>Hi Andrea, Peter, > >> > >>I have a question on page refcounting in your NUMA > >>page migration code. > >> > >>In Peter's case, I wonder why you introduce a new > >>MIGRATE_FAULT migration mode. If the normal page > >>migration / compaction logic can do without taking > >>an extra reference count, why does your code need it? > > > >Hi Rik van Riel, > > > >This is which part of codes? Why I can't find MIGRATE_FAULT in latest > >v3.7-rc2? > > It is in tip.git in the numa/core branch. The Git access URI is: git pull git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git numa/core git clone git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git numa/core Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cryptsetup not working under 3.6 - regression from 3.4?
On 21/10/12 13:20, Zdenek Kaspar wrote: I would say you are still missing some modules. Kernel says this: device-mapper: table: 252:1: crypt: Error allocating crypto tfm device-mapper: ioctl: error adding target to table It complains about aes-cbc-essiv:sha256. It can be missing CBC od SHA256, but according the message I bet you have no "cbc" block cipher mode module compiled. Can you grep your final .config for CONFIG_CRYPTO_CBC and CONFIG_CRYPTO_SHA256 a paste it here? I both working 3.4 and non-working 3.6 situation is the same: CONFIG_CRYPTO_CBC=y CONFIG_CRYPTO_SHA256=m Compare please: grep CONFIG_CRYPTO /boot/config-3.4 grep CONFIG_CRYPTO /boot/config-3.6 One of the problem could be that your configuration misses something like: CONFIG_CRYPTO_BLKCIPHER, CONFIG_CRYPTO_MANAGER, etc.. or some of those could changed into modules and are not getting loaded.. Here it is: --- 3.4 2012-10-21 13:32:27.289602863 +0100 +++ 3.6 2012-10-21 13:32:23.824602841 +0100 @@ -1,3 +1,4 @@ +CONFIG_CRYPTO_ABLK_HELPER_X86=m CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_AEAD=m CONFIG_CRYPTO_AES=m @@ -27,15 +28,14 @@ CONFIG_CRYPTO_CTS=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_DES=m -CONFIG_CRYPTO_DEV_PADLOCK_AES=m -CONFIG_CRYPTO_DEV_PADLOCK_SHA=m -CONFIG_CRYPTO_DEV_PADLOCK=y +# CONFIG_CRYPTO_DEV_PADLOCK is not set CONFIG_CRYPTO_ECB=y CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_GCM=m CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=m CONFIG_CRYPTO_GHASH=m +CONFIG_CRYPTO_GLUE_HELPER_X86=m CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HMAC=y @@ -64,6 +64,7 @@ CONFIG_CRYPTO_SALSA20_X86_64=m CONFIG_CRYPTO_SEED=m CONFIG_CRYPTO_SEQIV=m +CONFIG_CRYPTO_SERPENT_AVX_X86_64=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_SERPENT_SSE2_X86_64=m CONFIG_CRYPTO_SHA1=m @@ -73,6 +74,7 @@ CONFIG_CRYPTO_TEA=m # CONFIG_CRYPTO_TEST is not set CONFIG_CRYPTO_TGR192=m +CONFIG_CRYPTO_TWOFISH_AVX_X86_64=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=m Tvrtko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/2] sched, numa, mm: Implement constant rate working set sampling
* Rik van Riel wrote:
> Hi Ingo,
>
> Here are some minor NUMA cleanups to start with.
>
> I have some ideas for larger improvements and ideas to port
> over from autonuma, but I got caught up in some of the code
> and am not sure about those changes yet.
To help out I picked up a couple of obvious ones:
cee8868763f8 x86, mm: Prevent gcc to re-read the pagetables
a860d4c7a1f4 mm: Check if PTE is already allocated during page fault
e9fe72334fb0 numa, mm: Fix NUMA hinting page faults from gup/gup_fast
I kept Andrea as the author, the patches needed only minimal
adaptation.
Plus I finally completed testing and applying Peter's
constant-rate WSS patch:
3d049f8a5398 sched, numa, mm: Implement constant, per task Working Set
Sampling (WSS) rate
This is in part similar to AutoNUMA's hinting page fault rate
limiting feature (pages_to_scan et al), and in part an
improvement/extension of it. See the patch below for details.
Let me know if you have any questions!
Thanks,
Ingo
>
>From 3d049f8a5398d0050ab9978b3ac67402f337390f Mon Sep 17 00:00:00 2001
From: Peter Zijlstra
Date: Sun, 14 Oct 2012 16:59:13 +0200
Subject: [PATCH] sched, numa, mm: Implement constant, per task Working Set
Sampling (WSS) rate
Previously, to probe the working set of a task, we'd use
a very simple and crude method: mark all of its address
space PROT_NONE.
That method has various (obvious) disadvantages:
- it samples the working set at dissimilar rates,
giving some tasks a sampling quality advantage
over others.
- creates performance problems for tasks with very
large working sets
- over-samples processes with large address spaces but
which only very rarely execute
Improve that method by keeping a rotating offset into the
address space that marks the current position of the scan,
and advance it by a constant rate (in a CPU cycles execution
proportional manner). If the offset reaches the last mapped
address of the mm then it then it starts over at the first
address.
The per-task nature of the working set sampling functionality
in this tree allows such constant rate, per task,
execution-weight proportional sampling of the working set,
with an adaptive sampling interval/frequency that goes from
once per 100 msecs up to just once per 1.6 seconds.
The current sampling volume is 256 MB per interval.
As tasks mature and converge their working set, so does the
sampling rate slow down to just a trickle, 256 MB per 1.6
seconds of CPU time executed.
This, beyond being adaptive, also rate-limits rarely
executing systems and does not over-sample on overloaded
systems.
[ In AutoNUMA speak, this patch deals with the effective sampling
rate of the 'hinting page fault'. AutoNUMA's scanning is
currently rate-limited, but it is also fundamentally
single-threaded, executing in the knuma_scand kernel thread,
so the limit in AutoNUMA is global and does not scale up with
the number of CPUs, nor does it scan tasks in an execution
proportional manner.
So the idea of rate-limiting the scanning was first implemented
in the AutoNUMA tree via a global rate limit. This patch goes
beyond that by implementing an execution rate proportional
working set sampling rate that is not implemented via a single
global scanning daemon. ]
Based-on-idea-by: Andrea Arcangeli
Signed-off-by: Peter Zijlstra
Cc: Linus Torvalds
Cc: Andrew Morton
Cc: Peter Zijlstra
Cc: Andrea Arcangeli
Cc: Rik van Riel
Link: http://lkml.kernel.org/n/tip-wt5b48o2226ec63784i58...@git.kernel.org
[ Wrote changelog and fixed bug. ]
Signed-off-by: Ingo Molnar
---
include/linux/mempolicy.h | 2 --
include/linux/mm.h| 6 ++
include/linux/mm_types.h | 1 +
include/linux/sched.h | 1 +
kernel/sched/fair.c | 44
kernel/sysctl.c | 7 +++
mm/mempolicy.c| 24
7 files changed, 55 insertions(+), 30 deletions(-)
diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
index a5bf9d6..d6b1ea1 100644
--- a/include/linux/mempolicy.h
+++ b/include/linux/mempolicy.h
@@ -199,8 +199,6 @@ static inline int vma_migratable(struct vm_area_struct *vma)
extern int mpol_misplaced(struct page *, struct vm_area_struct *, unsigned
long);
-extern void lazy_migrate_process(struct mm_struct *mm);
-
#else /* CONFIG_NUMA */
struct mempolicy {};
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 423464b..64ccf29 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1581,6 +1581,12 @@ static inline pgprot_t vma_prot_none(struct
vm_area_struct *vma)
return pgprot_modify(vma->vm_page_prot, vm_get_page_prot(vmflags));
}
+static inline void
+change_prot_none(struct vm_area_struct *vma, unsigned long start, unsigned
long end)
+{
+ change_protection(vma, start, end, vma_prot_none(vma), 0);
+}
+
struct vm_area_struct *find_extend_vma(struct mm_struct *, unsigned long addr);
int
[PATCH 4/2] numa, mm: Rename the PROT_NONE fault handling functions
* Ingo Molnar wrote:
> > > I don't much care either way, but I was thinking walken
> > > might want to use something similar to do WSS estimation,
> > > in which case the NUMA name is just as wrong.
> >
> > That's a good point. I had not considered other uses of the
> > same code.
>
> Renaming the functions for more clarity still makes sense IMO:
> we could give it a _wss or _working_set prefix/postfix?
So, to not drop your patch on the floor I've modified it as per
the patch below.
The _wss() names signal that these handlers are used for a
specific purpose, they are not related to the regular PROT_NONE
handling code.
Agreed?
Thanks,
Ingo
--->
>From 7e426e0f6ffe228118e57a70ae402e21792a0456 Mon Sep 17 00:00:00 2001
From: Rik van Riel
Date: Thu, 18 Oct 2012 17:20:21 -0400
Subject: [PATCH] numa, mm: Rename the PROT_NONE fault handling functions
Having the function name indicate what the function is used
for makes the code a little easier to read. Furthermore,
the fault handling code largely consists of do__page
functions.
Rename the Working-Set Sampling (WSS) fault handling functions
to indicate what they are used for.
Signed-off-by: Rik van Riel
Cc: aarca...@redhat.com
Cc: a.p.zijls...@chello.nl
Link: http://lkml.kernel.org/r/20121018172021.0b1f6...@cuia.bos.redhat.com
[ Changed the naming pattern to 'working-set sampling (WSS)' wss_() ]
Signed-off-by: Ingo Molnar
---
include/linux/huge_mm.h | 8
mm/huge_memory.c| 4 ++--
mm/memory.c | 18 ++
3 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index bcbe467..93c6ab5 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -160,9 +160,9 @@ static inline struct page *compound_trans_head(struct page
*page)
return page;
}
-extern bool pmd_prot_none(struct vm_area_struct *vma, pmd_t pmd);
+extern bool pmd_wss(struct vm_area_struct *vma, pmd_t pmd);
-extern void do_huge_pmd_prot_none(struct mm_struct *mm, struct vm_area_struct
*vma,
+extern void do_huge_pmd_wss_page(struct mm_struct *mm, struct vm_area_struct
*vma,
unsigned long address, pmd_t *pmd,
unsigned int flags, pmd_t orig_pmd);
@@ -203,12 +203,12 @@ static inline int pmd_trans_huge_lock(pmd_t *pmd,
return 0;
}
-static inline bool pmd_prot_none(struct vm_area_struct *vma, pmd_t pmd)
+static inline bool pmd_wss(struct vm_area_struct *vma, pmd_t pmd)
{
return false;
}
-static inline void do_huge_pmd_prot_none(struct mm_struct *mm, struct
vm_area_struct *vma,
+static inline void do_huge_pmd_wss_page(struct mm_struct *mm, struct
vm_area_struct *vma,
unsigned long address, pmd_t *pmd,
unsigned int flags, pmd_t orig_pmd)
{
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index c58a5f0..982f678 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -727,7 +727,7 @@ out:
return handle_pte_fault(mm, vma, address, pte, pmd, flags);
}
-bool pmd_prot_none(struct vm_area_struct *vma, pmd_t pmd)
+bool pmd_wss(struct vm_area_struct *vma, pmd_t pmd)
{
/*
* See pte_prot_none().
@@ -738,7 +738,7 @@ bool pmd_prot_none(struct vm_area_struct *vma, pmd_t pmd)
return pmd_same(pmd, pmd_modify(pmd, vma_prot_none(vma)));
}
-void do_huge_pmd_prot_none(struct mm_struct *mm, struct vm_area_struct *vma,
+void do_huge_pmd_wss_page(struct mm_struct *mm, struct vm_area_struct *vma,
unsigned long address, pmd_t *pmd,
unsigned int flags, pmd_t entry)
{
diff --git a/mm/memory.c b/mm/memory.c
index 2cc8a29..a3693e6 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1471,11 +1471,13 @@ int zap_vma_ptes(struct vm_area_struct *vma, unsigned
long address,
}
EXPORT_SYMBOL_GPL(zap_vma_ptes);
-static bool pte_prot_none(struct vm_area_struct *vma, pte_t pte)
+static bool pte_wss(struct vm_area_struct *vma, pte_t pte)
{
/*
-* If we have the normal vma->vm_page_prot protections we're not a
-* 'special' PROT_NONE page.
+* For NUMA page faults, we use PROT_NONE ptes in VMAs with
+* "normal" vma->vm_page_prot protections. Genuine PROT_NONE
+* VMAs should never get here, because the fault handling code
+* will notice that the VMA has no read or write permissions.
*
* This means we cannot get 'special' PROT_NONE faults from genuine
* PROT_NONE maps, nor from PROT_WRITE file maps that do dirty
@@ -3476,7 +3478,7 @@ static int do_nonlinear_fault(struct mm_struct *mm,
struct vm_area_struct *vma,
return __do_fault(mm, vma, address, pmd, pgoff, flags, orig_pte);
}
-static int do_prot_none(struct mm_struct *mm, struct vm_area_struct *vma,
+static int do_wss_page(struct mm_struct *mm, struct vm_area_struct *vma,
[tip:numa/core] sched, numa, mm: Implement constant, per task Working Set Sampling (WSS) rate
Commit-ID: 3d049f8a5398d0050ab9978b3ac67402f337390f
Gitweb: http://git.kernel.org/tip/3d049f8a5398d0050ab9978b3ac67402f337390f
Author: Peter Zijlstra
AuthorDate: Sun, 14 Oct 2012 16:59:13 +0200
Committer: Ingo Molnar
CommitDate: Sun, 21 Oct 2012 14:40:27 +0200
sched, numa, mm: Implement constant, per task Working Set Sampling (WSS) rate
Previously, to probe the working set of a task, we'd use
a very simple and crude method: mark all of its address
space PROT_NONE.
That method has various (obvious) disadvantages:
- it samples the working set at dissimilar rates,
giving some tasks a sampling quality advantage
over others.
- creates performance problems for tasks with very
large working sets
- over-samples processes with large address spaces but
which only very rarely execute
Improve that method by keeping a rotating offset into the
address space that marks the current position of the scan,
and advance it by a constant rate (in a CPU cycles execution
proportional manner). If the offset reaches the last mapped
address of the mm then it then it starts over at the first
address.
The per-task nature of the working set sampling functionality
in this tree allows such constant rate, per task,
execution-weight proportional sampling of the working set,
with an adaptive sampling interval/frequency that goes from
once per 100 msecs up to just once per 1.6 seconds.
The current sampling volume is 256 MB per interval.
As tasks mature and converge their working set, so does the
sampling rate slow down to just a trickle, 256 MB per 1.6
seconds of CPU time executed.
This, beyond being adaptive, also rate-limits rarely
executing systems and does not over-sample on overloaded
systems.
[ In AutoNUMA speak, this patch deals with the effective sampling
rate of the 'hinting page fault'. AutoNUMA's scanning is
currently rate-limited, but it is also fundamentally
single-threaded, executing in the knuma_scand kernel thread,
so the limit in AutoNUMA is global and does not scale up with
the number of CPUs, nor does it scan tasks in an execution
proportional manner.
So the idea of rate-limiting the scanning was first implemented
in the AutoNUMA tree via a global rate limit. This patch goes
beyond that by implementing an execution rate proportional
working set sampling rate that is not implemented via a single
global scanning daemon. ]
Based-on-idea-by: Andrea Arcangeli
Signed-off-by: Peter Zijlstra
Cc: Linus Torvalds
Cc: Andrew Morton
Cc: Peter Zijlstra
Cc: Andrea Arcangeli
Cc: Rik van Riel
Link: http://lkml.kernel.org/n/tip-wt5b48o2226ec63784i58...@git.kernel.org
[ Wrote changelog and fixed bug. ]
Signed-off-by: Ingo Molnar
---
include/linux/mempolicy.h |2 --
include/linux/mm.h|6 ++
include/linux/mm_types.h |1 +
include/linux/sched.h |1 +
kernel/sched/fair.c | 44
kernel/sysctl.c |7 +++
mm/mempolicy.c| 24
7 files changed, 55 insertions(+), 30 deletions(-)
diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
index a5bf9d6..d6b1ea1 100644
--- a/include/linux/mempolicy.h
+++ b/include/linux/mempolicy.h
@@ -199,8 +199,6 @@ static inline int vma_migratable(struct vm_area_struct *vma)
extern int mpol_misplaced(struct page *, struct vm_area_struct *, unsigned
long);
-extern void lazy_migrate_process(struct mm_struct *mm);
-
#else /* CONFIG_NUMA */
struct mempolicy {};
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 423464b..64ccf29 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1581,6 +1581,12 @@ static inline pgprot_t vma_prot_none(struct
vm_area_struct *vma)
return pgprot_modify(vma->vm_page_prot, vm_get_page_prot(vmflags));
}
+static inline void
+change_prot_none(struct vm_area_struct *vma, unsigned long start, unsigned
long end)
+{
+ change_protection(vma, start, end, vma_prot_none(vma), 0);
+}
+
struct vm_area_struct *find_extend_vma(struct mm_struct *, unsigned long addr);
int remap_pfn_range(struct vm_area_struct *, unsigned long addr,
unsigned long pfn, unsigned long size, pgprot_t);
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index bef4c5e..01c1d04 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -405,6 +405,7 @@ struct mm_struct {
#endif
#ifdef CONFIG_SCHED_NUMA
unsigned long numa_next_scan;
+ unsigned long numa_scan_offset;
int numa_scan_seq;
#endif
struct uprobes_state uprobes_state;
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 9e726f0..63c011e 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2022,6 +2022,7 @@ extern enum sched_tunable_scaling
sysctl_sched_tunable_scaling;
extern unsigned int sysctl_sched_numa_task_period_min;
extern unsigned int sysctl_sched_numa_task_period_max;
+extern unsigned int sys
[tip:numa/core] sched, numa: Add NUMA_MIGRATION feature flag
Commit-ID: aef6f4048d7467d2d805c6c9edc6dab37597becb Gitweb: http://git.kernel.org/tip/aef6f4048d7467d2d805c6c9edc6dab37597becb Author: Ingo Molnar AuthorDate: Sat, 20 Oct 2012 22:20:19 +0200 Committer: Ingo Molnar CommitDate: Sun, 21 Oct 2012 14:40:41 +0200 sched, numa: Add NUMA_MIGRATION feature flag After this patch, doing: # echo NO_NUMA_MIGRATION > /sys/kernel/debug/sched_features Will turn off the NUMA placement logic/policy - but keeps the working set sampling faults in place. This allows the debugging of the WSS facility, by using it but keeping vanilla, non-NUMA CPU and memory placement policies. Default enabled. Generates on extra code on !CONFIG_SCHED_DEBUG. Signed-off-by: Ingo Molnar Cc: Linus Torvalds Cc: Andrew Morton Cc: Peter Zijlstra Cc: Andrea Arcangeli Cc: Rik van Riel Link: http://lkml.kernel.org/n/tip-xjt7bqjlphxrfjxxasqm4...@git.kernel.org --- kernel/sched/core.c |3 +++ kernel/sched/features.h |3 +++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index ef24c7b..67221c0 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -6002,6 +6002,9 @@ void sched_setnode(struct task_struct *p, int node) int on_rq, running; struct rq *rq; + if (!sched_feat(NUMA_MIGRATION)) + return; + rq = task_rq_lock(p, &flags); on_rq = p->on_rq; running = task_current(rq, p); diff --git a/kernel/sched/features.h b/kernel/sched/features.h index f8a7aeb..1d11f6c 100644 --- a/kernel/sched/features.h +++ b/kernel/sched/features.h @@ -63,7 +63,10 @@ SCHED_FEAT(RT_RUNTIME_SHARE, true) SCHED_FEAT(LB_MIN, false) #ifdef CONFIG_SCHED_NUMA +/* Do the working set probing faults: */ SCHED_FEAT(NUMA, true) +/* Do actual migration/placement based on the working set information: */ +SCHED_FEAT(NUMA_MIGRATION, true) SCHED_FEAT(NUMA_HOT, true) SCHED_FEAT(NUMA_TTWU_BIAS, false) SCHED_FEAT(NUMA_TTWU_TO, false) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:numa/core] numa, mm: Fix 4K migration races
Commit-ID: eb4f84b1aaad78ca07e274b81410ec9d60abe434
Gitweb: http://git.kernel.org/tip/eb4f84b1aaad78ca07e274b81410ec9d60abe434
Author: Ingo Molnar
AuthorDate: Sat, 20 Oct 2012 23:06:00 +0200
Committer: Ingo Molnar
CommitDate: Sun, 21 Oct 2012 14:40:42 +0200
numa, mm: Fix 4K migration races
__unmap_and_move() can fail with -EAGAIN:
- if we race with swapout picking up the page
- if migrate_page_move_mapping() sees the
page count changing unexpectedly
- if two threads are trying to migrate the same page
There are other, more theoretical races as well, such as
the possibility of a pte being WSS mapped twice.
Fix them and clean up the code flow.
Signed-off-by: Ingo Molnar
Cc: Linus Torvalds
Cc: Andrew Morton
Cc: Peter Zijlstra
Cc: Andrea Arcangeli
Cc: Rik van Riel
Link: http://lkml.kernel.org/n/tip-wdyptm0xgskzbyatienqe...@git.kernel.org
---
mm/memory.c | 44
mm/migrate.c | 22 --
2 files changed, 48 insertions(+), 18 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index c0de477..2cc8a29 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3483,11 +3483,13 @@ static int do_prot_none(struct mm_struct *mm, struct
vm_area_struct *vma,
struct page *page = NULL;
int node, page_nid = -1;
spinlock_t *ptl;
+ int account = 1;
+ int locked = 0;
ptl = pte_lockptr(mm, pmd);
spin_lock(ptl);
if (unlikely(!pte_same(*ptep, entry)))
- goto unlock;
+ goto out_unlock;
page = vm_normal_page(vma, address, entry);
if (page) {
@@ -3498,20 +3500,25 @@ static int do_prot_none(struct mm_struct *mm, struct
vm_area_struct *vma,
goto migrate;
}
-fixup:
+out_pte_upgrade_unlock:
flush_cache_page(vma, address, pte_pfn(entry));
ptep_modify_prot_start(mm, address, ptep);
entry = pte_modify(entry, vma->vm_page_prot);
ptep_modify_prot_commit(mm, address, ptep, entry);
+ /* No TLB flush needed because we upgraded the PTE */
+
update_mmu_cache(vma, address, ptep);
-unlock:
+out_unlock:
pte_unmap_unlock(ptep, ptl);
out:
if (page) {
- task_numa_fault(page_nid, 1);
+ if (locked)
+ unlock_page(page);
+ if (account)
+ task_numa_fault(page_nid, 1);
put_page(page);
}
@@ -3520,19 +3527,40 @@ out:
migrate:
pte_unmap_unlock(ptep, ptl);
+ locked = 1;
+ lock_page(page);
+
+ /*
+* We have to do this again, to make sure
+* we have not raced with a pte update
+* during the lock_page():
+*/
+ ptep = pte_offset_map_lock(mm, pmd, address, &ptl);
+ if (!pte_same(*ptep, entry)) {
+ account = 0;
+ goto out_unlock;
+ }
+ pte_unmap_unlock(ptep, ptl);
+
if (!migrate_misplaced_page(page, node)) {
+ /*
+* Successful migration - account the fault.
+* Note, we don't fix up the pte, that will
+* happen on the next fault.
+*/
page_nid = node;
+ put_page(page);
+
goto out;
}
ptep = pte_offset_map_lock(mm, pmd, address, &ptl);
if (!pte_same(*ptep, entry)) {
- put_page(page);
- page = NULL;
- goto unlock;
+ account = 0;
+ goto out_unlock;
}
- goto fixup;
+ goto out_pte_upgrade_unlock;
}
/*
diff --git a/mm/migrate.c b/mm/migrate.c
index 72d1056..6d16bff 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1449,20 +1449,22 @@ int migrate_misplaced_page(struct page *page, int node)
}
if (isolate_lru_page(page)) {
- ret = -EBUSY;
- goto put_new;
+ put_page(newpage);
+ return -EBUSY;
}
inc_zone_page_state(page, NR_ISOLATED_ANON + page_lru);
ret = __unmap_and_move(page, newpage, 0, 0, MIGRATE_FAULT);
- /*
-* A page that has been migrated has all references removed and will be
-* freed. A page that has not been migrated will have kepts its
-* references and be restored.
-*/
- dec_zone_page_state(page, NR_ISOLATED_ANON + page_lru);
- putback_lru_page(page);
-put_new:
+
+ if (ret != -EAGAIN) {
+ /*
+* A page that has been migrated has all references removed and
will be
+* freed. A page that has not been migrated will have kepts its
+* references and be restored.
+*/
+ dec_zone_page_state(page, NR_ISOLATED_ANON + page_lru);
+ putback_lru_page(page);
+ }
/*
* Move the new page to the LRU. If migration was not successful
* then
Re: [GIT PULL] Linux KVM tool for v3.7-rc0
* Christoph Hellwig wrote: > On Sun, Oct 21, 2012 at 01:07:31PM +1000, Dave Airlie wrote: > > Why couldn't this script just be a wrapper around qemu > > It can be. Here is my ususual one: > > #!/bin/sh > > /opt/qemu/bin/qemu-system-x86_64 \ > -m 1500 \ > -enable-kvm \ > -drive if=none,file=/home/hch/qemu-root.img,cache=none,id=root \ You are wrong on three counts: - As I mentioned it in my first mail to you this is not the same as 'vm run': you still have a qemu-root.img while tools/kvm does not ... 'vm run' works without having any disk image around, it just uses the existing distro binaries and boots them, sharing the host file system. - automatic, transparent host filesystem sharing is another useful feature: I can copy files in/out of the virtual machine using the host filesystem. - transparent networking is up and running straight away But yeah, I guess if you ignore enough key tools/kvm/ features then you will eventually be right: it's really just the same as Qemu and has no place in the kernel repo ;-) Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/2] numa, mm: Rename the PROT_NONE fault handling functions
On 10/21/2012 08:50 AM, Ingo Molnar wrote: * Ingo Molnar wrote: I don't much care either way, but I was thinking walken might want to use something similar to do WSS estimation, in which case the NUMA name is just as wrong. That's a good point. I had not considered other uses of the same code. Renaming the functions for more clarity still makes sense IMO: we could give it a _wss or _working_set prefix/postfix? So, to not drop your patch on the floor I've modified it as per the patch below. The _wss() names signal that these handlers are used for a specific purpose, they are not related to the regular PROT_NONE handling code. Michel indicated that he does not use PROT_NONE for his working set estimation code, but instead checks the accessed bits in the page tables. Since NUMA migration is the only user of PROT_NONE ptes in normal vmas, maybe _numa is the right suffix after all? -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/2] numa, mm: Rename the PROT_NONE fault handling functions
* Rik van Riel wrote: > On 10/21/2012 08:50 AM, Ingo Molnar wrote: > > > >* Ingo Molnar wrote: > > > I don't much care either way, but I was thinking walken > might want to use something similar to do WSS estimation, > in which case the NUMA name is just as wrong. > >>> > >>>That's a good point. I had not considered other uses of the > >>>same code. > >> > >>Renaming the functions for more clarity still makes sense IMO: > >>we could give it a _wss or _working_set prefix/postfix? > > > >So, to not drop your patch on the floor I've modified it as per > >the patch below. > > > >The _wss() names signal that these handlers are used for a > >specific purpose, they are not related to the regular PROT_NONE > >handling code. > > Michel indicated that he does not use PROT_NONE for his > working set estimation code, but instead checks the accessed > bits in the page tables. The pte_young() WSS method has a couple of fundamental limitations: - it doesn't work with shared memory very well, the pte is per mapping, not per page. The PROT_NONE method instruments the physical page in essence. - it does not tell us which task touched the pte, in a multi-threaded program So like Peter I'd too expect these new WSS methods to eventually be picked up for any serious WSS work. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On 21.10.2012, Marcin Slusarz wrote: > > > Please attach acpidump output. > > > > http://pluto.agmk.net/nv/acpidump.txt > > > > This looks like ACPI bug... I guess my acpidump didn't make it to the list. Anyway, here it is: http://www.fritha.org/acpidump.gz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/11] perf python: Link with libtraceevent
* Arnaldo Carvalho de Melo wrote: > Em Sat, Oct 20, 2012 at 02:35:57AM +0200, Ingo Molnar escreveu: > > Even with that I'm getting: > > > > util/python.c: In function ???initperf???: > > util/python.c:1018:2: error: ???page_size??? undeclared > > (first use in this function) > > util/python.c:1018:2: note: each undeclared identifier is > > reported only once for each function it appears in > > error: command 'gcc' failed with exit status 1 > > Yeah, there was another problem, a patch that makes sense only > for perf/core was added, I reverted it after Namhyung reported > the same problem: Yeah. So, you being on conference and me trying to not miss -rc2 with a couple of high-profile perf fixes I ended up resolving this bug in the merge commit, the almost-evil merge a448a03 and such. That's now upstream - mind checking whether anything is still amiss? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/2] numa, mm: Rename the PROT_NONE fault handling functions
* Ingo Molnar wrote: > > Michel indicated that he does not use PROT_NONE for his > > working set estimation code, but instead checks the accessed > > bits in the page tables. > > The pte_young() WSS method has a couple of fundamental > limitations: > > - it doesn't work with shared memory very well, the pte is per >mapping, not per page. The PROT_NONE method instruments the >physical page in essence. > > - it does not tell us which task touched the pte, in a >multi-threaded program > > So like Peter I'd too expect these new WSS methods to eventually > be picked up for any serious WSS work. Nevertheless lets wait and see until it actually happens - and meanwhile the prot_none namings are confusing. So I've applied your patch as-is, with two more (new) usage sites converted as well. Will push it out after a bit of testing. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Linux KVM tool for v3.7-rc0
On Sun, Oct 21, 2012 at 2:59 PM, Ingo Molnar wrote: > You are wrong on three counts: > > - As I mentioned it in my first mail to you this is not the >same as 'vm run': you still have a qemu-root.img while >tools/kvm does not ... > >'vm run' works without having any disk image around, it just >uses the existing distro binaries and boots them, sharing the >host file system. > > - automatic, transparent host filesystem sharing is another >useful feature: I can copy files in/out of the virtual >machine using the host filesystem. > > - transparent networking is up and running straight away qemu supports all these features. E.g. to access the host fs use: qemu ... \ -fsdev local,security_model=passthrough,id=fsdev-root,path=/your/root/,readonly \ -device virtio-9p-pci,id=fs-root,fsdev=fsdev-root,mount_tag=rootshare -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: was: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
[Cc: alsa-devel]
On 21.10.2012 14:30, Artem S. Tashkinov wrote:
> On Oct 21, 2012, Daniel Mack wrote:
>
>> A hint at least. How did you enable the audio record exactly? Can you
>> reproduce this with arecord?
>>
>> What chipset are you on? Please provide both "lspci -v" and "lsusb -v"
>> dumps. As I said, I fail to reproduce that issue on any of my machines.
>
> All other applications can read from the USB audio without problems, it's
> just something in the way Adobe Flash polls my audio input which causes
> a crash.
>
> Just video capture (without audio) works just fine in Adobe Flash.
Ok, so that pretty much rules out the host controller. I just wonder why
I still don't see it here, and I haven't heard of any such problem from
anyone else.
Some more questions:
- Which version of Flash are you running?
- Does this also happen with Firefox?
- Does flash access the device directly or via PulseAudio?
- Could you please apply the attached patch and see what it spits out to
dmesg once Flash opens the device? It returns -EINVAL in the hw_params
callback to prevent the actual streaming. On my machine with Flash
11.4.31.110, I get values of 2/44800/1/32768/2048/0, which seems sane.
Or does your machine still crash before anything is written to the logs?
> Only and only when I choose to use
>
> USB Device 0x46d:0x81d my system crashes in Adobe Flash.
>
> See the screenshot:
>
> https://bugzilla.kernel.org/attachment.cgi?id=84151
When exactly does the crash happen? Right after you selected that entry
from the list? There's a little recording level meter in that dialog.
Does that show any input from the microphone?
> My hardware information can be fetched from here:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=49181
>
> On a second thought that can be even an ALSA crash or pretty much
> anything else.
We'll see. Thanks for your help to sort this out!
Daniel
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
index f782ce1..5664b45 100644
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -453,6 +453,18 @@ static int snd_usb_hw_params(struct snd_pcm_substream *substream,
unsigned int channels, rate, format;
int ret, changed;
+
+ printk(">>> %s()\n", __func__);
+
+ printk("format: %d\n", params_format(hw_params));
+ printk("rate: %d\n", params_rate(hw_params));
+ printk("channels: %d\n", params_channels(hw_params));
+ printk("buffer bytes: %d\n", params_buffer_bytes(hw_params));
+ printk("period bytes: %d\n", params_period_bytes(hw_params));
+ printk("access: %d\n", params_access(hw_params));
+
+ return -EINVAL;
+
ret = snd_pcm_lib_alloc_vmalloc_buffer(substream,
params_buffer_bytes(hw_params));
if (ret < 0)
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz wrote: > > This looks like ACPI bug... I'm _shocked_ to hear that firmware would be fragile. Anyway, here's the #1 thing to keep in mind about firmware: - firmware is *always* buggy. It's that simple. Don't expect anything else. Firmware is written by people who have lost the will to live (why? Because they do firmware development for a living), and the only thing keeping them going is the drugs. And they're not the "fun" kind of drugs. The end result is predictable. In their drug-induced haze, they make a mess. So saying "ACPI is buggy" is like saying "water is wet". Deal with it. > Nouveau calls this method: [...] > > with Arg0 == 0, Arg1 == 3 and gets: > > ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond end of region > [VROM] (length 24) (20120913/exfldio-210) > ACPI Error: Method parse/execution failed [\_SB_.PCI0.PEGR.GFX0._ROM] (Node > 88033e47fe88), AE_AML_REGION_LIMIT (20120913/psparse-536) > > We can workaround it by aligning Arg1 to 4096 (I'm wondering what is the > minimal > value), but do we really have to? Yes, you really have to. You need to understand that ACPI has been tested with one thing, and one thing only: Windows. Clearly windows doesn't ask for some three-byte region. So it doesn't work. Big surprise. Untested code written by monkeys on crack - what did you expect? So don't do "clever" things. When it comes to firmware, you need to expect it to be buggy, and try to access it the way Windows accesses it. Now, whether Windows realy always does things with a 4kB-aligned access, or whether you just need to make sure that you're (say) 4-byte-aligned, I don't know. Maybe doing things four (or eight, or sixteen) bytes at a time will work. You can try. But if we know from past experience that a 4kB block-size will work, I'd suggest just saying "It's stupid, but stupid is good - we're working with firmware" Think of firmware the way you think of hardware: it's buggy and needs workarounds. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
drm_kms_helper problems
I have a TV that appears to not provide proper EDID info to the HDMI or DVI
ports of my Intel DH77DF motherboard. I received some pointers from this
list that pointed me in the direction of creating my own EDID file and I
now have a binary blob that matches what the service manual says is the
proper EDID info.
But I am unable to get the drm_kms_helper module to load and use this file.
My relevant kernel config options are.
CONFIG_DRM_KMS_HELPER=m
CONFIG_DRM_LOAD_EDID_FIRMWARE=y
my relevant kernel command line contains:
video=card0-HDMI-A-1:e
drm_kms_helper.edid_firmware=card0-HDMI-A-1:edid/lg42lb9df_hdmi1.edid
The edid file:
# ls -al /lib/firmware/edid/lg42lb9df_hdmi1.edid
-rw-r--r-- 1 root root 256 Oct 16 05:46 /lib/firmware/edid/lg42lb9df_hdmi1.edid
connector info from /sys/class/drm/
card0 card0-DP-1 card0-DP-2 card0-DP-3 card0-HDMI-A-1 card0-HDMI-A-2
card0-HDMI-A-3 card0-VGA-1 controlD64 version
And I don't really understand why I have 3 entries for the one hdmi port?
Nor do I really understand _exactly_ how to define the connector in my
kernel command line or which of the 3 connectors from /sys I should be
using. I've tried different variants. Ie. card0-HDMI-A-1and HDMI-A-1.
The results in the kernel log file remain:
[1.879654] drm_kms_helper: Unknown parameter `edid'
I assume I am doing something wrong but I have put some debug printks in
kernel/params.c that shows me every call made to it and it's params. It is
entered many times and I see a sequence to in the log file. As an example,
the last one to call with params before drm_kms_helper is "late" and here
are my debug prints for it:
[0.840206] parse_args: Entered for late
[0.840207] parse_args: doing = late
[0.840208] parse_args: args =
root=/dev/disk/by-id/ata-INTEL_SSDSC2CW060A3_CVCV205106EB060AGN-part4
video=1024x768
resume=/dev/disk/by-id/ata-INTEL_SSDSC2CW060A3_CVCV205106EB060AGN-part3
splash=silent quiet vga=0x37e irqpoll video=card0-HDMI-A-1:e
drm_kms_helper.edid_firmware=card0-HDMI-A-1:edid/lg42lb9df_hdmi1.edid
[0.840209] parse_args: params =
[0.840210] parse_args: num = 174
[0.840210] parse_args: min_level = 7
[0.840211] parse_args: max_level = 7
Now when it gets to drm_kms_helper this is what I get and this is certainly
screwed up, I just don't know why.
[1.879648] parse_args: Entered for drm_kms_helper
[1.879648] parse_args: doing = drm_kms_helper
[1.879649] parse_args: args = edid
\xff86\xffe2\xfff8h\xff89\xff86\xffc0\xff80\x\xԒ\xffe2\xfff8T\xff86\xffe2\xfff88\xff89\xff86\xffc0\xffa4\x\xd\xff86\xffe2\xfff8
[1.879650] parse_args: num = 2
[1.879651] parse_args: min_level = -32768
[1.879651] parse_args: max_level = 32767
[1.879653]
\xff86\xffe2\xfff8h\xff89\xff86\xffc0\xff80\x\xԒ\xffe2\xfff8T\xff86\xffe2\xfff88\xff89\xff86\xffc0\xffa4\x\xd\xff86\xffe2\xfff8,
num=2, min_level=-32768, max_level=32767
Then finally:
[1.879654] drm_kms_helper: Unknown parameter `edid'
The additional printks I inserted into kernel/params.c:
if (*args)
pr_debug("doing %s, parsing ARGS: '%s'\n", doing, args);
+ if (*args) {
+ printk("\nparse_args: Entered for %s\n", doing);
+ printk("parse_args: doing = %s\n", doing);
+ printk("parse_args: args = %s\n", args);
+ printk("parse_args: params = %s\n", params);
+ printk("parse_args: num = %d\n", num);
+ printk("parse_args: min_level = %d\n",min_level);
+ printk("parse_args: max_level = %d\n", max_level);
+ }
while (*args) {
This is using a vanilla 3.6.2 kernel. Any help would be appreciated.
Regards
Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] genirq: for edge interrupt IRQS_ONESHOT support with irq thread
On Sat, 2012-10-13 at 14:21 +0900, anish kumar wrote: > On Fri, 2012-10-12 at 22:52 +0200, Thomas Gleixner wrote: > > On Fri, 12 Oct 2012, Liu, Chuansheng wrote: > > > > -Original Message- > > > > From: anish kumar [mailto:anish198519851...@gmail.com] > > > > Sent: Friday, October 12, 2012 11:25 PM > > > > To: Liu, Chuansheng > > > > Cc: Thomas Gleixner; linux-kernel@vger.kernel.org > > > > Subject: RE: [PATCH] genirq: for edge interrupt IRQS_ONESHOT support > > > > with irq > > > > thread > > > > > > > > On Fri, 2012-10-12 at 14:57 +, Liu, Chuansheng wrote: > > > > > > On SMP an interrupt which is raised after the ack() again before the > > > > > > handler finishes, can invoke another delivery on a different CPU, > > > > > > which then sees the IRQ_INPROGESS flag, masks it and flags it > > > > > > PENDING. When the primary handler on the first CPU returns, it sees > > > > > > the PENDING flag, unmasks and invokes the handler another time. > > > > > In this case, when IRQ_INPROGRESS flag is set, on another CPU, it will > > > > > mask and ack it, if before the primary handler on the first CPU > > > > > returns, > > > > > the edge interrupt is raised again, it will be lost, right? > > > > Why will the interrupt be raised again?Is not it masked?I read tglx > > > I means because it is masked, if at this time device issues edge irq, > > > It will not be delivered and lost. > > > > No, it is NOT lost. The irq is marked PENDING already, so we invoke > It is fairly easy for an edge triggered interrupt to be missed - for > example if interrupts have to be masked for a period - and unless there > is some type of hardware latch that records the event it is impossible > to recover. > tglx, explanation will only work if we have a hardware latch which when > unmasked sends all those edge interrupts again (which had come when it > was masked while the CPU was handling the same interrupts). > > PS:http://kernel.org/doc/htmldocs/genericirq.html Hello tglx, Does this explanation makes sense? > > the handler again and handle it. And before we invoke the handler > > another time we unmask it. > > > > It does not matter at all whether the interrupt has been sent five > > times while it was masked. What matters is that we recorded the first > > one and set the PENDING flag. That way we invoke the interrupt handler > > again and keep stuff rolling. > > > > Thanks, > > > > tglx > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: irq/manage.c wrong comment( ? )
ping...
On Sat, 2012-10-13 at 00:32 +0900, anish kumar wrote:?
> Hello tglx,
>
> I just found the below inconsistency while going through the code.
>
>
> kernel/irq/manage.c
>
> if (new->flags & IRQF_ONESHOT) {
> /*
> * The thread_mask for the action is or'ed to
> * desc->thread_active to indicate that the
> * IRQF_ONESHOT thread handler has been woken, but not
> * yet finished. The bit is cleared when a thread
> * completes. When all threads of a shared interr
>
> Shouldn't this "desc->thread_active" be desc->threads_active ??
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sun, Oct 21, 2012 at 07:38:58AM -0700, Linus Torvalds wrote: > On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz > wrote: > > > > This looks like ACPI bug... > > I'm _shocked_ to hear that firmware would be fragile. > > Anyway, here's the #1 thing to keep in mind about firmware: > > - firmware is *always* buggy. I know. But this bug is not about broken firmware. It's about Linux kernel ACPI implementation, which (I think) wrongly interprets ACPI script. Marcin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: was: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
> On Oct 21, 2012, Daniel Mack wrote: > > [Cc: alsa-devel] > > On 21.10.2012 14:30, Artem S. Tashkinov wrote: > > On Oct 21, 2012, Daniel Mack wrote: > > > >> A hint at least. How did you enable the audio record exactly? Can you > >> reproduce this with arecord? > >> > >> What chipset are you on? Please provide both "lspci -v" and "lsusb -v" > >> dumps. As I said, I fail to reproduce that issue on any of my machines. > > > > All other applications can read from the USB audio without problems, it's > > just something in the way Adobe Flash polls my audio input which causes > > a crash. > > > > Just video capture (without audio) works just fine in Adobe Flash. > > Ok, so that pretty much rules out the host controller. I just wonder why > I still don't see it here, and I haven't heard of any such problem from > anyone else. > > Some more questions: > > - Which version of Flash are you running? Google Chrome has its own version of Adobe Flash: Name: Shockwave Flash Description:Shockwave Flash 11.4 r31 Version:11.4.31.110 > - Does this also happen with Firefox? No, Adobe Flash in Firefox is an older version (Shockwave Flash 11.1 r102), it shows just two input devices instead of three which the newer Flash players sees. * HDA Intel PCH * USB Device 0x46d:0x81d > - Does flash access the device directly or via PulseAudio? PA is not installed on my computer, so Flash accesses it directly via ALSA calls. > - Could you please apply the attached patch and see what it spits out to > dmesg once Flash opens the device? It returns -EINVAL in the hw_params > callback to prevent the actual streaming. On my machine with Flash > 11.4.31.110, I get values of 2/44800/1/32768/2048/0, which seems sane. > Or does your machine still crash before anything is written to the logs? I will try it a bit later. > > Only and only when I choose to use > > > > USB Device 0x46d:0x81d my system crashes in Adobe Flash. > > > > See the screenshot: > > > > https://bugzilla.kernel.org/attachment.cgi?id=84151 > > When exactly does the crash happen? Right after you selected that entry > from the list? There's a little recording level meter in that dialog. > Does that show any input from the microphone? Yes, right after I select it and move the mouse cursor away from this combobox so that this selection becomes active. > > My hardware information can be fetched from here: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=49181 > > > > On a second thought that can be even an ALSA crash or pretty much > > anything else. > > We'll see. Thanks for your help to sort this out! Thank you for your assistance! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] drm_kms_helper problems
Hi mark,
On Sun, 21 October 2012 Mark Hounschell wrote:
> I have a TV that appears to not provide proper EDID info to the HDMI or DVI
> ports of my Intel DH77DF motherboard. I received some pointers from this
> list that pointed me in the direction of creating my own EDID file and I
> now have a binary blob that matches what the service manual says is the
> proper EDID info.
>
> But I am unable to get the drm_kms_helper module to load and use this file.
> My relevant kernel config options are.
>
> CONFIG_DRM_KMS_HELPER=m
> CONFIG_DRM_LOAD_EDID_FIRMWARE=y
>
> my relevant kernel command line contains:
>
> video=card0-HDMI-A-1:e
> drm_kms_helper.edid_firmware=card0-HDMI-A-1:edid/lg42lb9df_hdmi1.edid
The variant without card0- should be the right one.
> The edid file:
> # ls -al /lib/firmware/edid/lg42lb9df_hdmi1.edid
> -rw-r--r-- 1 root root 256 Oct 16 05:46
> /lib/firmware/edid/lg42lb9df_hdmi1.edid
>
> connector info from /sys/class/drm/
>
> card0 card0-DP-1 card0-DP-2 card0-DP-3 card0-HDMI-A-1 card0-HDMI-A-2
> card0-HDMI-A-3 card0-VGA-1 controlD64 version
>
> And I don't really understand why I have 3 entries for the one hdmi port?
> Nor do I really understand _exactly_ how to define the connector in my
> kernel command line or which of the 3 connectors from /sys I should be
> using. I've tried different variants. Ie. card0-HDMI-A-1and HDMI-A-1.
>
> The results in the kernel log file remain:
>
> [1.879654] drm_kms_helper: Unknown parameter `edid'
As your drm_kms_helper is built modular, did you try not putting that
parameter on kernel cmdline but rather put it in modprobe's configuration
for that module? (may doing the whole loading manually).
# modprobe drm_kms_helper edid_firmware=HDMI-A-1:edid/lg42lb9df_hdmi1.edid
I have no idea why it fails for you, here on the systems I have it works
fine (on one where everything is built into the kernel I did set the cmdline
arguments via CONFIG_CMDLINE="..." (having CONFIG_CMDLINE_BOOL=y).
> I assume I am doing something wrong but I have put some debug printks in
> kernel/params.c that shows me every call made to it and it's params. It is
> entered many times and I see a sequence to in the log file. As an example,
> the last one to call with params before drm_kms_helper is "late" and here
> are my debug prints for it:
Did you check that your bootloader get things right, e.g. if results are the
same no matter in which order you put the kernel parameters (and if there are
some non-ASCII values in there).
As you have quite some length of parameters there could be some buffer size
issue.
(take this as just wild guessing)
Bruno
> [0.840206] parse_args: Entered for late
> [0.840207] parse_args: doing = late
> [0.840208] parse_args: args =
> root=/dev/disk/by-id/ata-INTEL_SSDSC2CW060A3_CVCV205106EB060AGN-part4
> video=1024x768
> resume=/dev/disk/by-id/ata-INTEL_SSDSC2CW060A3_CVCV205106EB060AGN-part3
> splash=silent quiet vga=0x37e irqpoll video=card0-HDMI-A-1:e
> drm_kms_helper.edid_firmware=card0-HDMI-A-1:edid/lg42lb9df_hdmi1.edid
> [0.840209] parse_args: params =
> [0.840210] parse_args: num = 174
> [0.840210] parse_args: min_level = 7
> [0.840211] parse_args: max_level = 7
>
> Now when it gets to drm_kms_helper this is what I get and this is certainly
> screwed up, I just don't know why.
>
> [1.879648] parse_args: Entered for drm_kms_helper
> [1.879648] parse_args: doing = drm_kms_helper
> [1.879649] parse_args: args = edid
> \xff86\xffe2\xfff8h\xff89\xff86\xffc0\xff80\x\xԒ\xffe2\xfff8T\xff86\xffe2\xfff88\xff89\xff86\xffc0\xffa4\x\xd\xff86\xffe2\xfff8
> [1.879650] parse_args: num = 2
> [1.879651] parse_args: min_level = -32768
> [1.879651] parse_args: max_level = 32767
> [1.879653]
> \xff86\xffe2\xfff8h\xff89\xff86\xffc0\xff80\x\xԒ\xffe2\xfff8T\xff86\xffe2\xfff88\xff89\xff86\xffc0\xffa4\x\xd\xff86\xffe2\xfff8,
>
> num=2, min_level=-32768, max_level=32767
>
> Then finally:
>
> [1.879654] drm_kms_helper: Unknown parameter `edid'
>
> The additional printks I inserted into kernel/params.c:
>
> if (*args)
> pr_debug("doing %s, parsing ARGS: '%s'\n", doing, args);
>
> + if (*args) {
> + printk("\nparse_args: Entered for %s\n", doing);
> + printk("parse_args: doing = %s\n", doing);
> + printk("parse_args: args = %s\n", args);
> + printk("parse_args: params = %s\n", params);
> + printk("parse_args: num = %d\n", num);
> + printk("parse_args: min_level = %d\n",min_level);
> + printk("parse_args: max_level = %d\n", max_level);
> + }
>
> while (*args) {
>
> This is using a vanilla 3.6.2 kernel. Any help would b
Re: [PATCH 5/5] Thermal: Add ST-Ericsson db8500 thermal dirver.
Hi Hongbo,
On 10/16/2012 01:44 PM, hongbo.zhang wrote:
> From: "hongbo.zhang"
>
> This diver is based on the thermal management framework in thermal_sys.c.
> A thermal zone device is created with the trip points to which cooling
> devices can be bound, the current cooling device is cpufreq, e.g. CPU
> frequency is clipped down to cool the CPU, and other cooling devices can
> be added and bound to the trip points dynamically.
> The platform specific PRCMU interrupts are used to active thermal update
> when trip points are reached.
[...]
> diff --git a/drivers/thermal/db8500_cpufreq_cooling.c
> b/drivers/thermal/db8500_cpufreq_cooling.c
> new file mode 100644
> index 000..bb065d4
> --- /dev/null
> +++ b/drivers/thermal/db8500_cpufreq_cooling.c
> @@ -0,0 +1,118 @@
> +/*
> + * db8500_cpufreq_cooling.c - db8500 cpufreq works as cooling device.
> + *
> + * Copyright (C) 2012 ST-Ericsson
> + * Copyright (C) 2012 Linaro Ltd.
> + *
> + * Author: Hongbo Zhang
Your e-mail address is misspelled :)
[...]
> diff --git a/drivers/thermal/db8500_thermal.c
> b/drivers/thermal/db8500_thermal.c
> new file mode 100644
> index 000..34dcc52
> --- /dev/null
> +++ b/drivers/thermal/db8500_thermal.c
> @@ -0,0 +1,507 @@
> +/*
> + * db8500_thermal.c - db8500 Thermal Management Implementation
> + *
> + * Copyright (C) 2012 ST-Ericsson
> + * Copyright (C) 2012 Linaro Ltd.
> + *
> + * Author: Hongbo Zhang
Misspelled address
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define PRCMU_DEFAULT_MEASURE_TIME 0xFFF
> +#define PRCMU_DEFAULT_LOW_TEMP 0
> +
> +struct db8500_thermal_zone {
> + struct thermal_zone_device *therm_dev;
> + struct mutex th_lock;
> + struct platform_device *thsens_pdev;
This member is set in db8500_thermal_probe(), but is never used. I would
suggest removing it.
> + struct work_struct therm_work;
> + struct db8500_thsens_platform_data *trip_tab;
> + enum thermal_device_mode mode;
> + enum thermal_trend trend;
> + unsigned long cur_temp_pseudo;
> + unsigned int cur_index;
> + int low_irq;
> + int high_irq;
Same story as thsens_pdev, low_irq and high_irq are set in
db8500_thermal_probe(), but are never used. Should be removed.
> +};
> +
> +/* Callback to bind cooling device to thermal zone */
> +static int db8500_cdev_bind(struct thermal_zone_device *thermal,
> + struct thermal_cooling_device *cdev)
> +{
> + struct db8500_thermal_zone *pzone;
> + struct db8500_thsens_platform_data *ptrips;
> + char *cdev_name;
> + unsigned long max_state, upper, lower;
> + int i, j, ret;
> +
> + pzone = (struct db8500_thermal_zone *)thermal->devdata;
> + ptrips = pzone->trip_tab;
> +
> + if (!cdev->type)
> + return -EINVAL;
cdev->type is an array, not a simple pointer, so it cannot be NULL.
> +
> + ret = -ENODEV;
> + for (i = 0; i < ptrips->num_trips; i++)
> + for (j = 0; j < COOLING_DEV_MAX; j++) {
> + cdev_name = ptrips->trip_points[i].cooling_dev_name[j];
> + if (!cdev_name)
> + continue;
> +
> + if (strcmp(cdev_name, cdev->type))
> + continue;
> +
> + cdev->ops->get_max_state(cdev, &max_state);
> + upper = (i > max_state) ? max_state : i;
> + lower = (i > max_state) ? max_state : i;
You may want to merge these two lines: upper = lower = ...
> +
> + ret = thermal_zone_bind_cooling_device(thermal, i,
> + cdev, upper, lower);
> + if (ret)
> + pr_err("Error binding cooling device.\n");
> + else
> + pr_info("Cdev %s bound.\n", cdev->type);
> + }
> +
> + return ret;
> +}
> +
> +/* Callback to unbind cooling device from thermal zone */
> +static int db8500_cdev_unbind(struct thermal_zone_device *thermal,
> + struct thermal_cooling_device *cdev)
> +{
> + struct db8500_thermal_zone *pzone;
> + struct db8500_thsens_platform_data *ptrips;
> + char *cdev_name;
> + int i, j, ret;
> +
> + pzone = (struct db8500_thermal_zone *)thermal->devdata;
> + ptrips = pzone->trip_tab;
> +
> + if (!cdev->type)
> +
Re: [GIT PULL] Linux KVM tool for v3.7-rc0
* richard -rw- weinberger wrote: > qemu supports all these features. > E.g. to access the host fs use: > qemu ... \ > -fsdev > local,security_model=passthrough,id=fsdev-root,path=/your/root/,readonly > \ > -device virtio-9p-pci,id=fs-root,fsdev=fsdev-root,mount_tag=rootshare The best way to compare them would be a script that gives exactly the same test environment that 'vm run' / 'vm sandbox' does out of box, but using qemu. If such a script is available then that would certainly be a useful testing option to kernel developers. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[NetRom] possible circular locking dependency detected
Hi,
When shutting down my dual core system, there was a possible circular
locking dependency detected that is related to NetRom.
Here is the syslog report.
Regards,
Bernard, f6bvp
Oct 21 12:10:35 f6bvp-8 aprslist[1773]: terminating on SIGTERM
Oct 21 12:10:35 f6bvp-8 fpacstat: terminating on SIGTERM
Oct 21 12:10:35 f6bvp-8 netromd[1653]: terminating on SIGTERM
Oct 21 12:10:35 f6bvp-8 ax25ipd:
Oct 21 12:10:35 f6bvp-8 ax25ipd: socket udp on port 10094
Oct 21 12:10:35 f6bvp-8 ax25ipd: mode tnc
Oct 21 12:10:35 f6bvp-8 ax25ipd: device /dev/ptmx
Oct 21 12:10:35 f6bvp-8 ax25ipd: speed 115200
Oct 21 12:10:35 f6bvp-8 ax25ipd: loglevel 1
Oct 21 12:10:35 f6bvp-8 ax25ipd:
Oct 21 12:10:35 f6bvp-8 ax25ipd: K4GBB 184.4.148.122 udp 10094 1
Oct 21 12:10:35 f6bvp-8 ax25ipd: F8COJ 0.0.0.0 udp 10093 1
Oct 21 12:10:35 f6bvp-8 ax25ipd: F3KT 62.147.189.164 udp 10093 1
Oct 21 12:10:35 f6bvp-8 ax25ipd: F6BVP-12 192.168.0.68 udp 10093 4
Oct 21 12:10:35 f6bvp-8 ax25ipd: F6BVP-11 192.168.0.115 udp 10093 4
Oct 21 12:10:35 f6bvp-8 ax25ipd: F6BVP-10 192.168.0.115 udp 10093 5
Oct 21 12:10:35 f6bvp-8 ax25ipd: VA2BBS 24.212.252.110 udp 10093 1
Oct 21 12:10:35 f6bvp-8 ax25ipd: ON4HU 81.243.88.115 udp 10093 1
Oct 21 12:10:35 f6bvp-8 ax25ipd: IZ3LSV 88.149.155.158 udp 10094 5
Oct 21 12:10:35 f6bvp-8 ax25ipd:
Oct 21 12:10:35 f6bvp-8 nfs-server[27474]: Arrêt de NFS kernel daemon
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150299]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150313]
==
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150317] [ INFO: possible circular
locking dependency detected ]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150321] 3.6.1 #1 Not tainted
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150325]
---
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150329] ax25ipd/1580 is trying to
acquire lock:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150333] (nr_node_list_lock){+.},
at: [] nr_rt_device_down+0x7c/0x240 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150352]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150352] but task is already holding
lock:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150356] (nr_neigh_list_lock){+.-.-.},
at: [] nr_rt_device_down+0x26/0x240 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150373]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150373] which lock already depends on
the new lock.
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150373]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150378]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150378] the existing dependency chain
(in reverse order) is:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150382]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150382] -> #2
(nr_neigh_list_lock){+.-.-.}:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150396][]
lock_acquire+0x92/0x120
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150409][]
_raw_spin_lock_bh+0x36/0x50
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150418][]
nr_remove_neigh+0x1b/0xb0 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150429][]
nr_rt_ioctl+0x2b0/0xa60 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150438][]
nr_ioctl+0x51/0x1d0 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150445][]
sock_do_ioctl+0x30/0x70
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150454][]
sock_ioctl+0x79/0x2f0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150460][]
do_vfs_ioctl+0x98/0x560
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150468][]
sys_ioctl+0x91/0xa0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150477][]
system_call_fastpath+0x16/0x1b
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150486]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150486] -> #1
(&(&nr_node->node_lock)->rlock){+.}:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150498][]
lock_acquire+0x92/0x120
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150505][]
_raw_spin_lock_bh+0x36/0x50
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150512][]
nr_node_show+0x4c/0x150 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150522][]
seq_read+0x26c/0x420
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150529][]
proc_reg_read+0x86/0xc0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150537][]
vfs_read+0xac/0x180
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150546][]
sys_read+0x4a/0x90
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150552][]
system_call_fastpath+0x16/0x1b
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150559]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150559] -> #0
(nr_node_list_lock){+.}:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150571][]
__lock_acquire+0x1a91/0x1ce0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150578][]
lock_acquire+0x92/0x120
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150586][]
_raw_spin_lock_bh+0x36/0x50
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150592][]
nr_rt_device_down+0x7c/0x240 [netrom]
Oct 21 12:10:36 f6bvp-8 ker
Re: [PATCH] tools/kvm: Add a .s file rule
On Sat, 20 Oct 2012, Borislav Petkov wrote: > Add a rule to the kvm tool Makefile to build .asm versions of the files. > This is good for debugging purposes. > > Cc: Pekka Enberg > Cc: Sasha Levin > Cc: Asias He > Signed-off-by: Borislav Petkov Applied, thanks Borislav! > --- > tools/kvm/Makefile | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/tools/kvm/Makefile b/tools/kvm/Makefile > index 903001e80951..64f2646e5966 100644 > --- a/tools/kvm/Makefile > +++ b/tools/kvm/Makefile > @@ -314,6 +314,9 @@ util/rbtree.d: ../../lib/rbtree.c > %.d: %.c > $(Q) $(CC) -M -MT $(patsubst %.d,%.o,$@) $(CFLAGS) $< -o $@ > > +%.s: %.c > + $(Q) $(CC) -o $@ -S $(CFLAGS) -fverbose-asm $< > + > # The header file common-cmds.h is needed for compilation of builtin-help.c. > builtin-help.d: $(KVM_INCLUDE)/common-cmds.h > > -- > 1.8.0.rc2 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:numa/core] numa, mm: Rename the PROT_NONE fault handling functions to *_numa()
Commit-ID: 2458840fddea542391d343dac734d149607db709
Gitweb: http://git.kernel.org/tip/2458840fddea542391d343dac734d149607db709
Author: Rik van Riel
AuthorDate: Thu, 18 Oct 2012 17:20:21 -0400
Committer: Ingo Molnar
CommitDate: Sun, 21 Oct 2012 15:41:26 +0200
numa, mm: Rename the PROT_NONE fault handling functions to *_numa()
Having the function name indicate what the function is used
for makes the code a little easier to read. Furthermore,
the fault handling code largely consists of do__page
functions.
Rename the NUMA working set sampling fault handling functions
to _numa() names, to indicate what they are used for.
This separates the naming from the regular PROT_NONE namings.
Signed-off-by: Rik van Riel
Cc: aarca...@redhat.com
Cc: a.p.zijls...@chello.nl
Link: http://lkml.kernel.org/r/20121018172021.0b1f6...@cuia.bos.redhat.com
[ Converted two more usage sites ]
Signed-off-by: Ingo Molnar
---
include/linux/huge_mm.h |8
mm/huge_memory.c|4 ++--
mm/memory.c | 22 --
3 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index bcbe467..4f0f948 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -160,9 +160,9 @@ static inline struct page *compound_trans_head(struct page
*page)
return page;
}
-extern bool pmd_prot_none(struct vm_area_struct *vma, pmd_t pmd);
+extern bool pmd_numa(struct vm_area_struct *vma, pmd_t pmd);
-extern void do_huge_pmd_prot_none(struct mm_struct *mm, struct vm_area_struct
*vma,
+extern void do_huge_pmd_numa_page(struct mm_struct *mm, struct vm_area_struct
*vma,
unsigned long address, pmd_t *pmd,
unsigned int flags, pmd_t orig_pmd);
@@ -203,12 +203,12 @@ static inline int pmd_trans_huge_lock(pmd_t *pmd,
return 0;
}
-static inline bool pmd_prot_none(struct vm_area_struct *vma, pmd_t pmd)
+static inline bool pmd_numa(struct vm_area_struct *vma, pmd_t pmd)
{
return false;
}
-static inline void do_huge_pmd_prot_none(struct mm_struct *mm, struct
vm_area_struct *vma,
+static inline void do_huge_pmd_numa_page(struct mm_struct *mm, struct
vm_area_struct *vma,
unsigned long address, pmd_t *pmd,
unsigned int flags, pmd_t orig_pmd)
{
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index c58a5f0..a8f6531 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -727,7 +727,7 @@ out:
return handle_pte_fault(mm, vma, address, pte, pmd, flags);
}
-bool pmd_prot_none(struct vm_area_struct *vma, pmd_t pmd)
+bool pmd_numa(struct vm_area_struct *vma, pmd_t pmd)
{
/*
* See pte_prot_none().
@@ -738,7 +738,7 @@ bool pmd_prot_none(struct vm_area_struct *vma, pmd_t pmd)
return pmd_same(pmd, pmd_modify(pmd, vma_prot_none(vma)));
}
-void do_huge_pmd_prot_none(struct mm_struct *mm, struct vm_area_struct *vma,
+void do_huge_pmd_numa_page(struct mm_struct *mm, struct vm_area_struct *vma,
unsigned long address, pmd_t *pmd,
unsigned int flags, pmd_t entry)
{
diff --git a/mm/memory.c b/mm/memory.c
index 2cc8a29..23d4bd4 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1471,11 +1471,13 @@ int zap_vma_ptes(struct vm_area_struct *vma, unsigned
long address,
}
EXPORT_SYMBOL_GPL(zap_vma_ptes);
-static bool pte_prot_none(struct vm_area_struct *vma, pte_t pte)
+static bool pte_numa(struct vm_area_struct *vma, pte_t pte)
{
/*
-* If we have the normal vma->vm_page_prot protections we're not a
-* 'special' PROT_NONE page.
+* For NUMA page faults, we use PROT_NONE ptes in VMAs with
+* "normal" vma->vm_page_prot protections. Genuine PROT_NONE
+* VMAs should never get here, because the fault handling code
+* will notice that the VMA has no read or write permissions.
*
* This means we cannot get 'special' PROT_NONE faults from genuine
* PROT_NONE maps, nor from PROT_WRITE file maps that do dirty
@@ -1543,7 +1545,7 @@ struct page *follow_page(struct vm_area_struct *vma,
unsigned long address,
page = follow_huge_pmd(mm, address, pmd, flags & FOLL_WRITE);
goto out;
}
- if ((flags & FOLL_NUMA) && pmd_prot_none(vma, *pmd))
+ if ((flags & FOLL_NUMA) && pmd_numa(vma, *pmd))
goto no_page_table;
if (pmd_trans_huge(*pmd)) {
if (flags & FOLL_SPLIT) {
@@ -1574,7 +1576,7 @@ split_fallthrough:
pte = *ptep;
if (!pte_present(pte))
goto no_page;
- if ((flags & FOLL_NUMA) && pte_prot_none(vma, pte))
+ if ((flags & FOLL_NUMA) && pte_numa(vma, pte))
goto no_page;
if ((flags & FOLL_WRITE) && !pte_write(pte))
goto unlock;
@@ -3476,7 +3478,7 @@ static int do_nonlinea
[tip:numa/core] numa, mm: Remove paranoia checks from do_huge_pmd_numa_page()
Commit-ID: 9e1696b792d97b7fea2d650d4d7a42a92e85c4b0 Gitweb: http://git.kernel.org/tip/9e1696b792d97b7fea2d650d4d7a42a92e85c4b0 Author: Ingo Molnar AuthorDate: Sun, 21 Oct 2012 16:32:33 +0200 Committer: Ingo Molnar CommitDate: Sun, 21 Oct 2012 16:32:33 +0200 numa, mm: Remove paranoia checks from do_huge_pmd_numa_page() Remove a couple of debugging checks from do_huge_pmd_numa_page(). Cc: Rik van Riel Cc: aarca...@redhat.com Cc: a.p.zijls...@chello.nl Link: http://lkml.kernel.org/n/tip-nhyrhlt42rlghgatxyugh...@git.kernel.org Signed-off-by: Ingo Molnar --- mm/huge_memory.c |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index a8f6531..5aa935a 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -782,10 +782,6 @@ unlock: return; migrate: - WARN_ON(!(((unsigned long)page->mapping & PAGE_MAPPING_ANON))); - WARN_ONunsigned long)page->mapping & PAGE_MAPPING_KSM))); - BUG_ON(PageSwapCache(page)); - spin_unlock(&mm->page_table_lock); lock_page(page); @@ -802,8 +798,6 @@ migrate: (GFP_TRANSHUGE | GFP_THISNODE) & ~__GFP_WAIT, HPAGE_PMD_ORDER); - WARN_ON(PageLRU(new_page)); - if (!new_page) goto alloc_fail; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: was: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On 21.10.2012 16:57, Artem S. Tashkinov wrote: >> On Oct 21, 2012, Daniel Mack wrote: >> >> [Cc: alsa-devel] >> >> On 21.10.2012 14:30, Artem S. Tashkinov wrote: >>> On Oct 21, 2012, Daniel Mack wrote: >>> A hint at least. How did you enable the audio record exactly? Can you reproduce this with arecord? What chipset are you on? Please provide both "lspci -v" and "lsusb -v" dumps. As I said, I fail to reproduce that issue on any of my machines. >>> >>> All other applications can read from the USB audio without problems, it's >>> just something in the way Adobe Flash polls my audio input which causes >>> a crash. >>> >>> Just video capture (without audio) works just fine in Adobe Flash. >> >> Ok, so that pretty much rules out the host controller. I just wonder why >> I still don't see it here, and I haven't heard of any such problem from >> anyone else. >> >> Some more questions: >> >> - Which version of Flash are you running? > > Google Chrome has its own version of Adobe Flash: > > Name: Shockwave Flash > Description: Shockwave Flash 11.4 r31 > Version: 11.4.31.110 So that's the same that I'm using. >> - Does this also happen with Firefox? > > No, Adobe Flash in Firefox is an older version (Shockwave Flash 11.1 r102), > it shows > just two input devices instead of three which the newer Flash players sees. > > * HDA Intel PCH > * USB Device 0x46d:0x81d And that works, I assume? Does the second choice in the newer Flash version work maybe? >> - Does flash access the device directly or via PulseAudio? > > PA is not installed on my computer, so Flash accesses it directly via ALSA > calls. Ok, Same here. >> - Could you please apply the attached patch and see what it spits out to >> dmesg once Flash opens the device? It returns -EINVAL in the hw_params >> callback to prevent the actual streaming. On my machine with Flash >> 11.4.31.110, I get values of 2/44800/1/32768/2048/0, which seems sane. >> Or does your machine still crash before anything is written to the logs? > > I will try it a bit later. Yes, we need to trace the call chain and see at which point the trouble starts. What could help is tracing the google-chrome binary with strace maybe. At least we would see the ioctl command sequence, if the log file survives the crash. As the usb list is still in Cc: - Artem's lcpci dump shows that his machine features XHCI controllers. Can anyone think of a relation to this problem? And Artem, is there any way you boot your system on an older machine that only has EHCI ports? Thinking about it, I wonder whether the freeze in VBox and the crashes on native hardware have the same root cause. In that case, would it be possible to share that VBox image? Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On Sun, 21 Oct 2012, Artem S. Tashkinov wrote: > What I've found out is that my system crashes *only* when I try to enable > usb-audio (from the same webcam) - I still have no idea how to capture a > panic message, but I ran > > "while :; do dmesg -c; done" in xterm, then I got like thousands of messages > and I photographed my monitor: > > http://imageshack.us/a/img685/9452/panicz.jpg > > list_del corruption. prev->next should be ... but was ... > > I cannot show you more as I have no serial console to use :( and the kernel > doesn't have enough time to push error messages to rsyslog and fsync > /var/log/messages Is it possible to use netconsole? The screenshot above appears to be the end of a long series of error messages, which isn't too useful. The most important information is in the first error. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: was: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On Sun, 21 Oct 2012, Daniel Mack wrote: > As the usb list is still in Cc: - Artem's lcpci dump shows that his > machine features XHCI controllers. Can anyone think of a relation to > this problem? > > And Artem, is there any way you boot your system on an older machine > that only has EHCI ports? Thinking about it, I wonder whether the freeze > in VBox and the crashes on native hardware have the same root cause. In > that case, would it be possible to share that VBox image? Don't grasp at straws. All of the kernel logs Artem has posted show ehci-hcd; none of them show xhci-hcd. Therefore the xHCI controller is highly unlikely to be involved. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Linux KVM tool for v3.7-rc0
On Sun, Oct 21, 2012 at 2:59 PM, Ingo Molnar wrote: >> You are wrong on three counts: >> >> - As I mentioned it in my first mail to you this is not the >>same as 'vm run': you still have a qemu-root.img while >>tools/kvm does not ... >> >>'vm run' works without having any disk image around, it just >>uses the existing distro binaries and boots them, sharing the >>host file system. >> >> - automatic, transparent host filesystem sharing is another >>useful feature: I can copy files in/out of the virtual >>machine using the host filesystem. >> >> - transparent networking is up and running straight away On Sun, Oct 21, 2012 at 5:02 PM, richard -rw- weinberger wrote: > qemu supports all these features. > E.g. to access the host fs use: > qemu ... \ > -fsdev > local,security_model=passthrough,id=fsdev-root,path=/your/root/,readonly > \ > -device virtio-9p-pci,id=fs-root,fsdev=fsdev-root,mount_tag=rootshare IIRC, QEMU uses SLIRP non-root zero-config networking which is much more limited than what LKVM offers out of the box. Using host system rootfs is not quote as simple as you seem to think so you need something like Alexander Graf's shell script for comparable 'vm run' experience. Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] oprofile fixes
* Robert Richter wrote: > Ingo, > > On 15.10.12 16:39:12, Robert Richter wrote: > > On 10.10.12 10:18:35, Dan Carpenter wrote: > > > The "event" variable is a u16 so the shift will always wrap to zero > > > making the line a no-op. > > > > > > Signed-off-by: Dan Carpenter > > > > Patch applied. Thanks for reporting and fixing. > > please pull this fix for tip:perf/urgent from > > git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git urgent Pulled, thanks guys! Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] firmware loader: misc changes
On Sun, Oct 21, 2012 at 03:55:45PM +0800, Ming Lei wrote: > On Tue, Oct 9, 2012 at 12:01 PM, Ming Lei wrote: > > Hi, > > > > The first two are fixes' patch, the 3rd one is to enable > > caching firmware for direct loading, and the last one is > > a cleanup patch. > > > > drivers/base/firmware_class.c | 266 > > +++-- > > 1 file changed, 151 insertions(+), 115 deletions(-) > > Hi Greg, > > Could you push the patchset or at least the first 3 fix patches > onto 3.7-rc? > > BTW: 3/4 is still a fix, since linus's direct loading breaks firmware cache > which has been used by some drivers(such as: ath9k) Yes, sorry, they are still in my queue, I was working on other fixes for other subsystems this past week. I'll get to these tomorrow. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] tick: Some consolidation cleanups
* Frederic Weisbecker wrote: > Ingo, Thomas, > > I guess those patches are not controversial so I'm joining a > pull request on the first take, just in case. > > This can be pulled from: > > git://github.com/fweisbec/linux-dynticks.git > nohz/core > > Thanks. > > Frederic Weisbecker (3): > tick: Consolidate timekeeping handling code > tick: Consolidate tick handling for high and low res handlers > tick: Conditionally build nohz specific code in tick handler > > kernel/time/tick-sched.c | 111 > -- > 1 files changed, 48 insertions(+), 63 deletions(-) Pulled, thanks Frederic! Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/6] perf tools: configure tmp path at build time
* Christoph Hellwig wrote: > A system that doesn't have /bin/sh is fundamentally broken. No, such a system is simply different. > How about just creating it as a symlink in a simple unix > compatibility layer for Android. That'd help with /tmp as > well. That might make sense to pursue, are you volunteering for it? Meanwhile here on earth we are making stuff work, regardless of dogmatic declarations. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 12/37] block: fix request_queue->flags initialization
On Sat, Oct 20, 2012 at 12:16:04AM +0100, Ben Hutchings wrote: > On Thu, Oct 18, 2012 at 08:16:35PM -0700, Greg Kroah-Hartman wrote: > > 3.0-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Tejun Heo > > > > commit 60ea8226cbd5c8301f9a39edc574ddabcb8150e0 upstream. > > > > A queue newly allocated with blk_alloc_queue_node() has only > > QUEUE_FLAG_BYPASS set. For request-based drivers, > > blk_init_allocated_queue() is called and q->queue_flags is overwritten > > with QUEUE_FLAG_DEFAULT which doesn't include BYPASS even though the > > initial bypass is still in effect. > > > > In blk_init_allocated_queue(), or QUEUE_FLAG_DEFAULT to q->queue_flags > > instead of overwriting. > [...] > > This is not needed, as there is no QUEUE_FLAG_BYPASS in 3.0.y. Odd, it doesn't break the build. And for some reason I just missed this, does it hurt to have it applied? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 02/37] lockd: use rpc clients cl_nodename for id encoding
On Sat, Oct 20, 2012 at 12:15:18AM +0100, Ben Hutchings wrote: > On Thu, Oct 18, 2012 at 08:16:25PM -0700, Greg Kroah-Hartman wrote: > > 3.0-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Stanislav Kinsbursky > > > > commit 303a7ce92064c285a04c870f2dc0192fdb2968cb upstream. > > > > Taking hostname from uts namespace if not safe, because this cuold be > > performind during umount operation on child reaper death. And in this case > > current->nsproxy is NULL already. > > In this case (3.0.y) you haven't included the following change > (commit cb7323fffa85 'lockd: create and use per-net NSM RPC clients on > MON/UNMON requests') that makes lockd actually use cl_nodename. I > think this patch alone won't fix the bug, as nsm_args::nodename can > end up pointing to freed memory. > > (I also wonder whether clients should really be per-net or per UTS > namespace, and whether those should be orthogonal namespaces at all.) Hm, Trond, should I also include the other commit above in the next 3.0-stable release? Or should this one be dropped? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 6/6] perf stat: implement --big-num grouping
* Christoph Hellwig wrote: > On Tue, Oct 16, 2012 at 02:33:40AM +0300, Irina Tirdea wrote: > > From: Irina Tirdea > > > > In glibc, printf supports ' to group numbers with thousands' > > grouping characters. Bionic does not support ' for printf. > > > > Implement thousands's grouping for numbers according to > > locale. The implementation uses the algorithm from glibc > > (http://www.gnu.org/software/libc/). > > > > Bionic does not implement locales, so we need to add a > > configuration option LOCALE_SUPPORT. If it is not defined, > > default values for thousands separator and grouping are > > used. > > Duplicating this in perf sounds like a hack. [...] There's countless utility and compatibility 'hacks' in the Linux kernel too, which makes it a practical solution. > [...] Does gnulib provide this feature? It's the canonical > source for getting standards or helper functions on systems > that don't support them. Unless Android comes with "gnulib" installed by default that's obviously not a solution. What's your point? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the tip tree with Linus' tree
* Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in
> mm/huge_memory.c between commit 325adeb55e32 ("mm: huge_memory: Fix build
> error") from Linus' tree and commit 39d6cb39a817 ("mm/mpol: Use special
> PROT_NONE to migrate pages") from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Ok, this conflict should go away the next time you integrate
linux-next.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ 60/76] drm/nouveau/bios: fix shadowing of ACPI ROMs larger than 64KiB
On Fri, Oct 19, 2012 at 09:11:15PM +0200, Heinz Diehl wrote: > On 19.10.2012, Greg Kroah-Hartman wrote: > > > Does Linus's 3.7 git tree also crash for you this way? > > Yes, it crashes in the same way with latest linus git 3.7. > Here's the screenshot: > > http://www.fritha.org/crash-linus-git.jpg Ok, I've dropped it from the 3.6-stable release. Ben, when you all have a fix for this in Linus's tree, feel free to send me the two git commit ids and I'll queue them up. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/11] perf tool: Add PERF_SAMPLE_READ sample read support
* Jiri Olsa wrote:
> hi,
> adding support to read sample values through the PERF_SAMPLE_READ
> sample type. It's now possible to specify 'S' modifier for an event
> and get its sample value by PERF_SAMPLE_READ.
>
> For group the 'S' modifier will enable sampling only for the leader
> and read all the group member by PERF_SAMPLE_READ smple type with
> PERF_FORMAT_GROUP read format.
>
> This patchset is based on group report patches by Namhyung Kim:
> http://lwn.net/Articles/518569/
>
> Example:
> (making sample on cycles, reading both cycles and cache-misses
> by PERF_SAMPLE_READ/PERF_FORMAT_GROUP)
>
> # ./perf record -e '{cycles,cache-misses}:S' ls
> ...
>
> # ./perf report --group --show-total-period --stdio
> #
> # captured on: Sat Oct 20 16:53:39 2012
> ...
> # group: {cycles,cache-misses}
> #
> #
> # Samples: 86 of event 'anon group { cycles, cache-misses }'
> # Event count (approx.): 34863674
> #
> # OverheadPeriod Command Shared Object
> Symbol
> # ... .
>
Might make sense to consider this column enumeration:
#
# cycles
# | cache-misses
# | |
> # v v
> #
> 16.56% 19.47% 5773450 475 ls [kernel.kallsyms]
> [k] native_sched_clock
> 10.87% 0.74% 3789088 18 ls [kernel.kallsyms]
> [k] rtl8169_interrupt
>9.82% 15.86% 3423364 387 ls [kernel.kallsyms]
> [k] mark_lock
>8.43% 17.75% 2938384 433 ls ld-2.14.90.so
> [.] do_lookup_x
>6.79% 20.86% 2365622 509 ls ls
> [.] calculate_columns
>6.36% 0.61% 2216808 15 ls [kernel.kallsyms]
> [k] lock_release
> ...
/me wants this feature ASAP :-)
This should probably be the out of box default for perf record
and perf top as well - the cache miss rate is probably one of
the least appreciated aspects of overhead analysis.
Does it have sane output if the cache-misses event is not
supported? The cache-misses column should probably stay empty in
that case - basically falling back to today's default output.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] perf: SNB exclusive PMU access for INST_RETIRED:PREC_DIST
* Andi Kleen wrote: > > > > This isn't limited to admin, right? So the above turns into a DoS on the > > > > console. > > > > > > > Ok, so how about a WARN_ON_ONCE() instead? > > > > That should be fine I guess ;-) > > imho there is need for a generic mechanism to return an error > string to the user program without such hacks. Agreed - we could return an 'extended errno' long error return value, which in reality is a pointer to an error string (in perf_attr::error_str), and copy that string to user-space at perf syscall return time. Thus error-string aware tooling could print the error string. So PMU drivers could do something obvious like: return (long)"perf: INST_RETIRED.PREC_DIST only works in exclusive mode"; The perf syscall notices these pointers by noticing that the error code returned is outside the errno range. Old userspace will get a -EINVAL and no string copied into the error string buffer. New userspace would get the error string copied into perf_attr::error_str, plus a 'normal' -EINVAL error code. The only cost on the kernel side is to make sure all "string errors" are returned as long. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On Sun, Oct 21, 2012 at 11:59:36AM +, Artem S. Tashkinov wrote: > http://imageshack.us/a/img685/9452/panicz.jpg > > list_del corruption. prev->next should be ... but was ... Btw, this is one of the debug options I told you to enable. > I cannot show you more as I have no serial console to use :( and the kernel > doesn't have enough time to push error messages to rsyslog and fsync > /var/log/messages I already told you how to catch that oops: boot with "pause_on_oops=600" on the kernel command line and photograph the screen when the first oops happens. This'll show us where the problem begins. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sun, Oct 21, 2012 at 5:49 PM, Marcin Slusarz wrote: > > I know. But this bug is not about broken firmware. It's about Linux kernel > ACPI implementation, which (I think) wrongly interprets ACPI script. Hmm. Len, care to comment? Marcin quoted the AML and our arguments in an earlier thing. I don't read AML, so I was assuming it's the AML itself that was buggy, not our interpretation of it.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Linux KVM tool for v3.7-rc0
On Sun, Oct 21, 2012 at 05:03:05PM +0200, Ingo Molnar wrote: > The best way to compare them would be a script that gives exactly the > same test environment that 'vm run' / 'vm sandbox' does out of box, > but using qemu. > > If such a script is available then that would certainly be a useful > testing option to kernel developers. Right, I gotta say, I've mucked around with qemu/kvm net options as a novice user and haven't always been successfu. If you get host networking straight away in lkvm then that's another clear point for tools/kvm. Same holds true for copying data back and forth between host and guest. Thanks. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 3.6.3
I'm announcing the release of the 3.6.3 kernel. All users of the 3.6 kernel series must upgrade. The updated 3.6.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.6.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 arch/arm/Kconfig| 10 + arch/arm/include/asm/vfpmacros.h|4 arch/arm/mm/cache-v7.S |3 arch/arm/plat-omap/counter_32k.c| 21 +- arch/mips/ath79/clock.c | 109 ++ arch/mips/include/asm/mach-ath79/ar71xx_regs.h | 23 +++ arch/mips/kernel/kgdb.c |9 + arch/x86/Makefile |2 arch/x86/xen/enlighten.c| 18 ++ block/blk-core.c|2 drivers/acpi/ec.c | 30 +++- drivers/char/tpm/tpm.c | 21 +- drivers/firewire/core-cdev.c|4 drivers/gpu/drm/i915/i915_gem.c |1 drivers/gpu/drm/i915/i915_reg.h |2 drivers/gpu/drm/i915/intel_display.c|4 drivers/gpu/drm/i915/intel_pm.c |4 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |6 drivers/md/raid10.c |2 drivers/mtd/nand/nand_base.c|8 - drivers/net/ethernet/intel/e1000e/e1000.h |6 drivers/net/ethernet/intel/e1000e/netdev.c |2 drivers/net/usb/mcs7830.c | 30 ++-- drivers/net/wireless/ath/ath9k/beacon.c |2 drivers/net/wireless/ath/ath9k/main.c |2 drivers/net/wireless/ath/ath9k/xmit.c | 53 +++ drivers/scsi/qla2xxx/qla_target.c |2 drivers/scsi/scsi_debug.c |2 drivers/scsi/storvsc_drv.c |5 drivers/scsi/virtio_scsi.c |2 drivers/target/iscsi/iscsi_target.c |2 drivers/target/iscsi/iscsi_target_core.h|4 drivers/target/iscsi/iscsi_target_tpg.c | 12 + drivers/target/target_core_configfs.c |8 - drivers/target/target_core_file.c | 41 + drivers/target/target_core_file.h |1 drivers/target/target_core_spc.c| 48 +- drivers/tty/vt/vt.c | 13 + drivers/usb/class/cdc-acm.c |3 drivers/usb/gadget/at91_udc.c |2 drivers/vfio/pci/vfio_pci_intrs.c | 18 ++ drivers/video/udlfb.c |2 drivers/video/via/via_clock.c | 19 ++ drivers/xen/xenbus/xenbus_xs.c | 21 ++ fs/autofs4/root.c |6 fs/ceph/export.c| 18 +- fs/gfs2/export.c|4 fs/isofs/export.c |2 fs/jbd/commit.c | 45 -- fs/jbd/transaction.c| 64 +--- fs/lockd/mon.c | 86 +-- fs/lockd/netns.h|4 fs/lockd/svc.c |1 fs/namei.c |2 fs/nfs/blocklayout/blocklayout.c| 177 ++-- fs/nfs/blocklayout/blocklayout.h|1 fs/nfs/client.c |1 fs/nfs/nfs4proc.c |9 + fs/nfsd/nfs4idmap.c |2 fs/nfsd/nfs4state.c | 19 ++ fs/reiserfs/inode.c |6 fs/xfs/xfs_export.c |3 include/linux/mtd/nand.h|3 kernel/audit.c |2 kernel/debug/kdb/kdb_io.c | 33 +++- kernel/module.c |4 kernel/time/tick-sched.c|2 kernel/time/timekeeping.c |2 kernel/timer.c | 10 - mm/shmem.c |6 net/core/pktgen.c |2 net/mac80211/status.c |4 net/mac80211/tx.c | 22 +- net/sunrpc/xprtsock.c | 21 ++ scripts/Makefile.fwinst |4 sound/pci/ac97/ac97_codec.c |2 sound/pci/emu10k1/emu10k1_main.c|9 + sound/pci/hda
Linux 3.0.47
I'm announcing the release of the 3.0.47 kernel.
All users of the 3.0 kernel series must upgrade.
The updated 3.0.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.0.y
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
Documentation/kernel-parameters.txt |5 +
Makefile|2
arch/arm/Kconfig| 10 +++
arch/arm/include/asm/vfpmacros.h|4 -
arch/arm/mm/cache-v7.S |3
arch/mips/kernel/kgdb.c |9 ++
arch/x86/Kconfig|9 ++
arch/x86/include/asm/archrandom.h | 75
arch/x86/kernel/cpu/Makefile|1
arch/x86/kernel/cpu/common.c|2
arch/x86/kernel/cpu/rdrand.c| 73 +++
arch/x86/xen/enlighten.c| 18 +
block/blk-core.c|2
drivers/acpi/ec.c | 30 -
drivers/char/tpm/tpm.c | 21 --
drivers/firewire/core-cdev.c|4 -
drivers/gpu/drm/radeon/radeon_legacy_encoders.c |6 -
drivers/net/tg3.c |5 -
drivers/usb/class/cdc-acm.c |3
drivers/video/udlfb.c |2
drivers/video/via/via_clock.c | 19 ++
fs/autofs4/root.c |6 +
fs/ceph/export.c| 18 -
fs/gfs2/export.c|4 +
fs/isofs/export.c |2
fs/jbd/commit.c | 45 ++
fs/jbd/transaction.c| 64 ++--
fs/lockd/mon.c |4 -
fs/reiserfs/inode.c |6 +
fs/udf/super.c |5 +
fs/xfs/linux-2.6/xfs_export.c |3
include/net/ip_vs.h |2
include/net/netfilter/nf_conntrack_ecache.h |1
kernel/module.c |4 +
kernel/timer.c | 10 +--
mm/shmem.c |6 +
net/core/pktgen.c |2
net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c |8 ++
net/ipv4/netfilter/nf_nat_sip.c | 10 ++-
net/netfilter/ipvs/ip_vs_ctl.c |5 -
net/netfilter/nf_conntrack_core.c | 16 +++--
net/netfilter/nf_conntrack_expect.c | 29 +
net/netfilter/xt_hashlimit.c|8 --
net/netfilter/xt_limit.c| 13 +---
net/sunrpc/xprtsock.c | 21 +-
sound/pci/ac97/ac97_codec.c |2
sound/pci/emu10k1/emu10k1_main.c|9 ++
47 files changed, 480 insertions(+), 126 deletions(-)
Alexander Holler (1):
video/udlfb: fix line counting in fb_write
Amerigo Wang (1):
pktgen: fix crash when generating IPv6 packets
Daniel Drake (1):
viafb: don't touch clock state on OLPC XO-1.5
Egbert Eich (1):
drm/radeon: Don't destroy I2C Bus Rec in radeon_ext_tmds_enc_destroy().
Feng Tang (2):
ACPI: EC: Make the GPE storm threshold a module parameter
ACPI: EC: Add a quirk for CLEVO M720T/M730T laptop
Florian Westphal (1):
netfilter: limit, hashlimit: avoid duplicated inline
Greg Kroah-Hartman (1):
Linux 3.0.47
H. Peter Anvin (2):
x86, random: Architectural inlines to get random integers with RDRAND
x86, random: Verify RDRAND functionality and allow it to be disabled
Hildner, Christian (1):
timers: Fix endless looping between cascade() and internal_add_timer()
Hugh Dickins (1):
tmpfs,ceph,gfs2,isofs,reiserfs,xfs: fix fh_len checking
Ian Kent (1):
autofs4 - fix reset pending flag on mount fail
Jan Engelhardt (1):
netfilter: xt_limit: have r->cost != 0 case work
Jan Kara (1):
jbd: Fix assertion failure in commit code due to lacking transaction
credits
Jason Wessel (1):
mips,kgdb: fix recursive page fault with CONFIG_KPROBES
Jean-Christian de Rivaz (1):
Add CDC-ACM support for the CX93010-2x UCMxx USB Modem
Jozsef Kadlecsik (1):
netfilter: nf_ct_ipv4: packets with wrong ihl are invalid
Julian Anastasov (1):
ipvs: fix oops in ip_vs_dst_event on rmmod
Konrad Rzeszutek Wilk (2):
xen/bootup: allow {read|write}_cr8 pvops call.
xen/bootup: allow read_tscp call for Xen PV guests.
Lin Ming (1):
ipvs: fix oops on N
Re: Linux 3.0.47
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index aa47be7..397ee05 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1764,6 +1764,11 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
noresidual [PPC] Don't use residual data on PReP machines.
+ nordrand[X86] Disable the direct use of the RDRAND
+ instruction even if it is supported by the
+ processor. RDRAND is still available to user
+ space applications.
+
noresume[SWSUSP] Disables resume and restores original swap
space.
diff --git a/Makefile b/Makefile
index 1cb8c1d..82f6dfe 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 0
-SUBLEVEL = 46
+SUBLEVEL = 47
EXTRAVERSION =
NAME = Sneaky Weasel
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 157781e..17d179c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1260,6 +1260,16 @@ config PL310_ERRATA_769419
on systems with an outer cache, the store buffer is drained
explicitly.
+config ARM_ERRATA_775420
+ bool "ARM errata: A data cache maintenance operation which aborts,
might lead to deadlock"
+ depends on CPU_V7
+ help
+This option enables the workaround for the 775420 Cortex-A9 (r2p2,
+r2p6,r2p8,r2p10,r3p0) erratum. In case a date cache maintenance
+operation aborts with MMU exception, it might cause the processor
+to deadlock. This workaround puts DSB before executing ISB if
+an abort may occur on cache maintenance.
+
endmenu
source "arch/arm/common/Kconfig"
diff --git a/arch/arm/include/asm/vfpmacros.h b/arch/arm/include/asm/vfpmacros.h
index 3d5fc41..bf53047 100644
--- a/arch/arm/include/asm/vfpmacros.h
+++ b/arch/arm/include/asm/vfpmacros.h
@@ -28,7 +28,7 @@
ldr \tmp, =elf_hwcap@ may not have MVFR regs
ldr \tmp, [\tmp, #0]
tst \tmp, #HWCAP_VFPv3D16
- ldceq p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31}
+ ldceql p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31}
addne \base, \base, #32*4 @ step over unused register
space
#else
VFPFMRX \tmp, MVFR0 @ Media and VFP Feature
Register 0
@@ -52,7 +52,7 @@
ldr \tmp, =elf_hwcap@ may not have MVFR regs
ldr \tmp, [\tmp, #0]
tst \tmp, #HWCAP_VFPv3D16
- stceq p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31}
+ stceql p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31}
addne \base, \base, #32*4 @ step over unused register
space
#else
VFPFMRX \tmp, MVFR0 @ Media and VFP Feature
Register 0
diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
index 1ed1fd3..428b243 100644
--- a/arch/arm/mm/cache-v7.S
+++ b/arch/arm/mm/cache-v7.S
@@ -211,6 +211,9 @@ ENTRY(v7_coherent_user_range)
* isn't mapped, just try the next page.
*/
9001:
+#ifdef CONFIG_ARM_ERRATA_775420
+ dsb
+#endif
mov r12, r12, lsr #12
mov r12, r12, lsl #12
add r12, r12, #4096
diff --git a/arch/mips/kernel/kgdb.c b/arch/mips/kernel/kgdb.c
index f4546e9..23817a6 100644
--- a/arch/mips/kernel/kgdb.c
+++ b/arch/mips/kernel/kgdb.c
@@ -283,6 +283,15 @@ static int kgdb_mips_notify(struct notifier_block *self,
unsigned long cmd,
struct pt_regs *regs = args->regs;
int trap = (regs->cp0_cause & 0x7c) >> 2;
+#ifdef CONFIG_KPROBES
+ /*
+* Return immediately if the kprobes fault notifier has set
+* DIE_PAGE_FAULT.
+*/
+ if (cmd == DIE_PAGE_FAULT)
+ return NOTIFY_DONE;
+#endif /* CONFIG_KPROBES */
+
/* Userspace events, ignore. */
if (user_mode(regs))
return NOTIFY_DONE;
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 37357a5..a0e9bda 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1451,6 +1451,15 @@ config ARCH_USES_PG_UNCACHED
def_bool y
depends on X86_PAT
+config ARCH_RANDOM
+ def_bool y
+ prompt "x86 architectural random number generator" if EXPERT
+ ---help---
+ Enable the x86 architectural RDRAND instruction
+ (Intel Bull Mountain technology) to generate random numbers.
+ If supported, this is a high bandwidth, cryptographically
+ secure hardware random number generator.
+
config EFI
bool "EFI runtime service support"
depends on ACPI
diff --git a/arch/x86/include/asm/archrandom.h
b/arch/x86/include/asm/archrandom.h
new file mode 100644
index 000..0d9ec77
--- /dev/null
+++ b/arch/x86/include/asm/archrandom.h
@@ -0,0 +1,75 @@
+/*
+ * This file is part of the Linux kernel.
+
Linux 3.4.15
I'm announcing the release of the 3.4.15 kernel. All users of the 3.4 kernel series must upgrade. The updated 3.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.4.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 arch/arm/Kconfig| 10 ++ arch/arm/include/asm/vfpmacros.h|4 arch/arm/mm/cache-v7.S |3 arch/mips/kernel/kgdb.c |9 ++ arch/x86/xen/enlighten.c| 18 block/blk-core.c|2 drivers/acpi/ec.c | 30 ++- drivers/char/tpm/tpm.c | 21 +++-- drivers/firewire/core-cdev.c|4 drivers/gpu/drm/i915/intel_display.c|4 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |6 - drivers/md/raid10.c |2 drivers/net/ethernet/intel/e1000e/e1000.h |6 - drivers/net/ethernet/intel/e1000e/netdev.c |2 drivers/net/wireless/ath/ath9k/beacon.c |2 drivers/net/wireless/ath/ath9k/main.c |2 drivers/net/wireless/ath/ath9k/xmit.c | 53 ++-- drivers/scsi/hpsa.c | 39 - drivers/scsi/hpsa.h |2 drivers/scsi/hpsa_cmd.h |1 drivers/scsi/scsi_debug.c |2 drivers/scsi/storvsc_drv.c |5 + drivers/target/iscsi/iscsi_target.c |2 drivers/target/iscsi/iscsi_target_core.h|4 drivers/target/iscsi/iscsi_target_tpg.c | 12 ++ drivers/target/target_core_configfs.c |8 + drivers/tty/vt/vt.c | 13 +++ drivers/usb/class/cdc-acm.c |3 drivers/usb/gadget/at91_udc.c |2 drivers/video/udlfb.c |2 drivers/video/via/via_clock.c | 19 fs/autofs4/root.c |6 - fs/ceph/export.c| 18 +++- fs/ecryptfs/ecryptfs_kernel.h |2 fs/ecryptfs/file.c | 100 +++- fs/ecryptfs/inode.c | 65 --- fs/ecryptfs/main.c |1 fs/ecryptfs/mmap.c | 39 +++-- fs/gfs2/export.c|4 fs/isofs/export.c |2 fs/jbd/commit.c | 45 -- fs/jbd/transaction.c| 64 ++- fs/lockd/mon.c |4 fs/nfsd/nfs4idmap.c |2 fs/nfsd/nfs4state.c |1 fs/reiserfs/inode.c |6 + fs/xfs/xfs_export.c |3 include/linux/netfilter/ipset/ip_set_timeout.h |4 include/net/ip_vs.h |2 include/net/netfilter/nf_conntrack_ecache.h |1 kernel/debug/kdb/kdb_io.c | 33 ++- kernel/module.c |4 kernel/timer.c | 10 +- mm/shmem.c |6 - net/core/pktgen.c |2 net/ipv4/netfilter/nf_nat_sip.c | 10 +- net/netfilter/ipvs/ip_vs_ctl.c |5 - net/netfilter/nf_conntrack_core.c | 16 ++- net/netfilter/nf_conntrack_expect.c | 29 +- net/netfilter/xt_hashlimit.c|8 - net/netfilter/xt_limit.c| 13 +-- net/netfilter/xt_set.c | 17 +++- net/sunrpc/xprtsock.c | 21 +++-- sound/pci/ac97/ac97_codec.c |2 sound/pci/emu10k1/emu10k1_main.c|9 ++ sound/pci/hda/patch_cirrus.c|6 - sound/pci/hda/patch_realtek.c |6 + sound/soc/codecs/wm2200.c |3 sound/soc/omap/omap-abe-twl6040.c |2 sound/soc/sh/fsi.c | 15 +-- 71 files changed, 583 insertions(+), 297 deletions(-) Alexander Holler (1): video/udlfb: fix line counting in fb_write Amerigo Wang (1): pktgen: fix crash when generating IPv6 packets Christoph Hellwig (1): iscsit: remove incorrect unlock in iscsit_build_sendtargets_resp Dan Carpenter (1): md/raid10: use correct limit variable Dan
Re: [GIT PULL] Linux KVM tool for v3.7-rc0
On 2012.10.21 at 19:15 +0200, Borislav Petkov wrote: > On Sun, Oct 21, 2012 at 05:03:05PM +0200, Ingo Molnar wrote: > > The best way to compare them would be a script that gives exactly the > > same test environment that 'vm run' / 'vm sandbox' does out of box, > > but using qemu. > > > > If such a script is available then that would certainly be a useful > > testing option to kernel developers. > > Right, > > I gotta say, I've mucked around with qemu/kvm net options as a novice > user and haven't always been successfu. If you get host networking > straight away in lkvm then that's another clear point for tools/kvm. > > Same holds true for copying data back and forth between host and guest. I'm agnostic about lkvm, but the following command does all the above: qemu-system-x86_64 -enable-kvm -net nic,vlan=0,model=virtio -net user -fsdev local,security_model=passthrough,id=root,path=/ -device virtio-9p-pci,id=root,fsdev=root,mount_tag=/dev/root -m 512 -smp 2 -kernel /usr/src/linux/arch/x86/boot/bzImage -nographic -append "init=/bin/zsh root=/dev/root console=ttyS0 kgdboc=ttyS0 rootflags=rw,trans=virtio rootfstype=9p ip=dhcp" If you want your host root-fs to be mounted rw (to copy data back and forth) you need to run to above as root and add "rw" to the kernel options. -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Linux KVM tool for v3.7-rc0
* Markus Trippelsdorf wrote: > On 2012.10.21 at 19:15 +0200, Borislav Petkov wrote: > > On Sun, Oct 21, 2012 at 05:03:05PM +0200, Ingo Molnar wrote: > > > The best way to compare them would be a script that gives exactly the > > > same test environment that 'vm run' / 'vm sandbox' does out of box, > > > but using qemu. > > > > > > If such a script is available then that would certainly be a useful > > > testing option to kernel developers. > > > > Right, > > > > I gotta say, I've mucked around with qemu/kvm net options as a novice > > user and haven't always been successfu. If you get host networking > > straight away in lkvm then that's another clear point for tools/kvm. > > > > Same holds true for copying data back and forth between host and guest. > > I'm agnostic about lkvm, but the following command does all the above: > > qemu-system-x86_64 -enable-kvm -net nic,vlan=0,model=virtio > -net user -fsdev > local,security_model=passthrough,id=root,path=/ -device > virtio-9p-pci,id=root,fsdev=root,mount_tag=/dev/root -m 512 > -smp 2 -kernel /usr/src/linux/arch/x86/boot/bzImage -nographic > -append "init=/bin/zsh root=/dev/root console=ttyS0 > kgdboc=ttyS0 rootflags=rw,trans=virtio rootfstype=9p ip=dhcp" > > If you want your host root-fs to be mounted rw (to copy data > back and forth) you need to run to above as root and add "rw" > to the kernel options. Why does it have to run as root? I run 'vm' unprivileged (other than /dev/kvm access). Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
