* Re: [PATCH] dm: use revalidate_disk to update device size after set_capacity
From: Jun'ichi Nomura @ 2010-10-20 5:42 UTC (permalink / raw)
To: device-mapper development, Mike Snitzer
In-Reply-To: <20101019220711.GA25169@redhat.com>
Hi Mike,
(10/20/10 07:07), Mike Snitzer wrote:
> Avoid taking md->bdev->bd_inode->i_mutex to update the DM block device's
> size. Doing so eliminates the potential for deadlock if an fsync is
> racing with a device resize.
>
> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
> ---
> drivers/md/dm.c | 5 +----
> 1 files changed, 1 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/md/dm.c b/drivers/md/dm.c
> index f934e98..fd315a7 100644
> --- a/drivers/md/dm.c
> +++ b/drivers/md/dm.c
> @@ -1995,10 +1995,7 @@ static void event_callback(void *context)
> static void __set_size(struct mapped_device *md, sector_t size)
> {
> set_capacity(md->disk, size);
> -
> - mutex_lock(&md->bdev->bd_inode->i_mutex);
> - i_size_write(md->bdev->bd_inode, (loff_t)size << SECTOR_SHIFT);
> - mutex_unlock(&md->bdev->bd_inode->i_mutex);
> + revalidate_disk(md->disk);
> }
Some concerns/questions:
- revalidate_disk() calls bdget() inside it.
Does bdget() no longer block on I/O?
Sometime ago, bdget() has been blocked by I_LOCK,
where process holding I_LOCK blocked by resize.
Since I_LOCK has disappeared, I suspect this might not
be a valid concern anymore.
FYI, past discussion on this topic:
http://www.redhat.com/archives/dm-devel/2007-October/msg00134.html
(it's not my intention to push the patch in the above URL)
- revalidate_disk() ends up with get_super():
revalidate_disk
check_disk_size_change
flush_disk
__invalidate_device
get_super
and get_super() takes sb->s_umount.
OTOH, there are codes which wait on I/O holding s_umount
exclusively. E.g. freeze_super() calls sync_filesystem().
So it seems there is a possible deadlock if you use
revalidate_disk from dm_swap_table.
I've been away from that part of the code for a while.
So it's nice if the above is just a false alarm...
Thanks,
--
Jun'ichi Nomura, NEC Corporation
^ permalink raw reply
* [Bug 22576] [KMS] mesa demo spectex broken on rv280
From: bugzilla-daemon @ 2010-10-20 5:43 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-22576-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=22576
--- Comment #16 from Andrew Randrianasulu <randrik@mail.ru> 2010-10-19 22:43:28 PDT ---
Created an attachment (id=39559)
--> (https://bugs.freedesktop.org/attachment.cgi?id=39559)
screenshot of corruption
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: nspr-4.7.1: race condition causing occasional build failure
From: Graham Gower @ 2010-10-20 5:43 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <4CBE2B7A.4040601@gmail.com>
On 10/20/2010 10:06 AM, Graham Gower wrote:
> The failure looks like this:
>
> make[3]: Entering directory `/mnt/oe/tmp/work/mipsel-oe-linux/nspr-4.7.1-r1/nspr-4.7.1/mozilla/nsprpub/pr/include/md'
> ../../../config/./nsinstall -R -m 444 ./_aix32.cfg ./_aix64.cfg ./_beos.cfg ./_bsdi.cfg ./_darwin.cfg ./_dgux.cfg ./_freebsd.cfg ./_hpux32.cfg ./_hpux64.cfg ./_irix32.cfg ./_irix64.cfg ./_linux.cfg ./_ncr.cfg ./_nec.cfg ./_netbsd.cfg ./_nextstep.cfg ./_nto.cfg ./_openbsd.cfg ./_openvms.cfg ./_os2.cfg ./_osf1.cfg ./_qnx.cfg ./_reliantunix.cfg ./_riscos.cfg ./_scoos.cfg ./_solaris.cfg ./_sony.cfg ./_sunos4.cfg ./_unixware.cfg ./_unixware7.cfg ./_win16.cfg ./_win95.cfg ./_winnt.cfg ../../../dist/include/nspr/md
> ../../../config/./nsinstall: ../../../config/./nsinstall: cannot execute binary file
> make[3]: *** [export] Error 126
>
Even with PARALLEL_MAKE and BB_NUMBER_THREADS commented out in my local.conf
I can reproduce the failure within a few minutes using the following loop.
while :; do
./bitbake.sh -b openembedded/recipes/mozilla/nspr_4.7.1.bb -c clean
./bitbake.sh -b openembedded/recipes/mozilla/nspr_4.7.1.bb -c compile || break
done
^ permalink raw reply
* [U-Boot] [PATCH v2 1/2] Adding fixed sdram setting for cornet_ds board
From: Kumar Gala @ 2010-10-20 5:46 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1287434810-11814-1-git-send-email-yorksun@freescale.com>
On Oct 18, 2010, at 3:46 PM, York Sun wrote:
> 800, 900, 1000, 1200MT/s data rate parameters are added for fixed sdram
> setting. SPD based parameters and fixed parameters can be toggled by hwconfig.
> To use fixed parameters,
>
> hwconfig=fsl_ddr:sdram=fixed
>
> To use SPD parameters,
>
> hwconfig=fsl_ddr:ctlr_intlv=cacheline,bank_intlv=cs0_cs1
>
> Signed-off-by: York Sun <yorksun@freescale.com>
> ---
> arch/powerpc/include/asm/fsl_ddr_sdram.h | 6 +
> board/freescale/corenet_ds/Makefile | 8 +-
> board/freescale/corenet_ds/corenet_ds.c | 15 --
> board/freescale/corenet_ds/ddr.c | 131 +++++++++++-
> board/freescale/corenet_ds/p3041ds_ddr.c | 14 ++
> board/freescale/corenet_ds/p4080ds_ddr.c | 356 ++++++++++++++++++++++++++++++
> board/freescale/corenet_ds/p5020ds_ddr.c | 18 ++
> include/configs/corenet_ds.h | 60 +-----
> 8 files changed, 529 insertions(+), 79 deletions(-)
> create mode 100644 board/freescale/corenet_ds/p3041ds_ddr.c
> create mode 100644 board/freescale/corenet_ds/p4080ds_ddr.c
> create mode 100644 board/freescale/corenet_ds/p5020ds_ddr.c
applied to 85xx, but removed p3041/p5020 stuff as its not upstream yet.
- k
^ permalink raw reply
* Re: [PATCH] OLPC: Add XO-1 suspend/resume support
From: Borislav Petkov @ 2010-10-20 5:47 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Daniel Drake, tglx@linutronix.de, mingo@redhat.com,
x86@kernel.org, dilinger@queued.net, linux-kernel@vger.kernel.org,
Borislav Petkov, Roedel, Joerg
In-Reply-To: <4CBE1781.1050000@zytor.com>
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Tue, Oct 19, 2010 at 06:11:13PM -0400
> On 10/19/2010 03:01 PM, Daniel Drake wrote:
> > Add code needed for basic suspend/resume of the XO-1 laptop.
> >
> > swsusp_pg_dir needs to be exposed as it is used by the assembly
> > code run in the wakeup path.
> >
>
> Okay... this is Yet Another Reason why we need to unify all the bloody
> trampoline page tables.
>
> What it comes down to is that there are several users which need a 1:1
> mapped pagetable and a chunk of memory < 1 MiB, and they should all be
> combined and linked together, and share a single pagetable set that
> sticks around.
>
> Borislav has already been doing some of this work:
>
> [PATCH] x86-32, mm: Add an initial page table for core bootstrapping
>
> I thought that patch was already in -tip, but it looks like it's not...
> Borislav/Joerg... was there a newer patch or did we just miss the final
> version? I remember we talked about this at some length, but it looks
> like I dropped the ball (I was on vacation when the above message was
> posted.)
The final version with fixed ACPI sleep is this one:
http://www.gossamer-threads.com/lists/linux/kernel/1270589
I ran it for a couple of weeks and it didn't show any regressions. If
you want to get it into the merge window, I can get you an updated
version against a -tip branch of your liking ASAP.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
^ permalink raw reply
* [U-Boot] [PATCH v2 2/2] Disable unused chip-select for DDR controller interleaving
From: Kumar Gala @ 2010-10-20 5:47 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1287434810-11814-2-git-send-email-yorksun@freescale.com>
On Oct 18, 2010, at 3:46 PM, York Sun wrote:
> When DDR controller interleaving is eabled and less than all bank (chip-select)
> interleaving is seletected, the unused chip-select should be disabled.
>
> Signed-off-by: York Sun <yorksun@freescale.com>
> ---
> arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c | 17 ++++++++++++++---
> 1 files changed, 14 insertions(+), 3 deletions(-)
applied to 85xx
- k
^ permalink raw reply
* [U-Boot] [PATCH RFC 1/4] ARMV7: OMAP: I2C driver: Use same timeout value as linux kernel driver
From: Heiko Schocher @ 2010-10-20 5:49 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1287462940-19496-2-git-send-email-steve@sakoman.com>
Hello Steve,
Steve Sakoman wrote:
> This patch matches the poll interval (1 millisecond) and timeout (1 second)
> used in the linux driver. It also adds a return value of 0 in the event of
> a timeout error and cleans up some formatting errors in that section of the
> code.
>
> Signed-off-by: Steve Sakoman <steve.sakoman@linaro.org>
> ---
> drivers/i2c/omap24xx_i2c.c | 14 ++++++++------
> 1 files changed, 8 insertions(+), 6 deletions(-)
Applied to u-boot-i2c master
Thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* [U-Boot] [PATCH RFC 2/4] ARMV7: OMAP: I2C driver: Restructure i2c_read_byte function
From: Heiko Schocher @ 2010-10-20 5:50 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1287462940-19496-3-git-send-email-steve@sakoman.com>
Hello Steve,
Steve Sakoman wrote:
> This patch removes the "magic number" delays and instead
> monitors state changes in the status register bits.
>
> Signed-off-by: Steve Sakoman <steve.sakomanlinaro.org>
> ---
> drivers/i2c/omap24xx_i2c.c | 76 +++++++++++++++++++++----------------------
> 1 files changed, 37 insertions(+), 39 deletions(-)
Applied to u-boot-i2c master
Thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* [U-Boot] facing issue in compiling latest u-boot for P1020RDB(powerpc)
From: Kumar Gala @ 2010-10-20 5:50 UTC (permalink / raw)
To: u-boot
In-Reply-To: <D6E175B6D647CC4E897E077D03FD4A5A2594AC@zin33exm22.fsl.freescale.net>
> bash-2.05a$ make P1020RDB_config
>
> Generating include/autoconf.mk
>
> Generating include/autoconf.mk.dep
>
> Configuring for P1020RDB - Board: P1_P2_RDB, Options: P1020RDB
>
> sed: -e expression #1, char 16: Extra characters after command
>
> make: *** [P1020RDB_config] Error 1
>
> bash-2.05a$
What's the version of sed you are running:
$ sed --version
I'm not seeing this error on my system (fedora 13 x86_64)
>
> By looking at git log, I can observe that there are some changes in
> Makefile and boards.cfg file.
>
> Is there is any change in config options for building power pc boards
> like P1020RDB, P2020RDB?
- k
^ permalink raw reply
* [U-Boot] [PATCH RFC 3/4] ARMV7: OMAP: I2C driver: Restructure i2c_write_byte function
From: Heiko Schocher @ 2010-10-20 5:50 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1287462940-19496-4-git-send-email-steve@sakoman.com>
Hello Steve,
Steve Sakoman wrote:
> This patch removes the "magic number" delays and instead
> monitors state changes in the status register bits.
>
> Signed-off-by: Steve Sakoman <steve.sakoman@linaro.org>
> ---
> drivers/i2c/omap24xx_i2c.c | 76 +++++++++++++++++++++++--------------------
> 1 files changed, 41 insertions(+), 35 deletions(-)
Applied to u-boot-i2c master
Thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* [U-Boot] [PATCH RFC 4/4] ARMV7: OMAP: I2C driver: Restructure i2c_probe function
From: Heiko Schocher @ 2010-10-20 5:51 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1287462940-19496-5-git-send-email-steve@sakoman.com>
Hello Steve,
Steve Sakoman wrote:
> This patch removes the "magic number" delays and instead
> monitors state changes in the status register bits.
>
> Signed-off-by: Steve Sakoman <steve.sakoman@linaro.org>
> ---
> drivers/i2c/omap24xx_i2c.c | 41 ++++++++++++++++++++++++++++++-----------
> 1 files changed, 30 insertions(+), 11 deletions(-)
Applied to u-boot-i2c master
Thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* [PATCH] Add Intel GMA500(Poulsbo) Stub Driver
From: Lee, Chun-Yi @ 2010-10-20 5:51 UTC (permalink / raw)
To: dri-devel
Cc: randy.dunlap, mjg59, gregkh, trenn, linux-acpi, linux-kernel,
Valdis.Kletnieks, Dennis.Jansen, airlied, airlied, eric,
alexdeucher, bskeggs, chris, Lee, Chun-Yi
Currently, there have no GMA500(Poulsbo) native video driver to support
intel opregion. So, use this stub driver to enable the acpi backlight
control sysfs entry files by requrest acpi_video_register.
Signed-off-by: Lee, Chun-Yi <jlee@novell.com>
---
drivers/gpu/Makefile | 2 +-
drivers/gpu/stub/Kconfig | 13 +++++++++
drivers/gpu/stub/Makefile | 1 +
drivers/gpu/stub/poulsbo.c | 63 ++++++++++++++++++++++++++++++++++++++++++++
drivers/video/Kconfig | 2 +
5 files changed, 80 insertions(+), 1 deletions(-)
create mode 100644 drivers/gpu/stub/Kconfig
create mode 100644 drivers/gpu/stub/Makefile
create mode 100644 drivers/gpu/stub/poulsbo.c
diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
index 30879df..cc92778 100644
--- a/drivers/gpu/Makefile
+++ b/drivers/gpu/Makefile
@@ -1 +1 @@
-obj-y += drm/ vga/
+obj-y += drm/ vga/ stub/
diff --git a/drivers/gpu/stub/Kconfig b/drivers/gpu/stub/Kconfig
new file mode 100644
index 0000000..8f5a540
--- /dev/null
+++ b/drivers/gpu/stub/Kconfig
@@ -0,0 +1,13 @@
+config STUB_POULSBO
+ tristate "Intel GMA500 Stub Driver"
+ depends on PCI
+ # Poulsbo stub depends on ACPI_VIDEO when ACPI is enabled
+ # but for select to work, need to select ACPI_VIDEO's dependencies, ick
+ select ACPI_VIDEO if ACPI
+ help
+ Choose this option if you have a system that has Intel GMA500
+ (Poulsbo) integrated graphics. If M is selected, the module will
+ be called Poulsbo. This driver is a stub driver for Poulsbo that
+ will call poulsbo.ko to enable the acpi backlight control sysfs
+ entry file because there have no poulsbo native driver can support
+ intel opregion.
diff --git a/drivers/gpu/stub/Makefile b/drivers/gpu/stub/Makefile
new file mode 100644
index 0000000..cd940cc
--- /dev/null
+++ b/drivers/gpu/stub/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_STUB_POULSBO) += poulsbo.o
diff --git a/drivers/gpu/stub/poulsbo.c b/drivers/gpu/stub/poulsbo.c
new file mode 100644
index 0000000..d8aa636
--- /dev/null
+++ b/drivers/gpu/stub/poulsbo.c
@@ -0,0 +1,63 @@
+/*
+ * Intel Poulsbo Stub driver
+ *
+ * Copyright (C) 2010 Novell <jlee@novell.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <acpi/video.h>
+
+#define DRIVER_NAME "poulsbo"
+
+enum {
+ CHIP_PSB_8108 = 0,
+ CHIP_PSB_8109 = 1,
+};
+
+static struct pci_device_id pciidlist[] = {
+ {0x8086, 0x8108, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PSB_8108}, \
+ {0x8086, 0x8109, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PSB_8109}, \
+ {0, 0, 0}
+};
+
+static int poulsbo_probe(struct pci_dev *pdev, const struct pci_device_id *id)
+{
+ return acpi_video_register();
+}
+
+static void poulsbo_remove(struct pci_dev *pdev)
+{
+ acpi_video_unregister();
+}
+
+static struct pci_driver poulsbo_driver = {
+ .name = DRIVER_NAME,
+ .id_table = pciidlist,
+ .probe = poulsbo_probe,
+ .remove = poulsbo_remove,
+};
+
+static int __init poulsbo_init(void)
+{
+ return pci_register_driver(&poulsbo_driver);
+}
+
+static void __exit poulsbo_exit(void)
+{
+ pci_unregister_driver(&poulsbo_driver);
+}
+
+module_init(poulsbo_init);
+module_exit(poulsbo_exit);
+
+MODULE_AUTHOR("Lee, Chun-Yi <jlee@novell.com>");
+MODULE_DESCRIPTION("Poulsbo Stub Driver");
+MODULE_LICENSE("GPL");
+
+MODULE_DEVICE_TABLE(pci, pciidlist);
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 8b31fdf..8807ae5 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -17,6 +17,8 @@ source "drivers/gpu/vga/Kconfig"
source "drivers/gpu/drm/Kconfig"
+source "drivers/gpu/stub/Kconfig"
+
config VGASTATE
tristate
default n
--
1.6.0.2
^ permalink raw reply related
* [PATCH] KVM Test: Set bootstatuspolicy to ignoreallfailures for Win2008 and r2 in autounattend.xml
From: Feng Yang @ 2010-10-20 5:53 UTC (permalink / raw)
To: autotest; +Cc: kvm, Feng Yang
Windows 2008 image is easy to go to startup repair screen, which make
many of our cases fail. This patch will disable startup repair screen
in win2008 which caused by shutdown failures.
Signed-off-by: Feng Yang <fyang@redhat.com>
---
.../kvm/unattended/win2008-32-autounattend.xml | 10 +++++++---
.../kvm/unattended/win2008-64-autounattend.xml | 10 +++++++---
.../kvm/unattended/win2008-r2-autounattend.xml | 10 +++++++---
3 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/client/tests/kvm/unattended/win2008-32-autounattend.xml b/client/tests/kvm/unattended/win2008-32-autounattend.xml
index 89af07f..7e8e160 100644
--- a/client/tests/kvm/unattended/win2008-32-autounattend.xml
+++ b/client/tests/kvm/unattended/win2008-32-autounattend.xml
@@ -149,16 +149,20 @@
<Order>5</Order>
</SynchronousCommand>
<SynchronousCommand wcm:action="add">
+ <CommandLine>%WINDIR%\System32\cmd /c bcdedit /set {current} bootstatuspolicy ignoreallfailures</CommandLine>
+ <Order>6</Order>
+ </SynchronousCommand>
+ <SynchronousCommand wcm:action="add">
<CommandLine>%WINDIR%\System32\cmd /c E:\setuprss.bat</CommandLine>
- <Order>6</Order>
+ <Order>7</Order>
</SynchronousCommand>
<SynchronousCommand wcm:action="add">
<CommandLine>%WINDIR%\System32\cmd /c netsh interface ip set address "Local Area Connection" dhcp</CommandLine>
- <Order>7</Order>
+ <Order>8</Order>
</SynchronousCommand>
<SynchronousCommand wcm:action="add">
<CommandLine>%WINDIR%\System32\cmd /c ping 10.0.2.2 -n 20 && A:\finish.exe</CommandLine>
- <Order>8</Order>
+ <Order>9</Order>
</SynchronousCommand>
</FirstLogonCommands>
<OOBE>
diff --git a/client/tests/kvm/unattended/win2008-64-autounattend.xml b/client/tests/kvm/unattended/win2008-64-autounattend.xml
index 98f5589..fce6582 100644
--- a/client/tests/kvm/unattended/win2008-64-autounattend.xml
+++ b/client/tests/kvm/unattended/win2008-64-autounattend.xml
@@ -158,17 +158,21 @@
<Order>5</Order>
</SynchronousCommand>
<SynchronousCommand wcm:action="add">
- <CommandLine>%WINDIR%\System32\cmd /c E:\setuprss.bat</CommandLine>
+ <CommandLine>%WINDIR%\System32\cmd /c bcdedit /set {current} bootstatuspolicy ignoreallfailures</CommandLine>
<Order>6</Order>
</SynchronousCommand>
<SynchronousCommand wcm:action="add">
- <CommandLine>%WINDIR%\System32\cmd /c netsh interface ip set address "Local Area Connection" dhcp</CommandLine>
+ <CommandLine>%WINDIR%\System32\cmd /c E:\setuprss.bat</CommandLine>
<Order>7</Order>
</SynchronousCommand>
<SynchronousCommand wcm:action="add">
- <CommandLine>%WINDIR%\System32\cmd /c ping 10.0.2.2 -n 20 && A:\finish.exe</CommandLine>
+ <CommandLine>%WINDIR%\System32\cmd /c netsh interface ip set address "Local Area Connection" dhcp</CommandLine>
<Order>8</Order>
</SynchronousCommand>
+ <SynchronousCommand wcm:action="add">
+ <CommandLine>%WINDIR%\System32\cmd /c ping 10.0.2.2 -n 20 && A:\finish.exe</CommandLine>
+ <Order>9</Order>
+ </SynchronousCommand>
</FirstLogonCommands>
<OOBE>
<HideEULAPage>true</HideEULAPage>
diff --git a/client/tests/kvm/unattended/win2008-r2-autounattend.xml b/client/tests/kvm/unattended/win2008-r2-autounattend.xml
index b624d10..948e9a1 100644
--- a/client/tests/kvm/unattended/win2008-r2-autounattend.xml
+++ b/client/tests/kvm/unattended/win2008-r2-autounattend.xml
@@ -158,17 +158,21 @@
<Order>5</Order>
</SynchronousCommand>
<SynchronousCommand wcm:action="add">
- <CommandLine>%WINDIR%\System32\cmd /c E:\setuprss.bat</CommandLine>
+ <CommandLine>%WINDIR%\System32\cmd /c bcdedit /set {current} bootstatuspolicy ignoreallfailures</CommandLine>
<Order>6</Order>
</SynchronousCommand>
<SynchronousCommand wcm:action="add">
- <CommandLine>%WINDIR%\System32\cmd /c netsh interface ip set address "Local Area Connection" dhcp</CommandLine>
+ <CommandLine>%WINDIR%\System32\cmd /c E:\setuprss.bat</CommandLine>
<Order>7</Order>
</SynchronousCommand>
<SynchronousCommand wcm:action="add">
- <CommandLine>%WINDIR%\System32\cmd /c ping 10.0.2.2 -n 20 && A:\finish.exe</CommandLine>
+ <CommandLine>%WINDIR%\System32\cmd /c netsh interface ip set address "Local Area Connection" dhcp</CommandLine>
<Order>8</Order>
</SynchronousCommand>
+ <SynchronousCommand wcm:action="add">
+ <CommandLine>%WINDIR%\System32\cmd /c ping 10.0.2.2 -n 20 && A:\finish.exe</CommandLine>
+ <Order>9</Order>
+ </SynchronousCommand>
</FirstLogonCommands>
<OOBE>
<HideEULAPage>true</HideEULAPage>
--
1.6.5.2
^ permalink raw reply related
* Re: read/write on RADOS using external buffer
From: Colin McCabe @ 2010-10-20 5:55 UTC (permalink / raw)
To: Sage Weil; +Cc: Takuya ASADA, ceph-devel
In-Reply-To: <Pine.LNX.4.64.1010192059070.21300@cobra.newdream.net>
On Tue, Oct 19, 2010 at 9:26 PM, Sage Weil <sage@newdream.net> wrote:
> - SimpleMessenger::read_message() just needs to call
> ms_deliver_get_data_buffer() if data_len > 0. If it returns true, use the
> provided bufferptr.
>
> - The existing Objecter::read() method returns the tid, which librados
> can then store in a private map of tid -> bufferptrs. When it's
> ms_get_data_buffer() is called it can provide the bufferptr; no need to
> modify the Objecter at all! Just make sure to verify that the entry
> exists in the map before using the operator[] (use find()).
If we want thread-local data, we should at least use
pthread_setspecific / pthread_getspecific. No need for tids and STL
maps. gettid() is a syscall and it will be slow.
> The main corner case is this: if there is some osd cluster change, it's
> theoretically possible we could have two threads reading read replies to
> the same request off the wire at the same time. Even if we carefully
> define which reply "wins", we need to make sure there isn't a stray thread
> read/accessing the buffer after the read() call returns.
I just don't see why we have to care about threads at all. If we need
rados client-specific data, it should definitely be in class
RadosClient. Otherwise, we should just get rid of class RadosClient,
because it's useless.
> I'm not sure what the solution to that one is yet. The kclient doesn't
> have separate threads, and takes pains to yank the pages out from under
> incoming message; that approach doesn't work well with the SimpleMessenger
> threading model. :/
I think I can propose a patch which solves this problem without rados
client-specific data, threads, tids, maps, thread-local data, or
changes to SimpleMessenger. It will just involve modifying bufferlist
so that it can use a buffer that's passed to it, rather than
allocating its own. Then we need something like a freeze operation
that will stop it from trying to reallocate or resize the buffer. This
solution will have much more generality and probably will be useful
elsewhere too.
Colin
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ARMV7: OMAP: I2C driver: fix compiler warning
From: Heiko Schocher @ 2010-10-20 5:57 UTC (permalink / raw)
To: u-boot
Signed-off-by: Heiko Schocher <hs@denx.de>
---
drivers/i2c/omap24xx_i2c.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index eb153fb..a72d1a1 100644
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -218,7 +218,7 @@ read_exit:
static int i2c_write_byte (u8 devaddr, u8 regoffset, u8 value)
{
int i2c_error = 0;
- u16 status, stat;
+ u16 status;
/* wait until bus not busy */
wait_for_bb ();
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply related
* [U-Boot] facing issue in compiling latest u-boot for P1020RDB(powerpc)
From: Jain Priyanka-B32167 @ 2010-10-20 5:57 UTC (permalink / raw)
To: u-boot
In-Reply-To: <7A17DD04-BF0D-4BE8-A38E-716A774AE1DB@kernel.crashing.org>
sed version on my machine is GNU 3.02
Regards
Priyanka
-----Original Message-----
From: Kumar Gala [mailto:galak at kernel.crashing.org]
Sent: Wednesday, October 20, 2010 11:20 AM
To: Jain Priyanka-B32167
Cc: u-boot at lists.denx.de
Subject: Re: [U-Boot] facing issue in compiling latest u-boot for
P1020RDB(powerpc)
> bash-2.05a$ make P1020RDB_config
>
> Generating include/autoconf.mk
>
> Generating include/autoconf.mk.dep
>
> Configuring for P1020RDB - Board: P1_P2_RDB, Options: P1020RDB
>
> sed: -e expression #1, char 16: Extra characters after command
>
> make: *** [P1020RDB_config] Error 1
>
> bash-2.05a$
What's the version of sed you are running:
$ sed --version
I'm not seeing this error on my system (fedora 13 x86_64)
>
> By looking at git log, I can observe that there are some changes in
> Makefile and boards.cfg file.
>
> Is there is any change in config options for building power pc boards
> like P1020RDB, P2020RDB?
- k
^ permalink raw reply
* Re: Deadlock possibly caused by too_many_isolated.
From: Wu Fengguang @ 2010-10-20 5:57 UTC (permalink / raw)
To: Torsten Kaiser
Cc: Neil Brown, Rik van Riel, Andrew Morton, KOSAKI Motohiro,
KAMEZAWA Hiroyuki, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Li, Shaohua
In-Reply-To: <AANLkTimVu+5gTDs8przJVP2EbWC=FX-zWW7aH08BtrHC@mail.gmail.com>
On Tue, Oct 19, 2010 at 06:06:21PM +0800, Torsten Kaiser wrote:
> On Tue, Oct 19, 2010 at 10:43 AM, Torsten Kaiser
> <just.for.lkml@googlemail.com> wrote:
> > On Tue, Oct 19, 2010 at 1:11 AM, Neil Brown <neilb@suse.de> wrote:
> >> Yes, thanks for the report.
> >> This is a real bug exactly as you describe.
> >>
> >> This is how I think I will fix it, though it needs a bit of review and
> >> testing before I can be certain.
> >> Also I need to check raid10 etc to see if they can suffer too.
> >>
> >> If you can test it I would really appreciate it.
> >
> > I did test it, but while it seemed to fix the deadlock, the system
> > still got unusable.
> > The still running "vmstat 1" showed that the swapout was still
> > progressing, but at a rate of ~20k sized bursts every 5 to 20 seconds.
> >
> > I also tried to additionally add Wu's patch:
> > --- linux-next.orig/mm/vmscan.c 2010-10-13 12:35:14.000000000 +0800
> > +++ linux-next/mm/vmscan.c 2010-10-19 00:13:04.000000000 +0800
> > @@ -1163,6 +1163,13 @@ static int too_many_isolated(struct zone
> > isolated = zone_page_state(zone, NR_ISOLATED_ANON);
> > }
> >
> > + /*
> > + * GFP_NOIO/GFP_NOFS callers are allowed to isolate more pages, so that
> > + * they won't get blocked by normal ones and form circular deadlock.
> > + */
> > + if ((sc->gfp_mask & GFP_IOFS) == GFP_IOFS)
> > + inactive >>= 3;
> > +
> > return isolated > inactive;
> >
> > Either it did help somewhat, or I was more lucky on my second try, but
> > this time I needed ~5 tries instead of only 2 to get the system mostly
> > stuck again. On the testrun with Wu's patch the writeout pattern was
> > more stable, a burst of ~80kb each 20 seconds. But I would suspect
> > that the size of the burst is rather random.
> >
> > I do have a complete SysRq+T dump from the first run, I can send that
> > to anyone how wants it.
> > (It's 190k so I don't want not spam it to the list)
>
> Is this call trace from the SysRq+T violation the rule to only
> allocate one bio from bio_alloc() until its submitted?
>
> [ 549.700038] Call Trace:
> [ 549.700038] [<ffffffff81566b54>] schedule_timeout+0x144/0x200
> [ 549.700038] [<ffffffff81045cd0>] ? process_timeout+0x0/0x10
> [ 549.700038] [<ffffffff81565e22>] io_schedule_timeout+0x42/0x60
> [ 549.700038] [<ffffffff81083123>] mempool_alloc+0x163/0x1b0
> [ 549.700038] [<ffffffff81053560>] ? autoremove_wake_function+0x0/0x40
> [ 549.700038] [<ffffffff810ea2b9>] bio_alloc_bioset+0x39/0xf0
> [ 549.700038] [<ffffffff810ea38d>] bio_clone+0x1d/0x50
> [ 549.700038] [<ffffffff814318ed>] make_request+0x23d/0x850
> [ 549.700038] [<ffffffff81082e20>] ? mempool_alloc_slab+0x10/0x20
> [ 549.700038] [<ffffffff81045cd0>] ? process_timeout+0x0/0x10
> [ 549.700038] [<ffffffff81436e63>] md_make_request+0xc3/0x220
> [ 549.700038] [<ffffffff81083099>] ? mempool_alloc+0xd9/0x1b0
> [ 549.700038] [<ffffffff811ec153>] generic_make_request+0x1b3/0x370
> [ 549.700038] [<ffffffff810ea2d6>] ? bio_alloc_bioset+0x56/0xf0
> [ 549.700038] [<ffffffff811ec36a>] submit_bio+0x5a/0xd0
> [ 549.700038] [<ffffffff81080cf5>] ? unlock_page+0x25/0x30
> [ 549.700038] [<ffffffff810a871e>] swap_writepage+0x7e/0xc0
> [ 549.700038] [<ffffffff81090d99>] shmem_writepage+0x1c9/0x240
> [ 549.700038] [<ffffffff8108c9cb>] pageout+0x11b/0x270
> [ 549.700038] [<ffffffff8108cd78>] shrink_page_list+0x258/0x4d0
> [ 549.700038] [<ffffffff8108d9e7>] shrink_inactive_list+0x187/0x310
> [ 549.700038] [<ffffffff8102dcb1>] ? __wake_up_common+0x51/0x80
> [ 549.700038] [<ffffffff811fc8b2>] ? cpumask_next_and+0x22/0x40
> [ 549.700038] [<ffffffff8108e1c0>] shrink_zone+0x3e0/0x470
> [ 549.700038] [<ffffffff8108e797>] try_to_free_pages+0x157/0x410
> [ 549.700038] [<ffffffff81087c92>] __alloc_pages_nodemask+0x412/0x760
> [ 549.700038] [<ffffffff810b27d6>] alloc_pages_current+0x76/0xe0
> [ 549.700038] [<ffffffff810b6dad>] new_slab+0x1fd/0x2a0
> [ 549.700038] [<ffffffff81045cd0>] ? process_timeout+0x0/0x10
> [ 549.700038] [<ffffffff810b8721>] __slab_alloc+0x111/0x540
> [ 549.700038] [<ffffffff81059961>] ? prepare_creds+0x21/0xb0
> [ 549.700038] [<ffffffff810b92bb>] kmem_cache_alloc+0x9b/0xa0
> [ 549.700038] [<ffffffff81059961>] prepare_creds+0x21/0xb0
> [ 549.700038] [<ffffffff8104a919>] sys_setresgid+0x29/0x120
> [ 549.700038] [<ffffffff8100242b>] system_call_fastpath+0x16/0x1b
> [ 549.700038] ffff88011e125ea8 0000000000000046 ffff88011e125e08
> ffffffff81073c59
> [ 549.700038] 0000000000012780 ffff88011ea905b0 ffff88011ea90808
> ffff88011e125fd8
> [ 549.700038] ffff88011ea90810 ffff88011e124010 0000000000012780
> ffff88011e125fd8
>
> swap_writepage() uses get_swap_bio() which uses bio_alloc() to get one
> bio. That bio is the submitted, but the submit path seems to get into
> make_request from raid1.c and that allocates a second bio from
> bio_alloc() via bio_clone().
>
> I am seeing this pattern (swap_writepage calling
> md_make_request/make_request and then getting stuck in mempool_alloc)
> more than 5 times in the SysRq+T output...
I bet the root cause is the failure of pool->alloc(__GFP_NORETRY)
inside mempool_alloc(), which can be fixed by this patch.
Thanks,
Fengguang
---
concurrent direct page reclaim problem
__GFP_NORETRY page allocations may fail when there are many concurrent page
allocating tasks, but not necessary in real short of memory. The root cause
is, tasks will first run direct page reclaim to free some pages from the LRU
lists and put them to the per-cpu page lists and the buddy system, and then
try to get a free page from there. However the free pages reclaimed by this
task may be consumed by other tasks when the direct reclaim task is able to
get the free page for itself.
Let's retry it a bit harder.
--- linux-next.orig/mm/page_alloc.c 2010-10-20 13:44:50.000000000 +0800
+++ linux-next/mm/page_alloc.c 2010-10-20 13:50:54.000000000 +0800
@@ -1700,7 +1700,7 @@ should_alloc_retry(gfp_t gfp_mask, unsig
unsigned long pages_reclaimed)
{
/* Do not loop if specifically requested */
- if (gfp_mask & __GFP_NORETRY)
+ if (gfp_mask & __GFP_NORETRY && pages_reclaimed > (1 << (order + 12)))
return 0;
/*
^ permalink raw reply
* [PATCH v2] t/gitweb-lib: Don't pass constant to decode_utf8
From: Brian Gernhardt @ 2010-10-20 5:57 UTC (permalink / raw)
To: Git List; +Cc: Jakub Narebski, Sven Verdoolaege, Junio C Hamano
Encode.pm started updating the string to decode in-place when a second
argument is passed in version 2.40. This causes 'decode_utf8("",
Encode::FB_CROAK)' to die with a message like:
Modification of a read-only value attempted at
/Library/Perl/Updates/5.10.0/darwin-thread-multi-2level/Encode.pm line
216.
Work around this by passing an empty variable instead of a constant
string.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
---
Changes since v1:
- Use an explicitly empty variable instead of $_
- Clearer commit message
- CC people who worked on t/gitweb-lib.sh
- based against maint
t/gitweb-lib.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/gitweb-lib.sh b/t/gitweb-lib.sh
index 81ef2a0..1b9523d 100644
--- a/t/gitweb-lib.sh
+++ b/t/gitweb-lib.sh
@@ -80,7 +80,7 @@ if ! test_have_prereq PERL; then
test_done
fi
-perl -MEncode -e 'decode_utf8("", Encode::FB_CROAK)' >/dev/null 2>&1 || {
+perl -MEncode -e '$e="";decode_utf8($e, Encode::FB_CROAK)' >/dev/null 2>&1 || {
skip_all='skipping gitweb tests, perl version is too old'
test_done
}
--
1.7.3.1.209.g52408
^ permalink raw reply related
* Re: Deadlock possibly caused by too_many_isolated.
From: Wu Fengguang @ 2010-10-20 5:57 UTC (permalink / raw)
To: Torsten Kaiser
Cc: Neil Brown, Rik van Riel, Andrew Morton, KOSAKI Motohiro,
KAMEZAWA Hiroyuki, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Li, Shaohua
In-Reply-To: <AANLkTimVu+5gTDs8przJVP2EbWC=FX-zWW7aH08BtrHC@mail.gmail.com>
On Tue, Oct 19, 2010 at 06:06:21PM +0800, Torsten Kaiser wrote:
> On Tue, Oct 19, 2010 at 10:43 AM, Torsten Kaiser
> <just.for.lkml@googlemail.com> wrote:
> > On Tue, Oct 19, 2010 at 1:11 AM, Neil Brown <neilb@suse.de> wrote:
> >> Yes, thanks for the report.
> >> This is a real bug exactly as you describe.
> >>
> >> This is how I think I will fix it, though it needs a bit of review and
> >> testing before I can be certain.
> >> Also I need to check raid10 etc to see if they can suffer too.
> >>
> >> If you can test it I would really appreciate it.
> >
> > I did test it, but while it seemed to fix the deadlock, the system
> > still got unusable.
> > The still running "vmstat 1" showed that the swapout was still
> > progressing, but at a rate of ~20k sized bursts every 5 to 20 seconds.
> >
> > I also tried to additionally add Wu's patch:
> > --- linux-next.orig/mm/vmscan.c 2010-10-13 12:35:14.000000000 +0800
> > +++ linux-next/mm/vmscan.c A A A 2010-10-19 00:13:04.000000000 +0800
> > @@ -1163,6 +1163,13 @@ static int too_many_isolated(struct zone
> > A A A A A A A isolated = zone_page_state(zone, NR_ISOLATED_ANON);
> > A A A }
> >
> > + A A A /*
> > + A A A A * GFP_NOIO/GFP_NOFS callers are allowed to isolate more pages, so that
> > + A A A A * they won't get blocked by normal ones and form circular deadlock.
> > + A A A A */
> > + A A A if ((sc->gfp_mask & GFP_IOFS) == GFP_IOFS)
> > + A A A A A A A inactive >>= 3;
> > +
> > A A A return isolated > inactive;
> >
> > Either it did help somewhat, or I was more lucky on my second try, but
> > this time I needed ~5 tries instead of only 2 to get the system mostly
> > stuck again. On the testrun with Wu's patch the writeout pattern was
> > more stable, a burst of ~80kb each 20 seconds. But I would suspect
> > that the size of the burst is rather random.
> >
> > I do have a complete SysRq+T dump from the first run, I can send that
> > to anyone how wants it.
> > (It's 190k so I don't want not spam it to the list)
>
> Is this call trace from the SysRq+T violation the rule to only
> allocate one bio from bio_alloc() until its submitted?
>
> [ 549.700038] Call Trace:
> [ 549.700038] [<ffffffff81566b54>] schedule_timeout+0x144/0x200
> [ 549.700038] [<ffffffff81045cd0>] ? process_timeout+0x0/0x10
> [ 549.700038] [<ffffffff81565e22>] io_schedule_timeout+0x42/0x60
> [ 549.700038] [<ffffffff81083123>] mempool_alloc+0x163/0x1b0
> [ 549.700038] [<ffffffff81053560>] ? autoremove_wake_function+0x0/0x40
> [ 549.700038] [<ffffffff810ea2b9>] bio_alloc_bioset+0x39/0xf0
> [ 549.700038] [<ffffffff810ea38d>] bio_clone+0x1d/0x50
> [ 549.700038] [<ffffffff814318ed>] make_request+0x23d/0x850
> [ 549.700038] [<ffffffff81082e20>] ? mempool_alloc_slab+0x10/0x20
> [ 549.700038] [<ffffffff81045cd0>] ? process_timeout+0x0/0x10
> [ 549.700038] [<ffffffff81436e63>] md_make_request+0xc3/0x220
> [ 549.700038] [<ffffffff81083099>] ? mempool_alloc+0xd9/0x1b0
> [ 549.700038] [<ffffffff811ec153>] generic_make_request+0x1b3/0x370
> [ 549.700038] [<ffffffff810ea2d6>] ? bio_alloc_bioset+0x56/0xf0
> [ 549.700038] [<ffffffff811ec36a>] submit_bio+0x5a/0xd0
> [ 549.700038] [<ffffffff81080cf5>] ? unlock_page+0x25/0x30
> [ 549.700038] [<ffffffff810a871e>] swap_writepage+0x7e/0xc0
> [ 549.700038] [<ffffffff81090d99>] shmem_writepage+0x1c9/0x240
> [ 549.700038] [<ffffffff8108c9cb>] pageout+0x11b/0x270
> [ 549.700038] [<ffffffff8108cd78>] shrink_page_list+0x258/0x4d0
> [ 549.700038] [<ffffffff8108d9e7>] shrink_inactive_list+0x187/0x310
> [ 549.700038] [<ffffffff8102dcb1>] ? __wake_up_common+0x51/0x80
> [ 549.700038] [<ffffffff811fc8b2>] ? cpumask_next_and+0x22/0x40
> [ 549.700038] [<ffffffff8108e1c0>] shrink_zone+0x3e0/0x470
> [ 549.700038] [<ffffffff8108e797>] try_to_free_pages+0x157/0x410
> [ 549.700038] [<ffffffff81087c92>] __alloc_pages_nodemask+0x412/0x760
> [ 549.700038] [<ffffffff810b27d6>] alloc_pages_current+0x76/0xe0
> [ 549.700038] [<ffffffff810b6dad>] new_slab+0x1fd/0x2a0
> [ 549.700038] [<ffffffff81045cd0>] ? process_timeout+0x0/0x10
> [ 549.700038] [<ffffffff810b8721>] __slab_alloc+0x111/0x540
> [ 549.700038] [<ffffffff81059961>] ? prepare_creds+0x21/0xb0
> [ 549.700038] [<ffffffff810b92bb>] kmem_cache_alloc+0x9b/0xa0
> [ 549.700038] [<ffffffff81059961>] prepare_creds+0x21/0xb0
> [ 549.700038] [<ffffffff8104a919>] sys_setresgid+0x29/0x120
> [ 549.700038] [<ffffffff8100242b>] system_call_fastpath+0x16/0x1b
> [ 549.700038] ffff88011e125ea8 0000000000000046 ffff88011e125e08
> ffffffff81073c59
> [ 549.700038] 0000000000012780 ffff88011ea905b0 ffff88011ea90808
> ffff88011e125fd8
> [ 549.700038] ffff88011ea90810 ffff88011e124010 0000000000012780
> ffff88011e125fd8
>
> swap_writepage() uses get_swap_bio() which uses bio_alloc() to get one
> bio. That bio is the submitted, but the submit path seems to get into
> make_request from raid1.c and that allocates a second bio from
> bio_alloc() via bio_clone().
>
> I am seeing this pattern (swap_writepage calling
> md_make_request/make_request and then getting stuck in mempool_alloc)
> more than 5 times in the SysRq+T output...
I bet the root cause is the failure of pool->alloc(__GFP_NORETRY)
inside mempool_alloc(), which can be fixed by this patch.
Thanks,
Fengguang
---
concurrent direct page reclaim problem
__GFP_NORETRY page allocations may fail when there are many concurrent page
allocating tasks, but not necessary in real short of memory. The root cause
is, tasks will first run direct page reclaim to free some pages from the LRU
lists and put them to the per-cpu page lists and the buddy system, and then
try to get a free page from there. However the free pages reclaimed by this
task may be consumed by other tasks when the direct reclaim task is able to
get the free page for itself.
Let's retry it a bit harder.
--- linux-next.orig/mm/page_alloc.c 2010-10-20 13:44:50.000000000 +0800
+++ linux-next/mm/page_alloc.c 2010-10-20 13:50:54.000000000 +0800
@@ -1700,7 +1700,7 @@ should_alloc_retry(gfp_t gfp_mask, unsig
unsigned long pages_reclaimed)
{
/* Do not loop if specifically requested */
- if (gfp_mask & __GFP_NORETRY)
+ if (gfp_mask & __GFP_NORETRY && pages_reclaimed > (1 << (order + 12)))
return 0;
/*
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] Add Intel GMA500(Poulsbo) Stub Driver
From: Joe Perches @ 2010-10-20 5:58 UTC (permalink / raw)
To: Lee, Chun-Yi
Cc: dri-devel, randy.dunlap, mjg59, gregkh, trenn, linux-acpi,
linux-kernel, Valdis.Kletnieks, Dennis.Jansen, airlied, airlied,
eric, alexdeucher, bskeggs, chris, Lee, Chun-Yi
In-Reply-To: <1287553879-25897-1-git-send-email-jlee@novell.com>
On Wed, 2010-10-20 at 13:51 +0800, Lee, Chun-Yi wrote:
> Currently, there have no GMA500(Poulsbo) native video driver to support
> intel opregion. So, use this stub driver to enable the acpi backlight
> control sysfs entry files by requrest acpi_video_register.
[]
> diff --git a/drivers/gpu/stub/poulsbo.c b/drivers/gpu/stub/poulsbo.c
[]
> +static struct pci_device_id pciidlist[] = {
DEFINE_PCI_DEVICE_TABLE
^ permalink raw reply
* Re: [PATCH V10] RO/NX protection for loadable kernel modules
From: Rusty Russell @ 2010-10-20 5:59 UTC (permalink / raw)
To: Kees Cook
Cc: H. Peter Anvin, Siarhei Liakh, linux-kernel,
linux-security-module, linux-next, Arjan van de Ven, James Morris,
Andrew Morton, Andi Kleen, Thomas Gleixner, Ingo Molnar,
Stephen Rothwell, Dave Jones
In-Reply-To: <20101020044539.GX6311@outflux.net>
On Wed, 20 Oct 2010 03:15:39 pm Kees Cook wrote:
> Hi,
...
> Sorry for losing track, but where did this patch end up? I don't see it
> in any of the trees I've looked in.
Good question... This would be quite nice to have of course.
Rusty.
^ permalink raw reply
* Re: [PATCH] OLPC: Add XO-1 suspend/resume support
From: H. Peter Anvin @ 2010-10-20 5:58 UTC (permalink / raw)
To: Borislav Petkov
Cc: Daniel Drake, tglx@linutronix.de, mingo@redhat.com,
x86@kernel.org, dilinger@queued.net, linux-kernel@vger.kernel.org,
Roedel, Joerg
In-Reply-To: <20101020054752.GA10441@aftab>
On 10/19/2010 10:47 PM, Borislav Petkov wrote:
>
> The final version with fixed ACPI sleep is this one:
> http://www.gossamer-threads.com/lists/linux/kernel/1270589
>
> I ran it for a couple of weeks and it didn't show any regressions. If
> you want to get it into the merge window, I can get you an updated
> version against a -tip branch of your liking ASAP.
>
If you could prep something against tip:master we *might* be able to get
it in... not sure yet (and it partly depends on when Linus decides to
push the button, of course.)
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* [LTP] smack testcase
From: ARJIT SHARMA @ 2010-10-20 6:00 UTC (permalink / raw)
To: ltp-list, Garrett Cooper
[-- Attachment #1.1: Type: text/plain, Size: 5690 bytes --]
Hi,
Inside the smack testcase, the sript "smack_common.sh" has a function
named "check_onlycap()" , please tell me its functionality as every time
this function is reporting that onlycap is "" not the expected "".
the log of the testcase is as follows---
INFO: creating /opt/ltp/results directory
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux 192.168.1.10 2.6.32 #2 SMP Tue Oct 19 17:34:35 IST 2010 armv7l unknown
unknown GNU/Linux
Gnu C gcc (GCC) 4.5.0
Gnu make 3.81
util-linux ng 2.16.1)
mount ng 2.16.1 (with libblkid support)
modutils 3.1
e2fsprogs 1.41.9
PPP 2.4.4
Linux C Library 2.10.1
Dynamic linker (ldd) 2.10.1
Linux C++ Library 6.0.14
Procps 3.2.7
Net-tools 1.60
iproute2 iproute2-ss100224
Console-tools 0.2.3
Sh-utils 5.2.1
Modules Loaded
free reports:
total used free shared buffers cached
Mem: 255368 21240 234128 0 0 11764
-/+ buffers/cache: 9476 245892
Swap: 0 0 0
/proc/cpuinfo
Processor : ARMv7 Processor rev 1 (v7l)
processor : 0
BogoMIPS : 996.14
processor : 1
BogoMIPS : 996.14
Features : swp half thumb fastmult vfp edsp vfpv3 vfpv3d16
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x1
CPU part : 0xc09
CPU revision : 1
Hardware : ST-SPEAR1300-EVB
Revision : 0000
Serial : 0000000000000000
remove test cases which require the block device.
You can specify it with option -b
COMMAND: /opt/ltp/bin/ltp-pan -e -S -a 1255 -n 1255 -p -f
/tmp/ltp-MqPLzA1261/alltests -l /opt/ltp/results/smack.result -C
/opt/ltp/output/LTP_RUN_ON-smack.result.failed
LOG File: /opt/ltp/results/smack.result
FAILED COMMAND File: /opt/ltp/output/LTP_RUN_ON-smack.result.failed
Running tests.......
<<<test_start>>>
tag=smack_set_ambient stime=618
cmdline="smack_set_ambient.sh"
contacts=""
analysis=exit
<<<test_output>>>
The smack label reported for /smack/onlycap is "", not the expected "".
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=1 corefile=no
cutime=1 cstime=5
<<<test_end>>>
<<<test_start>>>
tag=smack_set_current stime=618
cmdline="smack_set_current.sh"
contacts=""
analysis=exit
<<<test_output>>>
The smack label reported for /smack/onlycap is "", not the expected "".
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=1 corefile=no
cutime=1 cstime=5
<<<test_end>>>
<<<test_start>>>
tag=smack_set_doi stime=619
cmdline=" smack_set_doi.sh"
contacts=""
analysis=exit
<<<test_output>>>
The smack label reported for /smack/onlycap is "", not the expected "".
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=1 corefile=no
cutime=2 cstime=6
<<<test_end>>>
<<<test_start>>>
tag=smack_set_netlabel stime=619
cmdline="smack_set_netlabel.sh"
contacts=""
analysis=exit
<<<test_output>>>
The smack label reported for /smack/onlycap is "", not the expected "".
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=1 corefile=no
cutime=3 cstime=3
<<<test_end>>>
<<<test_start>>>
tag=smack_set_socket_labels stime=619
cmdline="smack_set_socket_labels"
contacts=""
analysis=exit
<<<test_output>>>
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=smack_set_cipso stime=619
cmdline=" smack_set_cipso.sh"
contacts=""
analysis=exit
<<<test_output>>>
The smack label reported for /smack/onlycap is "", not the expected "".
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=1 corefile=no
cutime=2 cstime=4
<<<test_end>>>
<<<test_start>>>
tag=smack_set_direct stime=619
cmdline="smack_set_direct.sh"
contacts=""
analysis=exit
<<<test_output>>>
The smack label reported for /smack/onlycap is "", not the expected "".
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=1 corefile=no
cutime=0 cstime=4
<<<test_end>>>
<<<test_start>>>
tag=smack_set_load stime=619
cmdline=" smack_set_load.sh"
contacts=""
analysis=exit
<<<test_output>>>
The smack label reported for /smack/onlycap is "", not the expected "".
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=1 corefile=no
cutime=1 cstime=5
<<<test_end>>>
<<<test_start>>>
tag=smack_set_onlycap stime=619
cmdline="smack_set_onlycap.sh"
contacts=""
analysis=exit
<<<test_output>>>
The smack label reported for /smack/onlycap is "", not the expected "".
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=1 corefile=no
cutime=0 cstime=6
<<<test_end>>>
<<<test_start>>>
tag=smack_file_access stime=619
cmdline="smack_file_access.sh"
contacts=""
analysis=exit
<<<test_output>>>
The smack label reported for /smack/onlycap is "", not the expected "".
incrementing stop
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=1 corefile=no
cutime=1 cstime=6
<<<test_end>>>
INFO: ltp-pan reported some tests FAIL
LTP Version: LTP-20100131
###############################################################"
Done executing testcases."
LTP Version: LTP-20100131
###############################################################"
--
Best Regards,
Arjit Sharma.
[-- Attachment #1.2: Type: text/html, Size: 7812 bytes --]
[-- Attachment #2: Type: text/plain, Size: 369 bytes --]
------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
[-- Attachment #3: Type: text/plain, Size: 155 bytes --]
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply
* Re: [PATCH 1/2]percpu: introduce read mostly percpu API
From: H. Peter Anvin @ 2010-10-20 6:00 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Shaohua Li, lkml, Ingo Molnar, Andi Kleen, Chen, Tim C
In-Reply-To: <1287551880.2700.79.camel@edumazet-laptop>
On 10/19/2010 10:18 PM, Eric Dumazet wrote:
>
> Could you precisely describe why grouping together read mostly percpu
> variables is a win ? Especially when you add in your next patch a single
> variable ?
>
The logic is that those variables are less likely to end up dirty in the
cache. It is, however, much less of an issue for percpu variables,
since dirty lines there aren't quite so likely to bounce around.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* [RFC, PATCH 0/5] unify definition of CLOCK_TICK_RATE across different platforms
From: Eric Miao @ 2010-10-20 6:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20101020045110.GW12979@mail.wantstofly.org>
On Wed, Oct 20, 2010 at 12:51 PM, Lennert Buytenhek
<buytenh@wantstofly.org> wrote:
> One of the things preventing building an ARM multiplatform kernel
> image is the fact that CLOCK_TICK_RATE (and as a consequence, LATCH)
> is defined differently for each ARM platform.
>
> The patches in this series:
> - pull the per-platform CLOCK_TICK_RATE defines from <mach/timex.h>
> ?into arch/arm/mach-foo/ (on those platforms that use the
> ?CLOCK_TICK_RATE define and/or the LATCH define in their platform
> ?support code);
> - define CLOCK_TICK_RATE as a platform-independent value in <asm/timex.h>;
> - get rid of all <mach/timex.h> include files.
>
Excellent!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.