* Re: Poor HVM performance with 8 vcpus
From: Juergen Gross @ 2009-10-07 11:45 UTC (permalink / raw)
To: George Dunlap
Cc: Ian Pratt, xen-devel@lists.xensource.com, Tim Deegan,
James Harper
In-Reply-To: <de76405a0910070311q6c879be0wd4f33d8108235d8b@mail.gmail.com>
George Dunlap wrote:
> Jeurgen,
>
> I think this problem is a good candidate for xentrace/xenalyze. If
> you take a 30-second trace (xentrace -D -e all -T 30
> /tmp/[traceid].trace) while the benchmark is at its heaviest, and then
> analyze it using xenalyze
> (http://xenbits.xensource.com/ext/xenalyze.hg), it should show up
> whether the shadow performance is due to brute-force search or
> something else.
>
> If you're using 3.3, you'll have to apply the back-patch to xenalyze
> to make it work properly.
Patches don't apply cleanly, build fails with error even without patches due
to incorrect format strings.
Juergen
--
Juergen Gross Principal Developer Operating Systems
TSP ES&S SWE OS6 Telephone: +49 (0) 89 636 47950
Fujitsu Technolgy Solutions e-mail: juergen.gross@ts.fujitsu.com
Otto-Hahn-Ring 6 Internet: ts.fujitsu.com
D-81739 Muenchen Company details: ts.fujitsu.com/imprint.html
^ permalink raw reply
* Re: [lm-sensors] I2C support STMicroeletronics LIS302Dx three-axis
From: Jonathan Cameron @ 2009-10-07 11:45 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <20090917215312.GA6974@intel.com>
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
> From 49fc14f67760c6f5ba0d3f33538af948f87c7b66 Mon Sep 17 00:00:00 2001
> From: Kalhan Trisal <kalhan.trisal@intel.com>
> Date: Mon, 5 Oct 2009 18:22:33 -0400
> Subject: [PATCH] I2C glue layer for lis3lv02d STMicroelectronics digital accelerometer
> This patch will support I2C interface for ST Macroelectronics 3 axis digital accelerometer.
>
> Signed-off-by: Kalhan Trisal <kalhan.trisal@intel.com>
> ---
> drivers/hwmon/Kconfig | 14 ++++++
> drivers/hwmon/Makefile | 1 +
> drivers/hwmon/lis3lv02d_i2c.c | 103 +++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 118 insertions(+), 0 deletions(-)
> create mode 100755 drivers/hwmon/lis3lv02d_i2c.c
>
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 6857560..c5e2760 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -983,6 +983,20 @@ config SENSORS_LIS3_SPI
> will be called lis3lv02d and a specific module for the SPI transport
> is called lis3lv02d_spi.
>
> +config SENSORS_LIS3_I2C
> + tristate "STMicroeletronics LIS3LV02Dx three-axis digital accelerometer (I2C)"
> + depends on I2C && INPUT
> + select INPUT_POLLDEV
> + default n
> + help
> + This driver provides support for the LIS3LV02Dx accelerometer connected
> + via I2C. The accelerometer data is readable via
> + /sys/devices/platform/lis3lv02d.
> +
> + This driver can also be built as modules. If so, the core module
> + will be called lis3lv02d and a specific module for the I2C transport
> + is called lis3lv02d_i2c.
> +
> config SENSORS_APPLESMC
> tristate "Apple SMC (Motion sensor, light sensor, keyboard backlight)"
> depends on INPUT && X86
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 9f46cb0..cc2c12d 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -55,6 +55,7 @@ obj-$(CONFIG_SENSORS_IT87) += it87.o
> obj-$(CONFIG_SENSORS_K8TEMP) += k8temp.o
> obj-$(CONFIG_SENSORS_LIS3LV02D) += lis3lv02d.o hp_accel.o
> obj-$(CONFIG_SENSORS_LIS3_SPI) += lis3lv02d.o lis3lv02d_spi.o
> +obj-$(CONFIG_SENSORS_LIS3_I2C) += lis3lv02d.o lis3lv02d_i2c.o
> obj-$(CONFIG_SENSORS_LM63) += lm63.o
> obj-$(CONFIG_SENSORS_LM70) += lm70.o
> obj-$(CONFIG_SENSORS_LM75) += lm75.o
> diff --git a/drivers/hwmon/lis3lv02d_i2c.c b/drivers/hwmon/lis3lv02d_i2c.c
> new file mode 100755
> index 0000000..0be5cd0
> --- /dev/null
> +++ b/drivers/hwmon/lis3lv02d_i2c.c
> @@ -0,0 +1,103 @@
> +/*
> + * lis3lv02d_i2c - I2C glue layer for LIS[32]02DL varients
> + *
> + * Copyright (c) 2009 Kalhan Trisal <kalhan.trisal@intel.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
> + * publishhed by the Free Software Foundation.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/i2c.h>
> +#include "lis3lv02d.h"
> +
> +
> +static int lis3_i2c_read(struct lis3lv02d *lis3, int reg, u8 *v)
> +{
> + int ret;
> + ret = i2c_smbus_read_byte_data(lis3->bus_priv, reg);
> +
> + *v = (u8) ret;
> + return ret;
> +}
> +
> +static int lis3_i2c_write(struct lis3lv02d *lis3, int reg, u8 val)
> +{
> +
> + return i2c_smbus_write_byte_data(lis3->bus_priv, reg, val);
> +}
> +
> +static int lis3_i2c_init(struct lis3lv02d *lis3)
> +{
> + u8 reg;
> + int ret;
> +
> + /* power up the device */
> + ret = lis3->read(lis3, CTRL_REG1, ®);
> + if (ret < 0)
> + return ret;
> +
> + reg |= CTRL1_PD0;
> + return lis3->write(lis3, CTRL_REG1, reg);
> +}
> +
> +static struct axis_conversion lis3lv02d_axis_normal = { 1, 2, 3 };
> +
> +static int lis302dl_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + lis3_dev.bus_priv = client;
> + lis3_dev.init = lis3_i2c_init;
> + lis3_dev.read = lis3_i2c_read;
> + lis3_dev.write = lis3_i2c_write;
> + lis3_dev.irq = client->irq;
> + lis3_dev.ac = lis3lv02d_axis_normal;
> + lis3_dev.pdata = client->dev.platform_data;
> + i2c_set_clientdata(client, &lis3_dev);
> + return lis3lv02d_init_device(&lis3_dev);
> +}
> +
> +static int lis302dl_remove(struct i2c_client *client)
> +{
> + struct lis3lv02d *lis3 = i2c_get_clientdata(client);
> + lis3lv02d_joystick_disable();
> + lis3lv02d_poweroff(lis3);
> + return 0;
> +}
> +
> +static struct i2c_device_id lis302dl_id[] = {
> + { "lis302dl", 0 },
> + { }
> +};
> +
> +MODULE_DEVICE_TABLE(i2c, lis302dl_id);
> +
> +static struct i2c_driver lis302dl_driver = {
> + .driver = {
> + .name = "lis302dl_i2c",
> + },
> + .probe = lis302dl_probe,
> + .remove = lis302dl_remove,
> + .id_table = lis302dl_id,
> +};
> +
> +static int __init sensor_lis302dl_init(void)
> +{
> + return i2c_add_driver(&lis302dl_driver);
> +}
> +
> +static void __exit sensor_lis302dl_exit(void)
> +{
> + i2c_del_driver(&lis302dl_driver);
> +}
> +
> +module_init(sensor_lis302dl_init);
> +module_exit(sensor_lis302dl_exit);
> +
> +MODULE_AUTHOR("Kalhan Trisal <kalhan.trisal@intel.com>");
> +MODULE_DESCRIPTION("LIS[32]02DL I2C glue layer");
> +MODULE_LICENSE("GPL");
> +
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* transparent proxy and iptables failing
From: Robin Wood @ 2009-10-07 11:44 UTC (permalink / raw)
To: netfilter
In-Reply-To: <7de411230910070245s23552d36v66496187db666440@mail.gmail.com>
Hi
I'm trying to setup a transparent proxy so I've got a linux device
with two NICs which are bridged using brctl. Traffic flows happily
across the bridge so I know it is working fine.
Now when I try to setup the iptables rules they are being ignored. The
rule I want to use is:
iptables -t nat -A PREROUTING -i br-lan -p tcp --dport 80 -j REDIRECT
--to-port 3128
but nothing gets redirected. I've also tried changing 3128 to a port
that is closed to see what would happen, nothing, the packets kept
flowing.
I've also tried clearing the list and then adding
iptables -t nat -A PREROUTING -i br-lan -p tcp --dport 80 -j DROP
which should kill all web traffic but it doesn't. As a last resort I tried
iptables -t nat -A PREROUTING -i br-lan -p tcp -j DROP
which should kill all TCP traffic but again, nothing.
What am I doing wrong?
Robin
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 3/6] virtio-console: Add a virtio-console bus, support for multiple ports
From: Amit Shah @ 2009-10-07 11:42 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: qemu-devel
In-Reply-To: <4ACC7CA5.4030704@redhat.com>
On (Wed) Oct 07 2009 [13:33:57], Gerd Hoffmann wrote:
> On 10/07/09 12:06, Amit Shah wrote:
>>> Oh, I thought it would create a new virtio-serial-bus (plus auto-created
>>> port0 console) unconditionally. Just do enougth to keep existing users
>>> of the switch working.
>>>
>>> If you want new features (i.e. two consoles ports attached to one
>>> virtio-serial-bus device) you must use the new syntax.
>>
>> So it's better overall to drop the old syntax altogether, right? It
>> could get easily confusing otherwise.
>>
>> We can easily end up having:
>>
>> -virtioconsole<chardev>
>> <auto-creates a bus and attaches a console port to it>
>>
>> -device virtio-serial-pci,id=blah
>> <a second bus>
>>
>> -device virtport,bus=blah.0
>>
>> <and no way to connect a device to the bus that got created by
>> virtioconsole>
>
> It isn't that bad.
>
> First, the busses get names based on the bus type by default, i.e. when
> creating a scsi adapter without specifying id=seomthing the bus is
> simply named "scsi.0". Likewise the -virtioconsole created bus would be
> "port.0" or simliar (depends on the name in BusInfo).
>
> Second, the bus= argument is optional. If not specified, qdev will pick
> the first bus of a matching type it finds. So as long you have a single
> port/scsi/usb/... bus only you don't need bus= at all. You can do:
The problem with this is that the management solution needs to know then
what is the default bus name (which could change if the code gets
updated).
And also there's the other problem of a console port spawning a bus
(which could end up spawning another console port at #0...)
So IMO it's better to leave that command line param out.
Amit
^ permalink raw reply
* [Bridge] Problem Forwarding Bridge to Tap Device
From: Carsten @ 2009-10-07 11:43 UTC (permalink / raw)
To: bridge
Hello,
I have a problem with bridge and tap network where I can't find a solution
first my scenario
[ETHx][PC1] <-> [Switch] <-> [PC2][ETHx][VLANx][BR0][TAP0][VBox]
Switchport of PC1 is untagged in VLANx, Switchport of PC2 is tagged in the same VLAN. I can see the packets running as I want over all components.
Now my Problem
I send a Ping from VBox to PC1 all works fine, while the ping is running I restart PC1, as suggested ping now fail.
After PC1 is up again packet transport should work correctly, but it doesn't (exactly some times is ok, some times problem comes after 5th reboot or so but is coming if I have enough reboots of PC1) .
So find the problem I dump the traffic of VLANx, BR0 and TAP0.
What I see:
@VLANx: arp request and reply
@ BR0: arp request and reply
@ TAP0: arp request
So I think the bridge stop forwarding packets to the TAP device and I don't understand why. Have anyone an idea?
Thx for help
----
versendet mit www.oleco.de Mail - Anmeldung und Nutzung kostenlos!
Oleco www.netlcr.org - jetzt auch mit Spamschutz.
^ permalink raw reply
* Re: [PATCH V2] fix a warning on kernel/trace/trace_branch.c and trace_hw_branches.c
From: Helight.Xu @ 2009-10-07 11:40 UTC (permalink / raw)
To: Li Zefan; +Cc: linux-kernel, Ingo Molnar, Frederic Weisbecker, Steven Rostedt
In-Reply-To: <4ACC5715.4000201@cn.fujitsu.com>
Li Zefan wrote:
> Zhenwen Xu wrote:
>
>> fix warnings that caused the API change of trace_buffer_lock_reserve()
>> change files: kernel/trace/trace_hw_branch.c
>> kernel/trace/trace_branch.c
>>
>>
>
> Hmm, did you really compile trace_hw_branch.c while testing
> this patch?
>
> This change is necessary too:
>
> - trace_buffer_unlock_commit(tr, event, 0, 0);
> + trace_buffer_unlock_commit(tr->buffer, event, 0, 0);
>
> And use a varaible "buffer = tr->buffer" should be better.
>
oh! sorry for my careless!
>
>> Signed-off-by: Zhenwen Xu <helight.xu@gmail.com>
>> ---
>> kernel/trace/trace_branch.c | 2 +-
>> kernel/trace/trace_hw_branches.c | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/trace/trace_branch.c b/kernel/trace/trace_branch.c
>> index 7a7a9fd..216e2dd 100644
>> --- a/kernel/trace/trace_branch.c
>> +++ b/kernel/trace/trace_branch.c
>> @@ -54,7 +54,7 @@ probe_likely_condition(struct ftrace_branch_data *f, int val, int expect)
>> goto out;
>>
>> pc = preempt_count();
>> - event = trace_buffer_lock_reserve(tr, TRACE_BRANCH,
>> + event = trace_buffer_lock_reserve(tr->buffer, TRACE_BRANCH,
>> sizeof(*entry), flags, pc);
>> if (!event)
>> goto out;
>> diff --git a/kernel/trace/trace_hw_branches.c b/kernel/trace/trace_hw_branches.c
>> index 23b6385..1cc17ca 100644
>> --- a/kernel/trace/trace_hw_branches.c
>> +++ b/kernel/trace/trace_hw_branches.c
>> @@ -180,7 +180,7 @@ void trace_hw_branch(u64 from, u64 to)
>> if (atomic_inc_return(&tr->data[cpu]->disabled) != 1)
>> goto out;
>>
>> - event = trace_buffer_lock_reserve(tr, TRACE_HW_BRANCHES,
>> + event = trace_buffer_lock_reserve(tr->buffer, TRACE_HW_BRANCHES,
>> sizeof(*entry), 0, 0);
>> if (!event)
>> goto out;
>>
>
>
--
---------------------------------
Zhenwen Xu - Open and Free
Home Page: http://zhwen.org
^ permalink raw reply
* [PATCH V3] fix a warning on kernel/trace/trace_branch.c andtrace_hw_branches.c
From: Zhenwen Xu @ 2009-10-07 11:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Ingo Molnar, Frederic Weisbecker, Steven Rostedt
fix warnings that caused the API change of trace_buffer_lock_reserve()
change files: kernel/trace/trace_hw_branch.c
kernel/trace/trace_branch.c
Signed-off-by: Zhenwen Xu <helight.xu@gmail.com>
---
kernel/trace/trace_branch.c | 2 +-
kernel/trace/trace_hw_branches.c | 6 ++++--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/kernel/trace/trace_branch.c b/kernel/trace/trace_branch.c
index 7a7a9fd..216e2dd 100644
--- a/kernel/trace/trace_branch.c
+++ b/kernel/trace/trace_branch.c
@@ -54,7 +54,7 @@ probe_likely_condition(struct ftrace_branch_data *f, int val, int expect)
goto out;
pc = preempt_count();
- event = trace_buffer_lock_reserve(tr, TRACE_BRANCH,
+ event = trace_buffer_lock_reserve(tr->buffer, TRACE_BRANCH,
sizeof(*entry), flags, pc);
if (!event)
goto out;
diff --git a/kernel/trace/trace_hw_branches.c b/kernel/trace/trace_hw_branches.c
index 23b6385..e40f5fb 100644
--- a/kernel/trace/trace_hw_branches.c
+++ b/kernel/trace/trace_hw_branches.c
@@ -165,6 +165,7 @@ void trace_hw_branch(u64 from, u64 to)
struct ftrace_event_call *call = &event_hw_branch;
struct trace_array *tr = hw_branch_trace;
struct ring_buffer_event *event;
+ struct ring_buffer *buf;
struct hw_branch_entry *entry;
unsigned long irq1;
int cpu;
@@ -180,7 +181,8 @@ void trace_hw_branch(u64 from, u64 to)
if (atomic_inc_return(&tr->data[cpu]->disabled) != 1)
goto out;
- event = trace_buffer_lock_reserve(tr, TRACE_HW_BRANCHES,
+ buf = tr->buffer
+ event = trace_buffer_lock_reserve(buf, TRACE_HW_BRANCHES,
sizeof(*entry), 0, 0);
if (!event)
goto out;
@@ -190,7 +192,7 @@ void trace_hw_branch(u64 from, u64 to)
entry->from = from;
entry->to = to;
if (!filter_check_discard(call, entry, tr->buffer, event))
- trace_buffer_unlock_commit(tr, event, 0, 0);
+ trace_buffer_unlock_commit(buf, event, 0, 0);
out:
atomic_dec(&tr->data[cpu]->disabled);
--
1.6.3.3
--
--------------------------------
http://zhwen.org - Open and Free
^ permalink raw reply related
* Re: tc and CONNMARK [SOLVED]
From: Fabio Marcone @ 2009-10-07 11:41 UTC (permalink / raw)
To: netfilter
In-Reply-To: <4AC9BD2E.301@duet.it>
Thanks to all for your help.
>
> Starting a single connection (upload or download) traffic is limited
> correctly but if I start two connection (one in upload and the other
> in download) I note that the one in upload runs correctly (how in the
> previous test) but the one in download stalls and then send some
> packets and then stalls alternatively.
I solve using sfq to htb leaves, in this way this two flows share the
bandwidth correctly.
Fabio
^ permalink raw reply
* get request context
From: michel m @ 2009-10-07 11:39 UTC (permalink / raw)
To: selinux
[-- Attachment #1: Type: text/plain, Size: 375 bytes --]
Hi,
Is there any way that I can get context for incoming http requests from
selinux API. that is I want to classify requests based on some criteria like
origin`s IP address or any thing that can help me to know what context the
request is coming from.
is there such an API for this is libselinux? If not, how can I have this
knowledge by using existing API?
Best regards.
[-- Attachment #2: Type: text/html, Size: 400 bytes --]
^ permalink raw reply
* Re: [PATCH 30/45] vmscan: lumpy pageout
From: Nikita Danilov @ 2009-10-07 11:37 UTC (permalink / raw)
To: Wu Fengguang
Cc: Andrew Morton, Theodore Tso, Christoph Hellwig, Dave Chinner,
Chris Mason, Peter Zijlstra, Li, Shaohua, Myklebust Trond,
jens.axboe@oracle.com, Jan Kara, Nick Piggin,
linux-fsdevel@vger.kernel.org
In-Reply-To: <20091007111454.GB15936@localhost>
2009/10/7 Wu Fengguang <fengguang.wu@intel.com>:
> On Wed, Oct 07, 2009 at 06:38:37PM +0800, Nikita Danilov wrote:
>> Hello,
>>
[...]
>
> Glad to know about your experiences :) Interestingly I started with
> ->writepage() and then switch to ->writepages() because filesystems
> behave better with the latter (i.e. less file fragmentation).
By the way, why is your patch doing
->writepage(page->index);
generic_writepages(page->index + 1, LUMPY_PAGEOUT_PAGES - 1);
instead of
generic_writepages(page->index, LUMPY_PAGEOUT_PAGES);
? Is this because of the difficulties with passing back page specific
errors from generic_writepages()?
>
> I'd like to just ignore the shmem case, by adding a
> bdi_cap_writeback_dirty() check. Because clustered writing to swap
> device may be a less gain.
Or you can just call try_to_unmap() from shmem_writepage() when
wbc->for_reclaim is true.
>
> Page filtering should also be possible in write_cache_pages(). But
> what do you mean by "hard-to-fix races against inode reclamation"?
vmscan.c pageout path doesn't take a reference on inode, so the
instant ->writepage() releases lock on the page, the inode can be
freed.
>
> Thanks,
> Fengguang
>
Thank you,
Nikita.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" 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
* [Qemu-devel] [PATCH 2/2] rom loader: also try filename as-is.
From: Gerd Hoffmann @ 2009-10-07 11:37 UTC (permalink / raw)
To: qemu-devel; +Cc: Gerd Hoffmann
In-Reply-To: <1254915427-7375-1-git-send-email-kraxel@redhat.com>
In case qemu_find_file fails try to open the file as-is.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
hw/loader.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/hw/loader.c b/hw/loader.c
index 40112b9..4ce7c6a 100644
--- a/hw/loader.c
+++ b/hw/loader.c
@@ -559,8 +559,7 @@ int rom_add_file(const char *file,
rom->name = qemu_strdup(file);
rom->path = qemu_find_file(QEMU_FILE_TYPE_BIOS, rom->name);
if (rom->path == NULL) {
- fprintf(stderr, "Could not find option rom '%s'\n", rom->name);
- goto err;
+ rom->path = strdup(file);
}
fd = open(rom->path, O_RDONLY);
--
1.6.2.5
^ permalink raw reply related
* [Qemu-devel] [PATCH 1/2] rom loader: fix sparc -kernel boot.
From: Gerd Hoffmann @ 2009-10-07 11:37 UTC (permalink / raw)
To: qemu-devel; +Cc: Gerd Hoffmann
Changes:
(1) register pstrcpy_targphys() in rom list, it is used for kernel
command lines by a number of architectures.
(2) add rom_ptr() function to get a pointer for applying changes
to loaded images. Needed for example to tell the linux kernel
where it finds the initrd image by updating the header.
(3) make sparc use rom_ptr for initrd setup.
booting sparc-test works now, and 'info roms' shows this:
(qemu) info roms
addr=0000000000000000 size=0x2a3828 mem=ram name="phdr #0: vmlinux-2.6.11+tcx"
addr=00000000007ff000 size=0x00000e mem=ram name="cmdline"
addr=0000000000800000 size=0x400000 mem=ram name="/root/qemu-test/sparc-test/linux.img"
addr=0000000070000000 size=0x0e4000 mem=rom name="phdr #0: /home/kraxel/projects/qemu/build-zfull/pc-bios/openbios-sparc32"
reboot via 'system_reset' works too.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
hw/axis_dev88.c | 2 +-
hw/etraxfs.c | 2 +-
hw/loader.c | 38 ++++++++++++++++++++++++++++++++------
hw/loader.h | 4 +++-
hw/mips_malta.c | 2 +-
hw/mips_r4k.c | 2 +-
hw/pc.c | 2 +-
hw/petalogix_s3adsp1800_mmu.c | 2 +-
hw/ppc.c | 2 +-
hw/ppc_newworld.c | 2 +-
hw/ppc_oldworld.c | 2 +-
hw/r2d.c | 2 +-
hw/sun4m.c | 14 ++++++++------
hw/sun4u.c | 2 +-
14 files changed, 54 insertions(+), 24 deletions(-)
diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c
index 81a41c9..2a79d33 100644
--- a/hw/axis_dev88.c
+++ b/hw/axis_dev88.c
@@ -365,7 +365,7 @@ void axisdev88_init (ram_addr_t ram_size,
/* Let the kernel know we are modifying the cmdline. */
env->regs[10] = 0x87109563;
env->regs[11] = 0x40000000;
- pstrcpy_targphys(env->regs[11], 256, kernel_cmdline);
+ pstrcpy_targphys("cmdline", env->regs[11], 256, kernel_cmdline);
}
}
env->pc = bootstrap_pc;
diff --git a/hw/etraxfs.c b/hw/etraxfs.c
index 4f451c5..9304b15 100644
--- a/hw/etraxfs.c
+++ b/hw/etraxfs.c
@@ -157,7 +157,7 @@ void bareetraxfs_init (ram_addr_t ram_size,
/* Let the kernel know we are modifying the cmdline. */
env->regs[10] = 0x87109563;
env->regs[11] = 0x40000000;
- pstrcpy_targphys(env->regs[11], 256, kernel_cmdline);
+ pstrcpy_targphys("cmdline", env->regs[11], 256, kernel_cmdline);
}
}
env->pc = bootstrap_pc;
diff --git a/hw/loader.c b/hw/loader.c
index c436ec6..40112b9 100644
--- a/hw/loader.c
+++ b/hw/loader.c
@@ -108,20 +108,20 @@ int load_image_targphys(const char *filename,
return size;
}
-void pstrcpy_targphys(target_phys_addr_t dest, int buf_size,
+void pstrcpy_targphys(const char *name, target_phys_addr_t dest, int buf_size,
const char *source)
{
- static const uint8_t nul_byte = 0;
const char *nulp;
+ char *ptr;
if (buf_size <= 0) return;
nulp = memchr(source, 0, buf_size);
if (nulp) {
- cpu_physical_memory_write_rom(dest, (uint8_t *)source,
- (nulp - source) + 1);
+ rom_add_blob_fixed(name, source, (nulp - source) + 1, dest);
} else {
- cpu_physical_memory_write_rom(dest, (uint8_t *)source, buf_size - 1);
- cpu_physical_memory_write_rom(dest, &nul_byte, 1);
+ rom_add_blob_fixed(name, source, buf_size, dest);
+ ptr = rom_ptr(dest + buf_size - 1);
+ *ptr = 0;
}
}
@@ -672,6 +672,32 @@ int rom_load_all(void)
return 0;
}
+static Rom *find_rom(target_phys_addr_t addr)
+{
+ Rom *rom;
+
+ QTAILQ_FOREACH(rom, &roms, next) {
+ if (rom->max)
+ continue;
+ if (rom->min > addr)
+ continue;
+ if (rom->min + rom->romsize < addr)
+ continue;
+ return rom;
+ }
+ return NULL;
+}
+
+void *rom_ptr(target_phys_addr_t addr)
+{
+ Rom *rom;
+
+ rom = find_rom(addr);
+ if (!rom || !rom->data)
+ return NULL;
+ return rom->data + (addr - rom->min);
+}
+
void do_info_roms(Monitor *mon)
{
Rom *rom;
diff --git a/hw/loader.h b/hw/loader.h
index 031e6ad..945c662 100644
--- a/hw/loader.h
+++ b/hw/loader.h
@@ -15,7 +15,8 @@ int load_uimage(const char *filename, target_phys_addr_t *ep,
int read_targphys(const char *name,
int fd, target_phys_addr_t dst_addr, size_t nbytes);
-void pstrcpy_targphys(target_phys_addr_t dest, int buf_size,
+void pstrcpy_targphys(const char *name,
+ target_phys_addr_t dest, int buf_size,
const char *source);
int rom_add_file(const char *file,
@@ -23,6 +24,7 @@ int rom_add_file(const char *file,
int rom_add_blob(const char *name, const void *blob, size_t len,
target_phys_addr_t min, target_phys_addr_t max, int align);
int rom_load_all(void);
+void *rom_ptr(target_phys_addr_t addr);
void do_info_roms(Monitor *mon);
#define rom_add_file_fixed(_f, _a) \
diff --git a/hw/mips_malta.c b/hw/mips_malta.c
index d0266d5..6b224e5 100644
--- a/hw/mips_malta.c
+++ b/hw/mips_malta.c
@@ -679,7 +679,7 @@ static void prom_set(int index, const char *string, ...)
va_start(ap, string);
vsnprintf(buf, ENVP_ENTRY_SIZE, string, ap);
va_end(ap);
- pstrcpy_targphys(table_addr + VIRT_TO_PHYS_ADDEND, ENVP_ENTRY_SIZE, buf);
+ pstrcpy_targphys("prom", table_addr + VIRT_TO_PHYS_ADDEND, ENVP_ENTRY_SIZE, buf);
}
/* Kernel */
diff --git a/hw/mips_r4k.c b/hw/mips_r4k.c
index d7b301a..d525c63 100644
--- a/hw/mips_r4k.c
+++ b/hw/mips_r4k.c
@@ -130,7 +130,7 @@ static void load_kernel (CPUState *env)
} else {
ret = 0;
}
- pstrcpy_targphys((16 << 20) - 256 + ret, 256,
+ pstrcpy_targphys("cmdline", (16 << 20) - 256 + ret, 256,
loaderparams.kernel_cmdline);
stl_phys((16 << 20) - 260, 0x12345678);
diff --git a/hw/pc.c b/hw/pc.c
index 2ca15a3..d8027ef 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -865,7 +865,7 @@ static void load_linux(void *fw_cfg,
initrd_max = max_ram_size-ACPI_DATA_SIZE-1;
/* kernel command line */
- rom_add_blob_fixed("linux-cmdline", kernel_cmdline,
+ rom_add_blob_fixed("cmdline", kernel_cmdline,
strlen(kernel_cmdline)+1, cmdline_addr);
if (protocol >= 0x202) {
diff --git a/hw/petalogix_s3adsp1800_mmu.c b/hw/petalogix_s3adsp1800_mmu.c
index f343dbf..93ce87f 100644
--- a/hw/petalogix_s3adsp1800_mmu.c
+++ b/hw/petalogix_s3adsp1800_mmu.c
@@ -176,7 +176,7 @@ petalogix_s3adsp1800_init(ram_addr_t ram_size,
env->regs[5] = ddr_base + kernel_size;
if (kernel_cmdline && (kcmdline_len = strlen(kernel_cmdline))) {
- pstrcpy_targphys(env->regs[5], 256, kernel_cmdline);
+ pstrcpy_targphys("cmdline", env->regs[5], 256, kernel_cmdline);
}
env->regs[6] = 0;
/* Provide a device-tree. */
diff --git a/hw/ppc.c b/hw/ppc.c
index 09ee2e4..2502e21 100644
--- a/hw/ppc.c
+++ b/hw/ppc.c
@@ -1256,7 +1256,7 @@ int PPC_NVRAM_set_params (nvram_t *nvram, uint16_t NVRAM_size,
NVRAM_set_lword(nvram, 0x3C, kernel_size);
if (cmdline) {
/* XXX: put the cmdline in NVRAM too ? */
- pstrcpy_targphys(CMDLINE_ADDR, RAM_size - CMDLINE_ADDR, cmdline);
+ pstrcpy_targphys("cmdline", CMDLINE_ADDR, RAM_size - CMDLINE_ADDR, cmdline);
NVRAM_set_lword(nvram, 0x40, CMDLINE_ADDR);
NVRAM_set_lword(nvram, 0x44, strlen(cmdline));
} else {
diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c
index d1a82bf..d9f45b5 100644
--- a/hw/ppc_newworld.c
+++ b/hw/ppc_newworld.c
@@ -364,7 +364,7 @@ static void ppc_core99_init (ram_addr_t ram_size,
fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_SIZE, kernel_size);
if (kernel_cmdline) {
fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_CMDLINE, CMDLINE_ADDR);
- pstrcpy_targphys(CMDLINE_ADDR, TARGET_PAGE_SIZE, kernel_cmdline);
+ pstrcpy_targphys("cmdline", CMDLINE_ADDR, TARGET_PAGE_SIZE, kernel_cmdline);
} else {
fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_CMDLINE, 0);
}
diff --git a/hw/ppc_oldworld.c b/hw/ppc_oldworld.c
index 79f17e8..3f23713 100644
--- a/hw/ppc_oldworld.c
+++ b/hw/ppc_oldworld.c
@@ -384,7 +384,7 @@ static void ppc_heathrow_init (ram_addr_t ram_size,
fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_SIZE, kernel_size);
if (kernel_cmdline) {
fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_CMDLINE, CMDLINE_ADDR);
- pstrcpy_targphys(CMDLINE_ADDR, TARGET_PAGE_SIZE, kernel_cmdline);
+ pstrcpy_targphys("cmdline", CMDLINE_ADDR, TARGET_PAGE_SIZE, kernel_cmdline);
} else {
fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_CMDLINE, 0);
}
diff --git a/hw/r2d.c b/hw/r2d.c
index f8a5968..c074a6e 100644
--- a/hw/r2d.c
+++ b/hw/r2d.c
@@ -250,7 +250,7 @@ static void r2d_init(ram_addr_t ram_size,
SDRAM_BASE + LINUX_LOAD_OFFSET,
SDRAM_SIZE - LINUX_LOAD_OFFSET);
env->pc = (SDRAM_BASE + LINUX_LOAD_OFFSET) | 0xa0000000;
- pstrcpy_targphys(SDRAM_BASE + 0x10100, 256, kernel_cmdline);
+ pstrcpy_targphys("cmdline", SDRAM_BASE + 0x10100, 256, kernel_cmdline);
} else {
kernel_size = load_image_targphys(kernel_filename, SDRAM_BASE, SDRAM_SIZE);
env->pc = SDRAM_BASE | 0xa0000000; /* Start from P2 area */
diff --git a/hw/sun4m.c b/hw/sun4m.c
index 01c7cb4..144bec1 100644
--- a/hw/sun4m.c
+++ b/hw/sun4m.c
@@ -299,6 +299,7 @@ static unsigned long sun4m_load_kernel(const char *kernel_filename,
int linux_boot;
unsigned int i;
long initrd_size, kernel_size;
+ uint8_t *ptr;
linux_boot = (kernel_filename != NULL);
@@ -341,9 +342,10 @@ static unsigned long sun4m_load_kernel(const char *kernel_filename,
}
if (initrd_size > 0) {
for (i = 0; i < 64 * TARGET_PAGE_SIZE; i += TARGET_PAGE_SIZE) {
- if (ldl_phys(KERNEL_LOAD_ADDR + i) == 0x48647253) { // HdrS
- stl_phys(KERNEL_LOAD_ADDR + i + 16, INITRD_LOAD_ADDR);
- stl_phys(KERNEL_LOAD_ADDR + i + 20, initrd_size);
+ ptr = rom_ptr(KERNEL_LOAD_ADDR + i);
+ if (ldl_p(ptr) == 0x48647253) { // HdrS
+ stl_p(ptr + 16, INITRD_LOAD_ADDR);
+ stl_p(ptr + 20, initrd_size);
break;
}
}
@@ -875,7 +877,7 @@ static void sun4m_hw_init(const struct sun4m_hwdef *hwdef, ram_addr_t RAM_size,
fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_SIZE, kernel_size);
if (kernel_cmdline) {
fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_CMDLINE, CMDLINE_ADDR);
- pstrcpy_targphys(CMDLINE_ADDR, TARGET_PAGE_SIZE, kernel_cmdline);
+ pstrcpy_targphys("cmdline", CMDLINE_ADDR, TARGET_PAGE_SIZE, kernel_cmdline);
} else {
fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_CMDLINE, 0);
}
@@ -1457,7 +1459,7 @@ static void sun4d_hw_init(const struct sun4d_hwdef *hwdef, ram_addr_t RAM_size,
fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_SIZE, kernel_size);
if (kernel_cmdline) {
fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_CMDLINE, CMDLINE_ADDR);
- pstrcpy_targphys(CMDLINE_ADDR, TARGET_PAGE_SIZE, kernel_cmdline);
+ pstrcpy_targphys("cmdline", CMDLINE_ADDR, TARGET_PAGE_SIZE, kernel_cmdline);
} else {
fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_CMDLINE, 0);
}
@@ -1645,7 +1647,7 @@ static void sun4c_hw_init(const struct sun4c_hwdef *hwdef, ram_addr_t RAM_size,
fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_SIZE, kernel_size);
if (kernel_cmdline) {
fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_CMDLINE, CMDLINE_ADDR);
- pstrcpy_targphys(CMDLINE_ADDR, TARGET_PAGE_SIZE, kernel_cmdline);
+ pstrcpy_targphys("cmdline", CMDLINE_ADDR, TARGET_PAGE_SIZE, kernel_cmdline);
} else {
fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_CMDLINE, 0);
}
diff --git a/hw/sun4u.c b/hw/sun4u.c
index 58d708a..30f5138 100644
--- a/hw/sun4u.c
+++ b/hw/sun4u.c
@@ -651,7 +651,7 @@ static void sun4uv_init(ram_addr_t RAM_size,
fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_SIZE, kernel_size);
if (kernel_cmdline) {
fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_CMDLINE, CMDLINE_ADDR);
- pstrcpy_targphys(CMDLINE_ADDR, TARGET_PAGE_SIZE, kernel_cmdline);
+ pstrcpy_targphys("cmdline", CMDLINE_ADDR, TARGET_PAGE_SIZE, kernel_cmdline);
} else {
fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_CMDLINE, 0);
}
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH 1/4] signals: SEND_SIG_NOINFO should be considered as SI_FROMUSER()
From: Oleg Nesterov @ 2009-10-07 11:30 UTC (permalink / raw)
To: Roland McGrath
Cc: Andrew Morton, Sukadev Bhattiprolu, Daniel Lezcano,
Sukadev Bhattiprolu, Linux Containers, linux-kernel
In-Reply-To: <20091006175705.6547A22@magilla.sf.frob.com>
On 10/06, Roland McGrath wrote:
>
> > Perhaps, we should add the comment to explain that both SI_FROMUSER()
> > and si_fromuser() are only valid in the sending pathes.
>
> Yes. Also now that you put them both in a sentence together, it is clear
> that it is insane to have two different things with those two names that
> differ only in capitalization.
I think this doesn't matter because we need more cleanups. As for naming
I agree, si_fromuser() sucks and I'd be happy to send the patch which
renames it (or re-send these 2 patches).
The problem is, both SI_FROMUSER() and SI_FROMKERNEL() must die imho.
In fact I think they should never exist.
SI_FROMUSER(siptr) ((siptr)->si_code <= 0)
note "<=", this means this helper is unuseable. What we need is another
macro/inline which checks "si_code < 0" (or >= 0 depending on naming),
this helper should be used by sys_sigqueueinfo/etc which can not not use
SI_FROMXXX() because SI_USER is rightly forbidden. __send_signal() can
use the new helper too.
Other cleanups which imho makes sense:
- rename SEND_SIG_XXX
- redefine them to make sure SEND_SIG_NOINFO != NULL
Oleg.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 3/6] virtio-console: Add a virtio-console bus, support for multiple ports
From: Gerd Hoffmann @ 2009-10-07 11:33 UTC (permalink / raw)
To: Amit Shah; +Cc: qemu-devel
In-Reply-To: <20091007100641.GC29515@amit-x200.redhat.com>
On 10/07/09 12:06, Amit Shah wrote:
>> Oh, I thought it would create a new virtio-serial-bus (plus auto-created
>> port0 console) unconditionally. Just do enougth to keep existing users
>> of the switch working.
>>
>> If you want new features (i.e. two consoles ports attached to one
>> virtio-serial-bus device) you must use the new syntax.
>
> So it's better overall to drop the old syntax altogether, right? It
> could get easily confusing otherwise.
>
> We can easily end up having:
>
> -virtioconsole<chardev>
> <auto-creates a bus and attaches a console port to it>
>
> -device virtio-serial-pci,id=blah
> <a second bus>
>
> -device virtport,bus=blah.0
>
> <and no way to connect a device to the bus that got created by
> virtioconsole>
It isn't that bad.
First, the busses get names based on the bus type by default, i.e. when
creating a scsi adapter without specifying id=seomthing the bus is
simply named "scsi.0". Likewise the -virtioconsole created bus would be
"port.0" or simliar (depends on the name in BusInfo).
Second, the bus= argument is optional. If not specified, qdev will pick
the first bus of a matching type it finds. So as long you have a single
port/scsi/usb/... bus only you don't need bus= at all. You can do:
-virtioconsole <chardev> -device virtport,<args>
and it will work just fine (creating a bus with the autocreated console
and additionally a virtport device attached to the same bus).
cheers,
Gerd
^ permalink raw reply
* Re: [PATCH 30/45] vmscan: lumpy pageout
From: Nick Piggin @ 2009-10-07 11:32 UTC (permalink / raw)
To: Wu Fengguang
Cc: Nikita Danilov, Andrew Morton, Theodore Tso, Christoph Hellwig,
Dave Chinner, Chris Mason, Peter Zijlstra, Li, Shaohua,
Myklebust Trond, jens.axboe@oracle.com, Jan Kara,
linux-fsdevel@vger.kernel.org
In-Reply-To: <20091007111454.GB15936@localhost>
On Wed, Oct 07, 2009 at 07:14:54PM +0800, Wu Fengguang wrote:
> On Wed, Oct 07, 2009 at 06:38:37PM +0800, Nikita Danilov wrote:
> > Hello,
> >
> > > When pageout a dirty page, try to piggy back more consecutive dirty
> > > pages (up to 512KB) to improve IO efficiency.
> > >
> > > Only ext3/reiserfs which don't have its own aops->writepages are
> > > supported in this initial version.
> > >
> >
> > [...]
> >
> > > /*
> > > + * only write_cache_pages() supports for_reclaim for now
> > > + */
> > > + if (!mapping->a_ops->writepages) {
> > > + wbc.range_start = (page->index + 1) << PAGE_CACHE_SHIFT;
> > > + wbc.nr_to_write = LUMPY_PAGEOUT_PAGES - 1;
> > > + generic_writepages(mapping, &wbc);
> > > + }
> >
> > This might end up calling ->writepage() on a page_mapped() page,
> > which used to be a problem, at least for shmem (see
> > BUG_ON(page_mapped(page)) in shmem_writepage()).
>
> Good catch, thanks a lot!
You also have a problem in that you aren't allowed to touch mapping
after the page is unlocked. So this patch looks buggy. I didn't see
where Nikita mentions the inode reclaim race, but this is it.
It seems tempting to do this lumpy writeout here, but... hmm, I
don't know. I would like to see workloads where it matters now,
and then I would like to know why normal writeout doesn't keep
up.
Then... maybe it's enough simply to allow the filesystem to do
their own clustering because they can tell when writepage is called
for reclaim.
But if you have real cases where this helps, it would be very
interesting.
^ permalink raw reply
* [Buildroot] [PATCH 12/23] qt: respect silent mode instead non existing verbose mode
From: Peter Korsgaard @ 2009-10-07 11:30 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20091007112738.GH10261@mx.loc>
>>>>> "Bernhard" == Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> writes:
Hi,
Bernhard> can't you use the configure invocation of autotools.in?
Bernhard> $(if $(VERBOSE),--verbose,$(if $(SILENT),--silent,))
Bernhard> (modulo real names) i.e. if VERBOSE is set, use it, else maybe use
Bernhard> silent or just leave it at defaults.
We already do something like that for QUIET, E.G. configure gets a -q
argument to make it shut up.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 1/4] signals: SEND_SIG_NOINFO should be considered as SI_FROMUSER()
From: Oleg Nesterov @ 2009-10-07 11:30 UTC (permalink / raw)
To: Roland McGrath
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linux Containers,
Andrew Morton, Sukadev Bhattiprolu, Daniel Lezcano
In-Reply-To: <20091006175705.6547A22-nL1rrgvulkc2UH6IwYuUx0EOCMrvLtNR@public.gmane.org>
On 10/06, Roland McGrath wrote:
>
> > Perhaps, we should add the comment to explain that both SI_FROMUSER()
> > and si_fromuser() are only valid in the sending pathes.
>
> Yes. Also now that you put them both in a sentence together, it is clear
> that it is insane to have two different things with those two names that
> differ only in capitalization.
I think this doesn't matter because we need more cleanups. As for naming
I agree, si_fromuser() sucks and I'd be happy to send the patch which
renames it (or re-send these 2 patches).
The problem is, both SI_FROMUSER() and SI_FROMKERNEL() must die imho.
In fact I think they should never exist.
SI_FROMUSER(siptr) ((siptr)->si_code <= 0)
note "<=", this means this helper is unuseable. What we need is another
macro/inline which checks "si_code < 0" (or >= 0 depending on naming),
this helper should be used by sys_sigqueueinfo/etc which can not not use
SI_FROMXXX() because SI_USER is rightly forbidden. __send_signal() can
use the new helper too.
Other cleanups which imho makes sense:
- rename SEND_SIG_XXX
- redefine them to make sure SEND_SIG_NOINFO != NULL
Oleg.
^ permalink raw reply
* Re: [Qemu-devel] Re: [PATCH 16/23] pci: pcie host and mmcfg support.
From: Akio Takebe @ 2009-10-07 11:30 UTC (permalink / raw)
To: Isaku Yamahata, Michael S. Tsirkin; +Cc: qemu-devel
In-Reply-To: <20091006100259.GE32367%yamahata@valinux.co.jp>
>> So I thought about this some more, and I think that this change
>> in unnecessary. PCI Express adds support for extended 4K
>> configuration space, but the only thing that must reside
>> there is the optional advanced error reporting capability,
>> which I don't think we'll need to implement, ever.
>>
>> Everything else can reside in the first 256 bytes, just as for regular
>> PCI. And pci code already returns 0 for accesses outside the first 256
>> bytes, so express specific code is necessary.
>
>I agree with you for emulated PCI express device
>(which doesn't exist for now). However I oppose it for other reason.
>
>My purpose is to direct attach PCIe device to a guest including
>AER emulation somehow.
>When direct attaching PCIe native device to a guest,
>we don't have any control on how its configuration space is used.
>When an error is reported on host via AER, I'd like to pass
>the error to guest in some manner. So I want AER too in a sense.
I also want AER feature. In this PCIe emulator codes,
PCIe features like AER is highlight.
If we can use AER, this pcie emulator is very worthwhile, I think.
Best Regards,
Akio Takebe
^ permalink raw reply
* Re: spitz: add gpio button support (AK_INT and remote control description)
From: Stanislav Brabec @ 2009-10-07 11:29 UTC (permalink / raw)
To: Pavel Machek
Cc: rpurdie, lenz, kernel list, Dirk, arminlitzel, Cyril Hrubis,
thommycheck, linux-arm-kernel, dbaryshkov, omegamoon, eric.y.miao,
Mark Brown
In-Reply-To: <20091007085806.GB28807@elf.ucw.cz>
Pavel Machek wrote:
> On Tue 2009-10-06 13:48:52, Stanislav Brabec wrote:
> > Pavel Machek wrote:
> > > I'm not sure what AK_INT is, nor what event it should
> > > generate.
> >
> > AK_INT: remote control detect
>
> Thanks. So for now I'll do:
>
> /* This is for remote control support. Zaurus supports wired
> remote on headphones. */
> {
> .type = EV_KEY,
> .code = KEY_F13,
> .gpio = SPITZ_GPIO_AK_INT,
> .desc = "Wired remote (AK_INT)",
> },
>
> ..and leave it for proper driver to support nicely.
I think that AK_INT should not generate key press event. Permanently
pressed key could confuse many programs.
But we may want to use switch events. I propose to create new switch
event for it: SW_REMOTE_INSERT. But mapping of AK_INT to
SW_REMOTE_INSERT cannot be straightforward.
That is why I propose to ignore AK_INT for now.
Following implementation may be used later (with future resistor matrix
keyboard driver):
Map SPITZ_GPIO_HP_IN to SW_JACK_PHYSICAL_INSERT (after debouncing).
Generate SW_REMOTE_INSERT if:
- SW_JACK_PHYSICAL_INSERT is on AK_INT is active and remote pin has full
voltage
or
- SW_JACK_PHYSICAL_INSERT is on and remote driver shows valid value
SW_REMOTE_INSERT should be recognized by the Jack abstraction layer
(sound/core/jack.c).
Well, I am thinking about defining extra values for resistors, that can
make stuff even more useful at cost of need of non-standard wiring on
fourth ring of the audio jack. It can generate SW_MICROPHONE_INSERT,
SW_LINEOUT_INSERT, and not yet defined SW_HEADESET_INSERT and
SW_LINEIN_INSERT (which would require hardware mod inside Zaurus for
stereo line-in).
The default may be SW_HEADPHONE_INSERT (short connection between remote
pin and ground).
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz
Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz/
^ permalink raw reply
* spitz: add gpio button support (AK_INT and remote control description)
From: Stanislav Brabec @ 2009-10-07 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20091007085806.GB28807@elf.ucw.cz>
Pavel Machek wrote:
> On Tue 2009-10-06 13:48:52, Stanislav Brabec wrote:
> > Pavel Machek wrote:
> > > I'm not sure what AK_INT is, nor what event it should
> > > generate.
> >
> > AK_INT: remote control detect
>
> Thanks. So for now I'll do:
>
> /* This is for remote control support. Zaurus supports wired
> remote on headphones. */
> {
> .type = EV_KEY,
> .code = KEY_F13,
> .gpio = SPITZ_GPIO_AK_INT,
> .desc = "Wired remote (AK_INT)",
> },
>
> ..and leave it for proper driver to support nicely.
I think that AK_INT should not generate key press event. Permanently
pressed key could confuse many programs.
But we may want to use switch events. I propose to create new switch
event for it: SW_REMOTE_INSERT. But mapping of AK_INT to
SW_REMOTE_INSERT cannot be straightforward.
That is why I propose to ignore AK_INT for now.
Following implementation may be used later (with future resistor matrix
keyboard driver):
Map SPITZ_GPIO_HP_IN to SW_JACK_PHYSICAL_INSERT (after debouncing).
Generate SW_REMOTE_INSERT if:
- SW_JACK_PHYSICAL_INSERT is on AK_INT is active and remote pin has full
voltage
or
- SW_JACK_PHYSICAL_INSERT is on and remote driver shows valid value
SW_REMOTE_INSERT should be recognized by the Jack abstraction layer
(sound/core/jack.c).
Well, I am thinking about defining extra values for resistors, that can
make stuff even more useful at cost of need of non-standard wiring on
fourth ring of the audio jack. It can generate SW_MICROPHONE_INSERT,
SW_LINEOUT_INSERT, and not yet defined SW_HEADESET_INSERT and
SW_LINEIN_INSERT (which would require hardware mod inside Zaurus for
stereo line-in).
The default may be SW_HEADPHONE_INSERT (short connection between remote
pin and ground).
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o. e-mail: sbrabec at suse.cz
Lihovarsk? 1060/12 tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz/
^ permalink raw reply
* Re: XFS/driver bug or bad drive?
From: Michael-John Turner @ 2009-10-07 11:29 UTC (permalink / raw)
To: David Engel; +Cc: Eric Sandeen, xfs
In-Reply-To: <20091002165704.GA17558@opus.istwok.net>
On Fri, Oct 02, 2009 at 11:57:04AM -0500, David Engel wrote:
> I agree it shouldn't be an xfs bug. I thought it was strange, though,
> that the problem only seemed to show up with xfs on 2.6.30.x. IO
> pattern sensitivity wouldn't surprise me, but I wanted to check all my
> bases before giving up on the drive.
Rather curiously, I had exactly the same issue with the same model drive
this past weekend. Debian-patched 2.6.26 kernel, however, though also with
XFS (on top of md/LVM). Interestingly, there were no SMART errors and a
full SMART test passed. The error was triggered by doing a cvs update on my
working copy of the NetBSD source tree - not a large copy, but a
disk-intensive activity.
-mj
--
Michael-John Turner
mj@mjturner.net <> http://mjturner.net/
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* [Buildroot] [PATCH 12/23] qt: respect silent mode instead non existing verbose mode
From: Peter Korsgaard @ 2009-10-07 11:27 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20091007130206.1a6f9821@surf>
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Thomas> Le Wed, 7 Oct 2009 12:30:43 +0200,
Thomas> Michael Roth <mroth@nessie.de> a ?crit :
>> Commit 89464a96015e89da07b87d18b31f4b25b4c890ba introduced QUIET.
Thomas> Hum correct. My tree was in branch not rebased against the very latest
Thomas> Buildroot git.
FYI, that commit just reintroduced it, as it got lost in the
reorganization. We've had it for ~1 year before that (43af3d3578(.
>> But you're right. I overlooked VERBOSE. Maybe this should be split
>> into two ifs?
Thomas> I think we should make a formal decision on the respective semantic of
Thomas> VERBOSE and QUIET, because the difference between these two variables
Thomas> is not clear to me.
Yes, it's a bit of a mess. Is there anything using VERBOSE yet? The
complains with BR has historically been that it has been TOO verbose,
not too less.
Maybe this would be a good subject for the dev day?
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [PATCH 12/23] qt: respect silent mode instead non existing verbose mode
From: Bernhard Reutner-Fischer @ 2009-10-07 11:27 UTC (permalink / raw)
To: buildroot
In-Reply-To: <200910071230.48080.mroth@nessie.de>
On Wed, Oct 07, 2009 at 12:30:43PM +0200, Michael Roth wrote:
>Am Wednesday 07 October 2009 11:57:41 schrieb Thomas Petazzoni:
>> I'm not sure about this one. In the main Makefile, we definitely define
>> VERBOSE, but not QUIET.
>
>Commit 89464a96015e89da07b87d18b31f4b25b4c890ba introduced QUIET.
>
>But you're right. I overlooked VERBOSE. Maybe this should be split
>into two ifs?
can't you use the configure invocation of autotools.in?
$(if $(VERBOSE),--verbose,$(if $(SILENT),--silent,))
(modulo real names) i.e. if VERBOSE is set, use it, else maybe use
silent or just leave it at defaults.
^ permalink raw reply
* Re: [v7 PATCH 0/7]: cpuidle/x86/POWER: Cleanup idle power management code in x86, cleanup drivers/cpuidle/cpuidle.c and introduce cpuidle to POWER.
From: Vaidyanathan Srinivasan @ 2009-10-07 11:26 UTC (permalink / raw)
To: Peter Zijlstra, Arjan van de Ven
Cc: arun, Joel Schopp, Benjamin Herrenschmidt, Paul Mackerras,
Ingo Molnar, Dipankar Sarma, Balbir Singh, Gautham R Shenoy,
Venkatesh Pallipadi, linux-kernel, linuxppc-dev, linux-arch
In-Reply-To: <1254852279.17055.2.camel@laptop>
* Peter Zijlstra <a.p.zijlstra@chello.nl> [2009-10-06 20:04:39]:
> On Tue, 2009-10-06 at 22:05 +0530, Arun R Bharadwaj wrote:
>
> > Also, the per-cpu nature of registration/unregistration of cpuidle
> > has been maintained as ACPI needs this.
>
> Right, so can't we ditch that and have acpi default to the lowest common
> C-state and warn when various cpus report different C-states?
Hi Peter,
As Arjan mentioned previously, the per-cpu registration has to stay
for x86 for now due to legacy ACPI compatibility. Breaking that may
break lot of existing users and we do not have a clean fallback
method.
As far as powerpc is concerned, we can work with a single global
registration. However we would like to have the same interface across
different archs.
With the new re-factoring (v7), Arun has killed most of the list
traversal and linking between various cpu's cpuidle_driver structures.
Now we have a per-cpu stack of registered devices and we lookup the
structs using online cpumasks. The cpuidle_driver structure has list
of idle routing pointers (struct cpuidle_state) and rest of it is
statistics that needs to be maintained at a per-cpu level anyway. All
that is duplicated here is the array of idle routines (struct
cpuidle_state) on each cpu.
The objective of the refactoring is to have a single common idle
routine management framework (remove pm_idle) and we have it done
through cpuidle registration framework. We can incrementally remove
the per-cpu registration later easily by splitting the cpuidle_driver
structure.
--Vaidy
^ permalink raw reply
* Re: [v7 PATCH 0/7]: cpuidle/x86/POWER: Cleanup idle power management code in x86, cleanup drivers/cpuidle/cpuidle.c and introduce cpuidle to POWER.
From: Vaidyanathan Srinivasan @ 2009-10-07 11:26 UTC (permalink / raw)
To: Peter Zijlstra, Arjan van de Ven
Cc: linux-arch, Gautham R Shenoy, Venkatesh Pallipadi, linux-kernel,
Paul Mackerras, arun, Ingo Molnar, linuxppc-dev
In-Reply-To: <1254852279.17055.2.camel@laptop>
* Peter Zijlstra <a.p.zijlstra@chello.nl> [2009-10-06 20:04:39]:
> On Tue, 2009-10-06 at 22:05 +0530, Arun R Bharadwaj wrote:
>
> > Also, the per-cpu nature of registration/unregistration of cpuidle
> > has been maintained as ACPI needs this.
>
> Right, so can't we ditch that and have acpi default to the lowest common
> C-state and warn when various cpus report different C-states?
Hi Peter,
As Arjan mentioned previously, the per-cpu registration has to stay
for x86 for now due to legacy ACPI compatibility. Breaking that may
break lot of existing users and we do not have a clean fallback
method.
As far as powerpc is concerned, we can work with a single global
registration. However we would like to have the same interface across
different archs.
With the new re-factoring (v7), Arun has killed most of the list
traversal and linking between various cpu's cpuidle_driver structures.
Now we have a per-cpu stack of registered devices and we lookup the
structs using online cpumasks. The cpuidle_driver structure has list
of idle routing pointers (struct cpuidle_state) and rest of it is
statistics that needs to be maintained at a per-cpu level anyway. All
that is duplicated here is the array of idle routines (struct
cpuidle_state) on each cpu.
The objective of the refactoring is to have a single common idle
routine management framework (remove pm_idle) and we have it done
through cpuidle registration framework. We can incrementally remove
the per-cpu registration later easily by splitting the cpuidle_driver
structure.
--Vaidy
^ 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.