* Re: [RFC: 2.6 patch] remove drivers/net/eepro100.c
From: David S. Miller @ 2005-11-23 22:39 UTC (permalink / raw)
To: rmk+lkml; +Cc: jgarzik, bunk, saw, linux-kernel, netdev
In-Reply-To: <20051123221547.GM15449@flint.arm.linux.org.uk>
From: Russell King <rmk+lkml@arm.linux.org.uk>
Date: Wed, 23 Nov 2005 22:15:48 +0000
> I leave it up to you how to proceed. Effectively I'm now completely
> out of the loop on this with no hardware to worry about. Sorry.
>
> Finally, please don't assign any blame for this in my direction; I
> reported it and I kept bugging people about it, and in spite of my
> best efforts there was very little which was forthcoming. Obviously
> that wasn't enough.
I think you're being unreasonable.
They've worked on a fix for the problem, and now you're unable to test
the fix, and you're angry at them because they took so long to code up
the fix.
If you're overextended and have too much work to do and that's
stressing you out, that doesn't give you permission to take it
out on other people.
^ permalink raw reply
* Re: [RFC] [PATCH 1/3] ioat: DMA subsystem
From: Jeff Garzik @ 2005-11-23 22:44 UTC (permalink / raw)
To: Andrew Grover; +Cc: netdev, linux-kernel, john.ronciak, christopher.leech
In-Reply-To: <Pine.LNX.4.44.0511231207410.32487-100000@isotope.jf.intel.com>
Mostly ok, but some minor nits.
Andrew Grover wrote:
> index 0000000..f2cc2d7
> --- /dev/null
> +++ b/drivers/dma/cb_list.h
> @@ -0,0 +1,12 @@
> +/* Extra macros that build on <linux/list.h> */
> +#ifndef CB_LIST_H
> +#define CB_LIST_H
> +
> +#include <linux/list.h>
> +
> +/* Provide some safty to list_add, which I find easy to swap the arguments to */
> +
> +#define list_add_entry(pos, head, member) list_add(&pos->member, head)
> +#define list_add_entry_tail(pos, head, member) list_add_tail(&pos->member, head)
> +
> +#endif /* CB_LIST_H */
Maybe this just adds fuel to the fire, given your code comment, but I
tend to think most people are used to
object_foo(object, other args...)
where the object in question is "the list". That would imply a
list_foo(head, others args...)
pattern.
As a side note, I have the same problem as you, WRT swapping the
list_add arguments. I've always thought that was the one big drawback
to Linus's otherwise elegant list implementation.
general nits:
1) docbook-able function headers, with useful documentation, would be
nice. Using libata as an example, even if I don't provide any useful
function description, I at least document the locking details/context
for each function.
2) more inline code commenting would be nice.
> + if (chan->device->device_alloc_chan_resources(chan) >= 0) {
> + chan->client = client;
> + list_add_entry_tail(chan, &client->channels, client_node);
> + return chan;
> + }
device_alloc_chan_resources is a very long name. :)
> +static void
> +dma_client_chan_free(struct dma_chan *chan)
> +{
> + BUG_ON(!chan);
> +
> + chan->device->device_free_chan_resources(chan);
> + chan->client = NULL;
> +}
ditto
> +static void
> +dma_chans_rebalance(void)
explanation of this function would be nice. remember to answer "how?"
and "why?", not "what?".
> +{
> + struct dma_client *client;
> + struct dma_chan *chan;
> +
> + list_for_each_entry(client, &dma_client_list, global_node) {
locking of dma_client_list?
> + while (client->chans_desired > client->chan_count) {
> + chan = dma_client_chan_alloc(client);
> + if (!chan)
> + break;
> +
> + client->chan_count++;
> + client->event_callback(client, chan, DMA_RESOURCE_ADDED);
> + }
> +
> + while (client->chans_desired < client->chan_count) {
> + chan = list_entry(client->channels.next, struct dma_chan, client_node);
> + list_del(&chan->client_node);
> + client->chan_count--;
> + client->event_callback(client, chan, DMA_RESOURCE_REMOVED);
> + dma_client_chan_free(chan);
In general, this DMA_RESOURCE_REMOVED operation feels like a "yanking
the carpet out from under my feet" operation, something we should avoid
for object-lifetime reasons.
However in this case, AFAICS dmaengine.c completely controls object
lifetime, so I do not see a real problem. I'm just nervous. :)
> + }
> + }
> +}
> +
> +struct dma_client *
> +dma_async_client_register(dma_event_callback event_callback)
> +{
> + struct dma_client *client;
> +
> + BUG_ON(!event_callback);
> +
> + client = kmalloc(sizeof(*client), GFP_KERNEL);
> + if (!client)
> + return NULL;
> +
> + INIT_LIST_HEAD(&client->channels);
> +
> + client->chans_desired = 0;
> + client->chan_count = 0;
> + client->event_callback = event_callback;
> +
> + list_add_entry_tail(client, &dma_client_list, global_node);
> +
> + return client;
Possible SMP bug here?
So far, in my code read, I was presuming that the caller was doing some
sort of locking on dma_client_list and dma_device_list. (Hint: need
locking docs for each function)
But if you are using GFP_KERNEL, it certainly appears that two callers
could race with each other when touching dma_client_list.
> +dma_cookie_t
> +dma_async_memcpy_buf_to_buf(
> + struct dma_chan *chan,
> + void *dest,
> + void *src,
> + size_t len)
> +{
> + chan->bytes_transferred += len;
> + chan->memcpy_count++;
> +
> + return chan->device->device_memcpy_buf_to_buf(chan, dest, src, len);
> +}
> +
> +dma_cookie_t
> +dma_async_memcpy_buf_to_pg(
> + struct dma_chan *chan,
> + struct page *page,
> + unsigned int offset,
> + void *kdata,
> + size_t len)
> +{
> + chan->bytes_transferred += len;
> + chan->memcpy_count++;
> +
> + return chan->device->device_memcpy_buf_to_pg(chan, page, offset, kdata, len);
> +}
> +
> +dma_cookie_t
> +dma_async_memcpy_pg_to_pg(
> + struct dma_chan *chan,
> + struct page *dest_pg,
> + unsigned int dest_off,
> + struct page *src_pg,
> + unsigned int src_off,
> + size_t len)
> +{
> + chan->bytes_transferred += len;
> + chan->memcpy_count++;
> +
> + return chan->device->device_memcpy_pg_to_pg(chan, dest_pg, dest_off,
> + src_pg, src_off, len);
> +}
> +
> +void
> +dma_async_memcpy_issue_pending(struct dma_chan *chan)
> +{
> + return chan->device->device_memcpy_issue_pending(chan);
> +}
> +
> +enum dma_status_t
> +dma_async_memcpy_complete(struct dma_chan *chan, dma_cookie_t cookie, dma_cookie_t *last, dma_cookie_t *used)
> +{
> + return chan->device->device_memcpy_complete(chan, cookie, last, used);
> +}
Making these 'static inline' might be a good idea?
> +int
> +dma_async_device_register(struct dma_device *device)
> +{
> + static int id;
> + int chancnt = 0;
> + struct dma_chan* chan;
> +
> + if (!device)
> + return -ENODEV;
> +
> + list_add_entry_tail(device, &dma_device_list, global_node);
> +
> + dma_chans_rebalance();
> +
> + device->dev_id = id++;
> +
> + /* represent channels in sysfs. Probably want devs too */
> + list_for_each_entry(chan, &device->channels, device_node) {
> + chan->chan_id = chancnt++;
> + chan->class_dev.class = &dma_devclass;
> + chan->class_dev.dev = NULL;
> + snprintf(chan->class_dev.class_id, BUS_ID_SIZE, "dma%dchan%d",
> + device->dev_id, chan->chan_id);
> +
> + chan->min_copy_size = DMA_DEFAULT_MIN_COPY_SIZE;
> + class_device_register(&chan->class_dev);
> + }
> +
> + return 0;
> +}
> +
> +void
> +dma_async_device_unregister(struct dma_device* device)
> +{
> + struct dma_chan *chan;
> +
> + BUG_ON(!device);
> +
> + list_for_each_entry(chan, &device->channels, device_node) {
> + if (chan->client) {
> + list_del(&chan->client_node);
> + chan->client->chan_count--;
> + chan->client->event_callback(chan->client, chan, DMA_RESOURCE_REMOVED);
> + dma_client_chan_free(chan);
> + }
> + class_device_unregister(&chan->class_dev);
> + }
> +
> + list_del(&device->global_node);
> +
> + dma_chans_rebalance();
> +}
> +
> +static struct workqueue_struct *dma_wait_wq;
> +static LIST_HEAD(dma_poll_list);
> +
> +enum dma_status_t
> +dma_async_wait_for_completion(struct dma_chan *chan, dma_cookie_t cookie)
> +{
> + while (dma_async_memcpy_complete(chan, cookie, NULL, NULL) == DMA_IN_PROGRESS)
> + schedule();
1) Is it worth adding a loop above the 'while', which does
retries = 5
while (operation == in progress &&
retries-- > 0)
udelay(1)
2) at that point, perhaps replace schedule() with schedule_timeout(1).
WARNING: this might introduce too much latency, and be a bad idea.
> + return DMA_SUCCESS;
> +}
> +
> +#if 0
> +static void
> +dma_poll(void *data)
> +{
> + struct dma_completion *comp = data;
> +
> + comp->status = dma_memcpy_complete(comp->chan, comp->cookie);
> + while (comp->status == DMA_IN_PROGRESS) {
> + comp->chan->device->device_arm_interrupt(comp->chan);
> + wait_for_completion(&__get_cpu_var(kick_dma_poll));
> + comp->status = dma_memcpy_complete(comp->chan, comp->cookie);
> + }
> + complete(&comp->comp);
> +}
> +
> +enum dma_status_t
> +dma_wait_for_completion(struct dma_chan *chan, dma_cookie_t cookie)
> +{
> + enum dma_status_t status;
> + DECLARE_DMA_COMPLETION(comp, chan, cookie);
> + DECLARE_WORK(dma_wait_work, dma_poll, &comp);
> +
> + BUG_ON(in_interrupt());
> +
> + status = dma_memcpy_complete(chan, cookie);
> + if (status != DMA_IN_PROGRESS)
> + return status;
> +
> + queue_work(dma_wait_wq, &dma_wait_work);
> + wait_for_completion(&comp.comp);
> + return comp.status;
> +}
> +#endif
is this for future use? never to be used?
> +static int __init dma_bus_init(void)
> +{
> + int cpu;
> +
> + dma_wait_wq = create_workqueue("dmapoll");
dma_wait_wq is never used, due to #if 0
> + for_each_online_cpu(cpu) {
> + init_completion(&per_cpu(kick_dma_poll, cpu));
> + }
> + return class_register(&dma_devclass);
> +}
> +
> +subsys_initcall(dma_bus_init);
> +
> +EXPORT_SYMBOL(dma_async_client_register);
> +EXPORT_SYMBOL(dma_async_client_unregister);
> +EXPORT_SYMBOL(dma_async_client_chan_request);
> +EXPORT_SYMBOL(dma_async_memcpy_buf_to_buf);
> +EXPORT_SYMBOL(dma_async_memcpy_buf_to_pg);
> +EXPORT_SYMBOL(dma_async_memcpy_pg_to_pg);
> +EXPORT_SYMBOL(dma_async_memcpy_complete);
> +EXPORT_SYMBOL(dma_async_memcpy_issue_pending);
> +EXPORT_SYMBOL(dma_async_device_register);
> +EXPORT_SYMBOL(dma_async_device_unregister);
> +EXPORT_SYMBOL(dma_async_wait_for_completion);
> +EXPORT_PER_CPU_SYMBOL(kick_dma_poll);
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> new file mode 100644
> index 0000000..7b4f58b
> --- /dev/null
> +++ b/include/linux/dmaengine.h
> @@ -0,0 +1,268 @@
> +/*******************************************************************************
> +
> +
> + Copyright(c) 2004 - 2005 Intel Corporation. All rights reserved.
> +
> + This program is free software; you can redistribute it and/or modify it
> + under the terms of the GNU General Public License as published by the Free
> + Software Foundation; either version 2 of the License, or (at your option)
> + any later version.
> +
> + This program is distributed in the hope that it will be useful, but WITHOUT
> + ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + more details.
> +
> + You should have received a copy of the GNU General Public License along with
> + this program; if not, write to the Free Software Foundation, Inc., 59
> + Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> +
> + The full GNU General Public License is included in this distribution in the
> + file called LICENSE.
> +
> +*******************************************************************************/
> +
> +
> +#ifndef DMAENGINE_H
> +#define DMAENGINE_H
> +
> +#include <linux/device.h>
> +#include <linux/uio.h>
> +#include <linux/skbuff.h>
> +
> +DECLARE_PER_CPU(struct completion, kick_dma_poll);
> +
> +#define DMA_DEFAULT_MIN_COPY_SIZE 16
> +
> +/**
> + * enum dma_event_t - resource PNP/power managment events
> + * @DMA_RESOURCE_SUSPEND: DMA device going into low power state
> + * @DMA_RESOURCE_RESUME: DMA device returning to full power
> + * @DMA_RESOURCE_ADDED: DMA device added to the system
> + * @DMA_RESOURCE_REMOVED: DMA device removed from the system
> + */
> +enum dma_event_t {
> + DMA_RESOURCE_SUSPEND,
> + DMA_RESOURCE_RESUME,
> + DMA_RESOURCE_ADDED,
> + DMA_RESOURCE_REMOVED,
> +};
> +
> +/**
> + * typedef dma_cookie_t
> + *
> + * if dma_cookie_t is >0 it's a DMA request cookie, <0 it's an error code
> + */
> +typedef s32 dma_cookie_t;
More natural to use [signed] long? i.e. a machine int. Or _must_ this
match hardware somewhere?
> +/*#define dma_submit_error(cookie) ((cookie) < 0 ? 1 : 0)*/
> +
> +/**
> + * enum dma_status_t - DMA transaction status
> + * @DMA_SUCCESS: transaction completed successfully
> + * @DMA_IN_PROGRESS: transaction not yet processed
> + * @DMA_ERROR: transaction failed
> + */
> +enum dma_status_t {
> + DMA_SUCCESS,
> + DMA_IN_PROGRESS,
> + DMA_ERROR,
> +};
> +
> +/**
> + * struct dma_chan - devices supply DMA channels, clients use them
> + * @client: ptr to the client user of this chan, will be NULL when unused
> + * @device: ptr to the dma device who supplies this channel, always !NULL
> + * @client_node: used to add this to the client chan list
> + * @device_node: used to add this to the device chan list
> + */
> +struct dma_chan
> +{
> + struct dma_client *client;
> + struct dma_device *device;
> + dma_cookie_t cookie;
> +
> + /* sysfs */
> + int chan_id;
> + struct class_device class_dev;
> +
> + /* stats */
> + unsigned long memcpy_count;
> + unsigned long bytes_transferred;
> + unsigned int min_copy_size;
very very minor nit, but it bugs me at least: the stats variables
strike me as overly long and verbose.
> + struct list_head client_node;
> + struct list_head device_node;
> +
> + cpumask_t cpumask;
> +};
> +
> +/*
> + * typedef dma_event_callback - function pointer to a DMA event callback
> + */
> +typedef void (*dma_event_callback) (struct dma_client *client, struct dma_chan *chan, enum dma_event_t event);
> +
> +/**
> + * struct dma_client - info on the entity making use of DMA services
> + * @event_callback: func ptr to call when something happens
> + * @chan_count: number of chans allocated
> + * @chans_desired: number of chans requested. Can be +- chan_count
> + * @port: upstream DMA port from the client's PCI device
> + * @channels: the list of DMA channels allocated
> + * @global_node: list_head for global dma_client_list
> + */
> +struct dma_client {
> + dma_event_callback event_callback;
> + unsigned int chan_count;
> + unsigned int chans_desired;
> +
> + /* TODO keep some stats */
> + struct list_head channels;
> + struct list_head global_node;
> +};
> +
> +/**
> + * struct dma_device - info on the entity supplying DMA services
> + * @chancnt: how many DMA channels are supported
> + * @channels: the list of struct dma_chan
> + * @global_node: list_head for global dma_device_list
> + * Other func ptrs: used to make use of this device's capabilities
> + */
> +struct dma_device {
> +
> + unsigned int chancnt;
> + struct list_head channels;
> + struct list_head global_node;
> +
> + int dev_id;
> + /*struct class_device class_dev;*/
> +
> + int (*device_alloc_chan_resources)(struct dma_chan *chan);
> + void (*device_free_chan_resources)(struct dma_chan *chan);
> + dma_cookie_t (*device_memcpy_buf_to_buf)(struct dma_chan *chan, void *dest,
> + void *src, size_t len);
> + dma_cookie_t (*device_memcpy_buf_to_pg)(struct dma_chan *chan, struct page *page,
> + unsigned int offset, void *kdata, size_t len);
> + dma_cookie_t (*device_memcpy_pg_to_pg)(struct dma_chan *chan, struct page *dest_pg,
> + unsigned int dest_off, struct page *src_pg, unsigned int src_off,
> + size_t len);
> + void (*device_arm_interrupt)(struct dma_chan *chan);
> + enum dma_status_t (*device_memcpy_complete)(struct dma_chan *chan, dma_cookie_t cookie, dma_cookie_t *last, dma_cookie_t *used);
> + void (*device_memcpy_issue_pending)(struct dma_chan *chan);
names feel a bit long
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Jeff Garzik @ 2005-11-23 22:45 UTC (permalink / raw)
To: Andrew Grover; +Cc: netdev, linux-kernel, john.ronciak, christopher.leech
In-Reply-To: <Pine.LNX.4.44.0511231143380.32487-100000@isotope.jf.intel.com>
Andrew Grover wrote:
> As presented in our talk at this year's OLS, the Bensley platform, which
> will be out in early 2006, will have an asyncronous DMA engine. It can be
> used to offload copies from the CPU, such as the kernel copies of received
> packets into the user buffer.
More than a one-paragraph description would be nice... URLs to OLS and
IDF presentations, other info?
Jeff
^ permalink raw reply
* Re: [RFC] [PATCH 2/3] ioat: user buffer pin; net DMA client register
From: Jeff Garzik @ 2005-11-23 22:46 UTC (permalink / raw)
To: Andrew Grover; +Cc: netdev, linux-kernel, john.ronciak, christopher.leech
In-Reply-To: <Pine.LNX.4.44.0511231215020.32487-100000@isotope.jf.intel.com>
A per-patch description would be nice, as DaveM mentioned... and also
please put a diffstat in each email.
Jeff
^ permalink raw reply
* Re: [RFC] [PATCH 3/3] ioat: testclient
From: Jeff Garzik @ 2005-11-23 22:53 UTC (permalink / raw)
To: Andrew Grover; +Cc: netdev, linux-kernel, john.ronciak, christopher.leech
In-Reply-To: <Pine.LNX.4.44.0511231217340.32487-100000@isotope.jf.intel.com>
Andrew Grover wrote:
> diff --git a/drivers/dma/testclient.c b/drivers/dma/testclient.c
> new file mode 100644
> index 0000000..9bfb979
> --- /dev/null
> +++ b/drivers/dma/testclient.c
> @@ -0,0 +1,132 @@
> +/*******************************************************************************
> +
> +
> + Copyright(c) 2004 - 2005 Intel Corporation. All rights reserved.
> +
> + This program is free software; you can redistribute it and/or modify it
> + under the terms of the GNU General Public License as published by the Free
> + Software Foundation; either version 2 of the License, or (at your option)
> + any later version.
> +
> + This program is distributed in the hope that it will be useful, but WITHOUT
> + ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + more details.
> +
> + You should have received a copy of the GNU General Public License along with
> + this program; if not, write to the Free Software Foundation, Inc., 59
> + Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> +
> + The full GNU General Public License is included in this distribution in the
> + file called LICENSE.
> +
> +*******************************************************************************/
> +
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/device.h>
> +#include <linux/dmaengine.h>
> +#include <linux/delay.h>
> +#include <asm/io.h>
> +
> +/* MODULE API */
> +
> +static volatile u8 *buffer1;
> +static volatile u8 *buffer2;
why do you think volatile is needed?
> +struct dma_client *test_dma_client;
> +struct dma_chan *test_dma_chan;
> +static dma_cookie_t cookie;
> +
> +void
> +test_added_chan(void)
> +{
> + int i;
> +
> + printk("buffer1 = %p\n", buffer1);
> + printk("buffer2 = %p\n", buffer2);
> + for (i = 0; i < 20; i+=4)
> + printk("%u %u %u %u\n", buffer2[i], buffer2[i+1], buffer2[i+2], buffer2[i+3]);
> +
> +// for (i = 0; i < 10; i++) {
> + cookie = dma_async_memcpy_buf_to_buf(test_dma_chan,
> + (void *)buffer2,
> + (void *)buffer1,
> + 2000);
> + dma_async_memcpy_issue_pending(test_dma_chan);
> +// }
> +// printk("dma cookie = %i\n", cookie);
> + if (dma_async_memcpy_complete(test_dma_chan, cookie, NULL, NULL) == DMA_IN_PROGRESS)
> + printk("DMA cookie == IN PROGRESS\n");
> + else
> + printk("DMA cookie == SUCCESS\n");
> +#if 0
> + for (i = 0; i < 1000; i++) {
> + if (buffer2[1] != 0)
> + break;
> + mdelay(1);
ummm....
> + printk("i = %d\n", i);
> + for (i = 0; i < 20; i+=4)
> + printk("%u %u %u %u\n", buffer2[i], buffer2[i+1], buffer2[i+2], buffer2[i+3]);
> + for (i = 0; i < 20; i+=4)
> + printk("%u %u %u %u\n", buffer1[i], buffer1[i+1], buffer1[i+2], buffer1[i+3]);
> +#endif
> +}
> +
> +void test_dma_event(struct dma_client *client, struct dma_chan *chan, enum dma_event_t event)
> +{
> + switch (event) {
> + case DMA_RESOURCE_ADDED:
> + test_dma_chan = chan;
> + test_added_chan();
> + break;
> + case DMA_RESOURCE_REMOVED:
> + test_dma_chan = NULL;
> + break;
> + default:
> + break;
> + }
> +}
what keeps DMA_RESOURCE_ADDED from being called multiple times?
What happens when there is more than one resource?
dma_async_client_chan_request(...,1) prevents this, perhaps?
> +static int __init
> +testclient_init_module(void)
> +{
> + int i;
> +
> + buffer1 = kmalloc(sizeof(u8) * 2000, SLAB_KERNEL);
> + buffer2 = kmalloc(sizeof(u8) * 2000, SLAB_KERNEL);
> + memset((void *)buffer2, 0, 2000);
1) GFP_KERNEL not SLAB_KERNEL
2) kzalloc()
3) be consistent: either use "2000" or "sizeof * 2000"
> + for (i = 0; i < 2000; i++)
> + buffer1[i] = i;
> + test_dma_client = dma_async_client_register(test_dma_event);
> + if (!test_dma_client) {
> + printk(KERN_ERR "Could not register dma client!\n");
> + return 0;
> + }
> +
> + dma_async_client_chan_request(test_dma_client, 1);
> +
> + return 0;
> +}
> +
> +module_init(testclient_init_module);
> +
> +static void __exit
> +testclient_exit_module(void)
> +{
> + int i;
> + for (i = 0; i < 20; i+=4)
> + printk("%u %u %u %u\n", buffer2[i], buffer2[i+1], buffer2[i+2], buffer2[i+3]);
> + if (dma_async_memcpy_complete(test_dma_chan, cookie, NULL, NULL) == DMA_SUCCESS)
> + printk("DMA cookie == SUCCESS\n");
> + else
> + printk("DMA cookie == IN PROGRESS\n");
> +
> + dma_async_client_unregister(test_dma_client);
> +}
> +
> +module_exit(testclient_exit_module);
> +
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" 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
* Re: [RFC: 2.6 patch] remove drivers/net/eepro100.c
From: Russell King @ 2005-11-23 22:53 UTC (permalink / raw)
To: David S. Miller; +Cc: jgarzik, bunk, saw, linux-kernel, netdev
In-Reply-To: <20051123.143946.41188551.davem@davemloft.net>
On Wed, Nov 23, 2005 at 02:39:46PM -0800, David S. Miller wrote:
> From: Russell King <rmk+lkml@arm.linux.org.uk>
> Date: Wed, 23 Nov 2005 22:15:48 +0000
>
> > I leave it up to you how to proceed. Effectively I'm now completely
> > out of the loop on this with no hardware to worry about. Sorry.
> >
> > Finally, please don't assign any blame for this in my direction; I
> > reported it and I kept bugging people about it, and in spite of my
> > best efforts there was very little which was forthcoming. Obviously
> > that wasn't enough.
>
> I think you're being unreasonable.
I think you're being unreasonable telling me that I'm being unreasonable.
> They've worked on a fix for the problem, and now you're unable to test
> the fix, and you're angry at them because they took so long to code up
> the fix.
>
> If you're overextended and have too much work to do and that's
> stressing you out, that doesn't give you permission to take it
> out on other people.
No. It's quite simple.
I've worked on trying to replicate the problem today. Tomorrow I'm
out at a meeting and since I'm no longer working on the problematical
hardware, it is being returned.
That means there's about 15 minutes left before I go to sleep before
having to be up early tomorrow to go on a 2 hour journey to attend a
meeting. What do you want me to do with those 15 minutes? Perform a
miracle maybe?
David, I ask you to retract your unreasonable mail. I'm being quite
calm here. I'm just pointing out the facts that as of *now* I'm no
longer in a position to test.
I was rather hoping that being crystal clear about the reasons about
_why_ I'm no longer able to continue participating in his problem
that I would be seen not to be unreasonable.
I guess I'm just cursed.
Sorry.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Jeff Garzik @ 2005-11-23 22:53 UTC (permalink / raw)
To: Andrew Grover; +Cc: netdev, linux-kernel, john.ronciak, christopher.leech
In-Reply-To: <Pine.LNX.4.44.0511231143380.32487-100000@isotope.jf.intel.com>
Andrew Grover wrote:
> overall diffstat information:
> drivers/Kconfig | 2
> drivers/Makefile | 1
> drivers/dma/Kconfig | 40 ++
> drivers/dma/Makefile | 5
> drivers/dma/cb_list.h | 12
> drivers/dma/dmaengine.c | 394 ++++++++++++++++++++++++
> drivers/dma/testclient.c | 132 ++++++++
> include/linux/dmaengine.h | 268 ++++++++++++++++
> net/core/Makefile | 3
> net/core/dev.c | 78 ++++
> net/core/user_dma.c | 422 ++++++++++++++++++++++++++
> 11 files changed, 1356 insertions(+), 1 deletion(-)
overall, there was a distinction lack of any useful
description/documentation, over and above the code itself.
Jeff
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Alan Cox @ 2005-11-23 22:54 UTC (permalink / raw)
To: Jeff Garzik
Cc: Andrew Grover, netdev, linux-kernel, john.ronciak,
christopher.leech
In-Reply-To: <4384E7F2.2030508@pobox.com>
On Mer, 2005-11-23 at 17:06 -0500, Jeff Garzik wrote:
> Sample ideas: VM page pre-zeroing. ATA PIO data xfers (async copy to
> static buffer, to dramatically shorten length of kmap+irqsave time).
> Extremely large memcpy() calls.
ATA PIO copies are 512 bytes of memory per sector and that is usually
already in cache and on cache line boundaries. You won't even be able to
measure it done by the CPU. I can't see the I/O engine sync cost being
worth it.
Might just about help large transfers I guess but you don't do
multisector which is the only case you'd get perhaps 8K an I/O.
> Additionally, current IOAT is memory->memory. I would love to be able
> to convince Intel to add transforms and checksums,
Not just transforms but also masks and maybe even merges and textures
would be rather handy 8)
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Jeff Garzik @ 2005-11-23 22:56 UTC (permalink / raw)
To: Alan Cox
Cc: Andrew Grover, netdev, linux-kernel, john.ronciak,
christopher.leech
In-Reply-To: <1132786445.13095.32.camel@localhost.localdomain>
Alan Cox wrote:
>>Additionally, current IOAT is memory->memory. I would love to be able
>>to convince Intel to add transforms and checksums,
>
>
> Not just transforms but also masks and maybe even merges and textures
> would be rather handy 8)
Ah yes: I totally forgot to mention XOR.
Software RAID would love that.
Jeff
^ permalink raw reply
* Re: [RFC: 2.6 patch] remove drivers/net/eepro100.c
From: David S. Miller @ 2005-11-23 23:01 UTC (permalink / raw)
To: rmk+lkml; +Cc: jgarzik, bunk, saw, linux-kernel, netdev
In-Reply-To: <20051123225319.GP15449@flint.arm.linux.org.uk>
From: Russell King <rmk+lkml@arm.linux.org.uk>
Date: Wed, 23 Nov 2005 22:53:19 +0000
> That means there's about 15 minutes left before I go to sleep before
> having to be up early tomorrow to go on a 2 hour journey to attend a
> meeting. What do you want me to do with those 15 minutes? Perform a
> miracle maybe?
It's perfectly fine that you are not able to test the fix. But being
so visibly angry about it, that's the part I don't get.
How about a "I'm not able to test this due to lack of access to the
necessary hardware, but I did give it a try although unsuccessful.
Perhaps someone else can lend a hand so we can resolve this for good?"
That's the "calm" response.
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Alan Cox @ 2005-11-23 23:02 UTC (permalink / raw)
To: Andrew Grover; +Cc: netdev, linux-kernel, john.ronciak, christopher.leech
In-Reply-To: <Pine.LNX.4.44.0511231143380.32487-100000@isotope.jf.intel.com>
On Mer, 2005-11-23 at 12:26 -0800, Andrew Grover wrote:
> early next year. Until then, the code doesn't really *do* anything, but we
> wanted to release what we could right away, and start getting some
> feedback.
First comment partly based on Jeff Garziks comments - if you added an
"operation" to the base functions and an operation mask to the DMA
engines it becomes possible to support engines that can do other ops (eg
abusing an NCR53c8xx for both copy and clear).
Second one - you obviously tested this somehow, was that all done by
simulation or do you have a "CPU" memcpy test engine for use before the
hardware pops up ?
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Jeff Garzik @ 2005-11-23 23:02 UTC (permalink / raw)
To: Andi Kleen
Cc: Andrew Grover, netdev, linux-kernel, john.ronciak,
christopher.leech
In-Reply-To: <20051123223007.GA5921@wotan.suse.de>
Andi Kleen wrote:
> Longer term the right way to handle this would be likely to use
> POSIX AIO on sockets. With that interface it would be easier
> to keep long queues of data in flight, which would be best for
> the DMA engine.
Agreed.
For my own userland projects, I'm starting to feel the need for network
AIO, since it is more natural: the hardware operations themselves are
asynchronous.
>>In addition to helping speed up network RX, I would like to see how
>>possible it is to experiment with IOAT uses outside of networking.
>>Sample ideas: VM page pre-zeroing. ATA PIO data xfers (async copy to
>>static buffer, to dramatically shorten length of kmap+irqsave time).
>>Extremely large memcpy() calls.
>
>
> Another proposal was swiotlb.
That's an interesting thought.
> But it's not clear it's a good idea: a lot of these applications prefer to
> have the target in cache. And IOAT will force it out of cache.
>
>
>>Additionally, current IOAT is memory->memory. I would love to be able
>>to convince Intel to add transforms and checksums, to enable offload of
>>memory->transform->memory and memory->checksum->result operations like
>>sha-{1,256} hashing[1], crc32*, aes crypto, and other highly common
>>operations. All of that could be made async.
>
>
> I remember the registers in the Amiga Blitter for this and I'm
> still scared... Maybe it's better to keep it simple.
We're talking about CISC here! ;-) ;-)
[note: I'm the type of person who would stuff the kernel + glibc onto an
FPGA, if I could]
I would love to see Intel, AMD, VIA (others?) compete by adding selected
transforms/checksums/hashs to their chips, though this method. Just
provide a method to enumerate what transforms are supported on <this>
chip...
Jeff
^ permalink raw reply
* Re: [2.6 patch] net/sunrpc/xdr.c: remove xdr_decode_string()
From: Neil Brown @ 2005-11-23 23:07 UTC (permalink / raw)
To: Adrian Bunk
Cc: Lever, Charles, David Miller, trond.myklebust, linux-kernel, nfs,
netdev
In-Reply-To: <20051123162528.GL3963@stusta.de>
On Wednesday November 23, bunk@stusta.de wrote:
> On Wed, Nov 23, 2005 at 04:31:14AM -0800, Lever, Charles wrote:
> > so i don't remember why you are removing xdr_decode_string. are we sure
> > that no-one will need this functionality in the future? it is harmless
> > to remove today, but i wonder if someone is just going to add it back
> > sometime.
>
> It's unused and you said:
> the only harmless change i see below is removing xdr_decode_string().
>
As 'xdr_decode_string' (sometimes) modifies the buffer that it is
decoding, I don't think it's usage should be encouraged. If it is no
longer in use, then I fully support and encourage removing it.
NeilBrown
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Jeff Garzik @ 2005-11-23 23:36 UTC (permalink / raw)
To: Alan Cox
Cc: Andi Kleen, Andrew Grover, netdev, linux-kernel, john.ronciak,
christopher.leech
In-Reply-To: <1132790740.13095.53.camel@localhost.localdomain>
Alan Cox wrote:
> Might also be interesting to use one half of a hypedthread CPU as a
> copier using the streaming instructions, might be better than turning it
> off to improve performance ?
That's pretty interesting too...
Jeff
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Alan Cox @ 2005-11-24 0:05 UTC (permalink / raw)
To: Andi Kleen
Cc: Jeff Garzik, Andrew Grover, netdev, linux-kernel, john.ronciak,
christopher.leech
In-Reply-To: <20051123223007.GA5921@wotan.suse.de>
On Mer, 2005-11-23 at 23:30 +0100, Andi Kleen wrote:
> Another proposal was swiotlb.
I was hoping Intel might have rediscovered the IOMMU by then and be back
on feature parity with the VAX 11/750
>
> But it's not clear it's a good idea: a lot of these applications prefer to
> have the target in cache. And IOAT will force it out of cache.
This is true for some cases but not all for iotlb
CPU generated data going out that won't be rewritten immediately should
be a cheap path not needing the cache. Incoming data would invalidate
the cache anyway if it arrives by DMA so the ioat would move it
asynchronously of the CPU without cache harm
Might also be interesting to use one half of a hypedthread CPU as a
copier using the streaming instructions, might be better than turning it
off to improve performance ?
Alan
^ permalink raw reply
* Re: [RFC] [PATCH 1/3] ioat: DMA subsystem
From: Greg KH @ 2005-11-24 0:07 UTC (permalink / raw)
To: Andrew Grover; +Cc: netdev, linux-kernel, john.ronciak, christopher.leech
In-Reply-To: <Pine.LNX.4.44.0511231207410.32487-100000@isotope.jf.intel.com>
On Wed, Nov 23, 2005 at 12:26:42PM -0800, Andrew Grover wrote:
> +static void
> +dma_class_release(struct class_device *cd)
> +{
> + /* do something */
> +}
Well, then actually do something here. Don't try to trick the kernel to
not complain about the lack of a release function by giving it an empty
function. This is wrong.
> +static struct class dma_devclass = {
> + .name = "dma",
> + .release = dma_class_release,
> + .class_dev_attrs = dma_class_attrs,
> +};
Why not just use class_device_create() and friends, instead of building
your own class this way? It will take care of your "look at the lack of
my release function" issues, and make things easier to handle.
> +EXPORT_SYMBOL(dma_async_client_register);
> +EXPORT_SYMBOL(dma_async_client_unregister);
> +EXPORT_SYMBOL(dma_async_client_chan_request);
> +EXPORT_SYMBOL(dma_async_memcpy_buf_to_buf);
> +EXPORT_SYMBOL(dma_async_memcpy_buf_to_pg);
> +EXPORT_SYMBOL(dma_async_memcpy_pg_to_pg);
> +EXPORT_SYMBOL(dma_async_memcpy_complete);
> +EXPORT_SYMBOL(dma_async_memcpy_issue_pending);
> +EXPORT_SYMBOL(dma_async_device_register);
> +EXPORT_SYMBOL(dma_async_device_unregister);
> +EXPORT_SYMBOL(dma_async_wait_for_completion);
> +EXPORT_PER_CPU_SYMBOL(kick_dma_poll);
EXPORT_SYMBOL_GPL() perhaps?
> +/**
> + * enum dma_event_t - resource PNP/power managment events
> + * @DMA_RESOURCE_SUSPEND: DMA device going into low power state
> + * @DMA_RESOURCE_RESUME: DMA device returning to full power
> + * @DMA_RESOURCE_ADDED: DMA device added to the system
> + * @DMA_RESOURCE_REMOVED: DMA device removed from the system
> + */
> +enum dma_event_t {
> + DMA_RESOURCE_SUSPEND,
> + DMA_RESOURCE_RESUME,
> + DMA_RESOURCE_ADDED,
> + DMA_RESOURCE_REMOVED,
> +};
Why "_t" for an enum?
> +/**
> + * struct dma_device - info on the entity supplying DMA services
> + * @chancnt: how many DMA channels are supported
> + * @channels: the list of struct dma_chan
> + * @global_node: list_head for global dma_device_list
> + * Other func ptrs: used to make use of this device's capabilities
> + */
> +struct dma_device {
> +
> + unsigned int chancnt;
> + struct list_head channels;
> + struct list_head global_node;
> +
> + int dev_id;
> + /*struct class_device class_dev;*/
Commented out?
> + int (*device_alloc_chan_resources)(struct dma_chan *chan);
> + void (*device_free_chan_resources)(struct dma_chan *chan);
> + dma_cookie_t (*device_memcpy_buf_to_buf)(struct dma_chan *chan, void *dest,
> + void *src, size_t len);
> + dma_cookie_t (*device_memcpy_buf_to_pg)(struct dma_chan *chan, struct page *page,
> + unsigned int offset, void *kdata, size_t len);
> + dma_cookie_t (*device_memcpy_pg_to_pg)(struct dma_chan *chan, struct page *dest_pg,
> + unsigned int dest_off, struct page *src_pg, unsigned int src_off,
> + size_t len);
> + void (*device_arm_interrupt)(struct dma_chan *chan);
> + enum dma_status_t (*device_memcpy_complete)(struct dma_chan *chan, dma_cookie_t cookie, dma_cookie_t *last, dma_cookie_t *used);
> + void (*device_memcpy_issue_pending)(struct dma_chan *chan);
> +};
> +
> +/* --- public DMA engine API --- */
> +
> +struct dma_client *
> +dma_async_client_register(dma_event_callback event_callback);
> +
> +void
> +dma_async_client_unregister(struct dma_client *client);
> +
> +void
> +dma_async_client_chan_request(struct dma_client *client, unsigned int number);
Put return types on the same line as the function please.
> +dma_cookie_t
> +dma_async_memcpy_buf_to_buf(
> + struct dma_chan *chan,
> + void *dest,
> + void *src,
> + size_t len);
Ick, don't duplicate the acpi coding style here please :)
> +static inline enum dma_status_t
> +dma_async_is_complete(
> + dma_cookie_t cookie,
> + dma_cookie_t last_complete,
> + dma_cookie_t last_used) {
> +
Trailing space :(
thanks,
greg k-h
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Benjamin LaHaise @ 2005-11-24 0:17 UTC (permalink / raw)
To: Andi Kleen
Cc: Jeff Garzik, Andrew Grover, netdev, linux-kernel, john.ronciak,
christopher.leech
In-Reply-To: <20051123223007.GA5921@wotan.suse.de>
On Wed, Nov 23, 2005 at 11:30:08PM +0100, Andi Kleen wrote:
> The main problem I see is that it'll likely only pay off when you can keep
> the queue of copies long (to amortize the cost of
> talking to an external chip). At least for the standard recvmsg
> skb->user space, user space-> skb cases these queues are
> likely short in most cases. That's because most applications
> do relatively small recvmsg or sendmsgs.
Don't forget that there are benefits of not polluting the cache with the
traffic for the incoming skbs.
> Longer term the right way to handle this would be likely to use
> POSIX AIO on sockets. With that interface it would be easier
> to keep long queues of data in flight, which would be best for
> the DMA engine.
Yes, that's something I'd like to try soon.
> But it's not clear it's a good idea: a lot of these applications prefer to
> have the target in cache. And IOAT will force it out of cache.
In the I/O AT case it might make sense to do a few prefetch()es of the
userland data on the return-to-userspace code path. Similarly, we should
make sure that network drivers prefetch the header at the earliest possible
time, too.
> I remember the registers in the Amiga Blitter for this and I'm
> still scared... Maybe it's better to keep it simple.
*grin* but you could use it for such cool tasks as MFM en/decoding! =-)
-ben
--
"Time is what keeps everything from happening all at once." -- John Wheeler
Don't Email: <dont@kvack.org>.
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: David S. Miller @ 2005-11-24 0:50 UTC (permalink / raw)
To: bcrl
Cc: ak, jgarzik, andrew.grover, netdev, linux-kernel, john.ronciak,
christopher.leech
In-Reply-To: <20051124001700.GC14246@kvack.org>
From: Benjamin LaHaise <bcrl@kvack.org>
Date: Wed, 23 Nov 2005 19:17:01 -0500
> Similarly, we should make sure that network drivers prefetch the
> header at the earliest possible time, too.
Several do already, thankfully :) At last check skge, tg3, chelsio,
and ixgb do the necessary prefetching on receive.
^ permalink raw reply
* Mouse issues in -mm
From: Frank Sorenson @ 2005-11-24 2:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: Marc Koschewski, linux-kernel, Harald Welte, netdev
In-Reply-To: <20051123113854.07fca702.akpm@osdl.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andrew Morton wrote:
> Marc Koschewski <marc@osknowledge.org> wrote:
>>Just booted into 2.6.15-rc2-mm1. The 'mouse problem' (as reported earlier) still
>>persists,
>
> You'l probably need to re-report the mouse problem if the previous report
> didn't get any action.
I'm not certain whether this is the same 'mouse problem', but I'll
report the mouse problems I've been seeing. In the past several -mm
kernels, my touchpad has initially worked at boot, but 'tapping' has
stopped working at some point later (with no obvious kernel messages).
I've experienced this problem at least with 2.6.15-rc1-mm2 and
2.6.15-rc2-mm1, and reverting
input-attempt-to-re-synchronize-mouse-every-5-seconds.patch gives a
kernel without the touchpad problems.
Thanks,
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
frank@tuxrocks.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFDhSAuaI0dwg4A47wRAvzYAJ94ifBDBTm7MfVsbTOZE8QG3NjZUwCggHv0
SQvehLxz6pLHs+5J+jTeaKU=
=Pkg2
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [2.6 patch] do not select NET_CLS
From: Randy.Dunlap @ 2005-11-24 2:13 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: davem, kaber, bunk, evil, linux-kernel, netdev, zippel
In-Reply-To: <20051123055735.GC7579@mars.ravnborg.org>
On Wed, 23 Nov 2005 06:57:35 +0100 Sam Ravnborg wrote:
> On Tue, Nov 22, 2005 at 03:00:41PM -0800, David S. Miller wrote:
> > From: Sam Ravnborg <sam@ravnborg.org>
> > Date: Tue, 22 Nov 2005 23:49:14 +0100
> >
> > > On Tue, Nov 22, 2005 at 02:37:13PM -0800, David S. Miller wrote:
> > > >
> > > > One thing we can do to prevent human
> > > > mistakes, is to make the "make modules" pass do a quick "is vmlinux
> > > > uptodate?" check, and if not print out an error message explaining the
> > > > situation and aborting the "make modules" attempt.
> > >
> > > I do not quite follow you here.
> >
> > If the user tries to do a "make modules" without first rebuilding
> > their kernel image, then the make will fail if the dependencies
> > are not satisfied for the main kernel image and it is thus not
> > up to date.
>
> OK - so a simple 'make -q vmlinux' check, except that the way we utilise
> make will let it fail at first build command.
> That will obscufate things even more in kbuild - but I will give it a
> try sometime. It will be easy to cover 95% but to reach 100%
> predictability will be though.
> - file dependencies is easy
> - command line changes is relatively easy
> - but the various scripts and user commands will be tricky..
>
> Not on the top of the TODO list though.
So -q means "quick" ?
I wouldn't mind seeing a -quiet (even less quiet than V=0),
not even printing the CC, AS, LD, etc. commands -- just let the
tools print errors & warnings. I always redirect output to a
disk file and filter it for errors and warnings anyway, so I
want hold my breath for this, but ISTM that V=0 could be even
quieter than it is right now.
---
~Randy
^ permalink raw reply
* Re: Mouse issues in -mm
From: Dmitry Torokhov @ 2005-11-24 3:26 UTC (permalink / raw)
To: Frank Sorenson
Cc: Andrew Morton, Marc Koschewski, linux-kernel, Harald Welte,
netdev
In-Reply-To: <4385202E.70404@tuxrocks.com>
On Wednesday 23 November 2005 21:06, Frank Sorenson wrote:
> Andrew Morton wrote:
> > Marc Koschewski <marc@osknowledge.org> wrote:
> >>Just booted into 2.6.15-rc2-mm1. The 'mouse problem' (as reported earlier) still
> >>persists,
> >
> > You'l probably need to re-report the mouse problem if the previous report
> > didn't get any action.
>
> I'm not certain whether this is the same 'mouse problem', but I'll
> report the mouse problems I've been seeing. In the past several -mm
> kernels, my touchpad has initially worked at boot, but 'tapping' has
> stopped working at some point later (with no obvious kernel messages).
>
> I've experienced this problem at least with 2.6.15-rc1-mm2 and
> 2.6.15-rc2-mm1, and reverting
> input-attempt-to-re-synchronize-mouse-every-5-seconds.patch gives a
> kernel without the touchpad problems.
>
What kind of touchpad do you have? Could you post your
/pros/bus/input/devices please?
--
Dmitry
^ permalink raw reply
* Re: [2.6 patch] do not select NET_CLS
From: Sam Ravnborg @ 2005-11-24 5:40 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: davem, kaber, bunk, evil, linux-kernel, netdev, zippel
In-Reply-To: <20051123181332.0f86bfdb.rdunlap@xenotime.net>
On Wed, Nov 23, 2005 at 06:13:32PM -0800, Randy.Dunlap wrote:
>
> So -q means "quick" ?
>From make help:
-q, --question Run no commands; exit status says if up to date
> I wouldn't mind seeing a -quiet (even less quiet than V=0),
> not even printing the CC, AS, LD, etc. commands -- just let the
> tools print errors & warnings. I always redirect output to a
> disk file and filter it for errors and warnings anyway, so I
> want hold my breath for this, but ISTM that V=0 could be even
> quieter than it is right now.
make -s shuld give you this. I've not used it for long though...
Sam
^ permalink raw reply
* Re: Mouse issues in -mm
From: Frank Sorenson @ 2005-11-24 6:14 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andrew Morton, Marc Koschewski, linux-kernel, Harald Welte,
netdev
In-Reply-To: <200511232226.44459.dtor_core@ameritech.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dmitry Torokhov wrote:
> What kind of touchpad do you have? Could you post your
> /pros/bus/input/devices please?
AlpsPS/2 ALPS GlidePoint
/proc/bus/input/devices:
I: Bus=0010 Vendor=001f Product=0001 Version=0100
N: Name="PC Speaker"
P: Phys=isa0061/input0
S: Sysfs=/class/input/input0
H: Handlers=kbd event0
B: EV=40001
B: SND=46
I: Bus=0011 Vendor=0001 Product=0001 Version=ab41
N: Name="AT Translated Set 2 keyboard"
P: Phys=isa0060/serio0/input0
S: Sysfs=/class/input/input1
H: Handlers=kbd event1
B: EV=120013
B: KEY=4 2000000 3802078 f840d001 f2ffffdf ffefffff ffffffff fffffffe
B: MSC=10
B: LED=7
I: Bus=0011 Vendor=0002 Product=0008 Version=0000
N: Name="PS/2 Mouse"
P: Phys=isa0060/serio1/input1
S: Sysfs=/class/input/input2
H: Handlers=mouse0 event2
B: EV=7
B: KEY=70000 0 0 0 0 0 0 0 0
B: REL=3
I: Bus=0011 Vendor=0002 Product=0008 Version=7321
N: Name="AlpsPS/2 ALPS GlidePoint"
P: Phys=isa0060/serio1/input0
S: Sysfs=/class/input/input3
H: Handlers=mouse1 event3
B: EV=f
B: KEY=420 0 70000 0 0 0 0 0 0 0 0
B: REL=3
B: ABS=1000003
Note: I believe this issue may also be related to the mouse protocol
extension. I typically run with 'psmouse.proto=exps' on the kernel
command line, and the psmouse resync patch seems to break tapping in
that mode. However, booting without proto=exps seems to continue to
work, even with the resync patch (though the touchpad is unusably
sensitive--hence the use of exps in the first place).
Thanks,
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
frank@tuxrocks.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFDhVpQaI0dwg4A47wRAgxMAKCgcX59rpVR2umCUz4IBNls8L+8EQCfQprd
4v8Qxv3890dRIus0ptIyGxs=
=AJGF
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Andi Kleen @ 2005-11-24 6:50 UTC (permalink / raw)
To: Benjamin LaHaise
Cc: Andi Kleen, Jeff Garzik, Andrew Grover, netdev, linux-kernel,
john.ronciak, christopher.leech
In-Reply-To: <20051124001700.GC14246@kvack.org>
On Wed, Nov 23, 2005 at 07:17:01PM -0500, Benjamin LaHaise wrote:
> On Wed, Nov 23, 2005 at 11:30:08PM +0100, Andi Kleen wrote:
> > The main problem I see is that it'll likely only pay off when you can keep
> > the queue of copies long (to amortize the cost of
> > talking to an external chip). At least for the standard recvmsg
> > skb->user space, user space-> skb cases these queues are
> > likely short in most cases. That's because most applications
> > do relatively small recvmsg or sendmsgs.
>
> Don't forget that there are benefits of not polluting the cache with the
> traffic for the incoming skbs.
Is that a general benefit outside benchmarks? I would expect
most real programs to actually do something with the data
- and that usually involves needing it in cache.
> > But it's not clear it's a good idea: a lot of these applications prefer to
> > have the target in cache. And IOAT will force it out of cache.
>
> In the I/O AT case it might make sense to do a few prefetch()es of the
> userland data on the return-to-userspace code path.
Some prefetches for user space might be a good idea yes
> Similarly, we should
> make sure that network drivers prefetch the header at the earliest possible
> time, too.
It's done kind of already but tricky to get right because
the prefetch distances upto use are not really long enough
-Andi
^ permalink raw reply
* RE: [2.6 patch] net/sunrpc/xdr.c: remove xdr_decode_string()
From: Lever, Charles @ 2005-11-24 6:56 UTC (permalink / raw)
To: Neil Brown, Adrian Bunk
Cc: David Miller, trond.myklebust, linux-kernel, nfs, netdev
> On Wednesday November 23, bunk@stusta.de wrote:
> > On Wed, Nov 23, 2005 at 04:31:14AM -0800, Lever, Charles wrote:
> > > so i don't remember why you are removing
> xdr_decode_string. are we sure
> > > that no-one will need this functionality in the future?
> it is harmless
> > > to remove today, but i wonder if someone is just going to
> add it back
> > > sometime.
> >
> > It's unused and you said:
> > the only harmless change i see below is removing
> xdr_decode_string().
> >
>
> As 'xdr_decode_string' (sometimes) modifies the buffer that it is
> decoding, I don't think it's usage should be encouraged. If it is no
> longer in use, then I fully support and encourage removing it.
actually this is a good point. since it is unused, it is an untested
path as we continue to evolve the code base.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox