* 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
* Re: 2.6.15-rc2-mm1
From: Harald Welte @ 2005-11-24 9:04 UTC (permalink / raw)
To: Andrew Morton; +Cc: Michal Piotrowski, linux-kernel, netdev
In-Reply-To: <20051123112218.73f68926.akpm@osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]
On Wed, Nov 23, 2005 at 11:22:18AM -0800, Andrew Morton wrote:
> Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> >
> > Debug: sleeping function called from invalid context at
> > include/asm/semaphore.h:123
> > in_atomic():1, irqs_disabled():0
> > [<c0103be6>] dump_stack+0x17/0x19
> > [<c011a0c3>] __might_sleep+0x9c/0xae
> > [<fd9a090d>] translate_table+0x147/0xc14 [ip_tables]
> > [<fd9a2b2a>] ipt_register_table+0x93/0x20d [ip_tables]
> > [<f98fe027>] init+0x27/0x9e [iptable_filter]
> > [<c01376d0>] sys_init_module+0xd7/0x26c
> > [<c0102cc7>] sysenter_past_esp+0x54/0x75
> > ---------------------------
> > | preempt count: 00000001 ]
> > | 1 level deep critical section nesting:
> > ----------------------------------------
> > .. [<fd9a2aca>] .... ipt_register_table+0x33/0x20d [ip_tables]
> > .....[<f98fe027>] .. ( <= init+0x27/0x9e [iptable_filter])
> >
>
> ipt_register_table() does get_cpu() then calls translate_table(), and
> somewhere under translate_table() we do something which sleeps, only I'm not
> sure what it is - netfilter likes to hide things in unexpected places.
I'll investigate this. the get_cpu() scheme was introduced as a fix for
a different (less serious) problem.
You'll get a reply until later today.
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Mouse issues in -mm
From: Marc Koschewski @ 2005-11-24 9:40 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Frank Sorenson, Andrew Morton, Marc Koschewski, linux-kernel,
Harald Welte, netdev
In-Reply-To: <200511232226.44459.dtor_core@ameritech.net>
* Dmitry Torokhov <dtor_core@ameritech.net> [2005-11-23 22:26:43 -0500]:
> 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?
Mine is like this:
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/input0
H: Handlers=kbd event0
B: EV=120013
B: KEY=4 2000000 3802078 f840d001 f2ffffdf ffefffff ffffffff fffffffe
B: MSC=10
B: LED=7
I: Bus=0010 Vendor=001f Product=0001 Version=0100
N: Name="PC Speaker"
P: Phys=isa0061/input0
S: Sysfs=/class/input/input1
H: Handlers=kbd event1
B: EV=40001
B: SND=6
I: Bus=0011 Vendor=0002 Product=0005 Version=0000
N: Name="ImPS/2 Generic Wheel Mouse"
P: Phys=isa0060/serio1/input0
S: Sysfs=/class/input/input2
H: Handlers=event2 mouse0
B: EV=7
B: KEY=70000 0 0 0 0 0 0 0 0
B: REL=103
I don't know why my touchpad is not listed. I have one and it perfectly
works with X (same pointer as the mouse which is a Microsoft USB Wheel Mouse'
attached to PS/2 using an appropriate adapter.
Marc
^ permalink raw reply
* Re: [RFC: 2.6 patch] remove drivers/net/eepro100.c
From: Catalin Marinas @ 2005-11-24 10:30 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Adrian Bunk, saw, linux-kernel, netdev, David S. Miller
In-Reply-To: <20051123222410.GN15449@flint.arm.linux.org.uk>
Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> On Wed, Nov 23, 2005 at 10:15:48PM +0000, Russell King wrote:
>> Well, I've run 2.6.15-rc2 on what I think was the ARM platform which
>> exhibited the problem, but it doesn't show up.
>
> The test was merely a "did it successfully BOOTP" because I can't
> get it to mount and run /sbin/init from the jffs2 rootfs which
> 2.5.70 was perfectly happy to earlier today. However, the
> failure point seemed to be when NFS tried to use the card.
If you you are referring to the ARM Integrator/AP platform, I tested
it earlier this year, with a 2.6.12 kernel, and the e100.c driver
seemed to be OK with an NFS-mounted root filesystem and the IP address
got via kernel DHCP. I had problems getting the eepro100.c driver to
work though, but I didn't dig any further since e100.c seemed OK.
I'll give it another try early next week with 2.6.15-rc2 and let you
know whether I see any problems.
--
Catalin
^ permalink raw reply
* Re: [RFC] [PATCH 1/3] ioat: DMA subsystem
From: Christoph Hellwig @ 2005-11-24 11:48 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>
> +++ 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)
these macros seem rather useless. if you disagree please submit a patch to
<linux/list.h> - if it gets accepted fine, else just remove this usage.
> + struct dma_chan *chan = container_of(cd, struct dma_chan, class_dev);
What about a
#define to_dma_chan(cdev) \
container_of(cd, struct dma_chan, cdev)
helper as we have in many subsystems?
> +static void
> +dma_class_release(struct class_device *cd)
> +{
> + /* do something */
> +}
umm, yeah.. :)
> +static struct dma_chan *
> +dma_client_chan_alloc(struct dma_client *client)
> +{
> + struct dma_device *device;
> + struct dma_chan *chan;
> +
> + BUG_ON(!client);
> +
> + /* Find a channel, any DMA engine will do */
> + list_for_each_entry(device, &dma_device_list, global_node) {
> + list_for_each_entry(chan, &device->channels, device_node) {
> + if (chan->client)
> + continue;
couldn't you use the normal device model list for this?
> +static void
> +dma_client_chan_free(struct dma_chan *chan)
> +{
> + BUG_ON(!chan);
> +
> + chan->device->device_free_chan_resources(chan);
you'll get the oops here anyway, no need for the BUG_ON
> + chan = list_entry(client->channels.next, struct dma_chan, client_node);
please shorten the line length to fit 80 column terminals.
> +static int __init dma_bus_init(void)
> +{
> + int cpu;
> +
> + dma_wait_wq = create_workqueue("dmapoll");
> + for_each_online_cpu(cpu) {
> + init_completion(&per_cpu(kick_dma_poll, cpu));
you either need to make this for_each_possible_cpu or add a hotplug
cpu notifier. the first is probably a lot easier :)
^ permalink raw reply
* Re: [RFC] [PATCH 1/3] ioat: DMA subsystem
From: Ingo Oeser @ 2005-11-24 15:00 UTC (permalink / raw)
To: Jeff Garzik
Cc: Andrew Grover, netdev, linux-kernel, john.ronciak,
christopher.leech
In-Reply-To: <4384F0C4.1090209@pobox.com>
Hi,
Jeff Garzik wrote:
> explanation of this function would be nice. remember to answer "how?"
> and "why?", not "what?".
Wasn't it the other way around?
Citing linux/Documentation/CodingStyle, section 7 "Comments":
"Generally, you want your comments to tell WHAT your code does, not HOW."
HOW and WHY should be obvious by the source code, unless
the sources are a mess.
Regards
Ingo Oeser
^ permalink raw reply
* Re: [RFC] [PATCH 1/3] ioat: DMA subsystem
From: Jeff Garzik @ 2005-11-24 15:04 UTC (permalink / raw)
To: Ingo Oeser
Cc: Andrew Grover, netdev, linux-kernel, john.ronciak,
christopher.leech
In-Reply-To: <200511241600.50046.netdev@axxeo.de>
On Thu, Nov 24, 2005 at 04:00:50PM +0100, Ingo Oeser wrote:
> Hi,
>
> Jeff Garzik wrote:
> > explanation of this function would be nice. remember to answer "how?"
> > and "why?", not "what?".
>
> Wasn't it the other way around?
> Citing linux/Documentation/CodingStyle, section 7 "Comments":
>
> "Generally, you want your comments to tell WHAT your code does, not HOW."
>
> HOW and WHY should be obvious by the source code, unless
> the sources are a mess.
Yes, good point, thanks for the correction.
Jeff
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Avi Kivity @ 2005-11-24 15:24 UTC (permalink / raw)
To: Andi Kleen
Cc: Benjamin LaHaise, Jeff Garzik, Andrew Grover, netdev,
linux-kernel, john.ronciak, christopher.leech
In-Reply-To: <20051124065037.GZ20775@brahms.suse.de>
Andi Kleen wrote:
>>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.
>
>
>
As an example, an NFS server reads some data pages using iSCSI and sends
them using NFS/TCP (or vice versa).
>>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
>
>
>
As long as they can be turned off. Not all usespace applications want to
touch the data immediately.
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Andi Kleen @ 2005-11-24 15:29 UTC (permalink / raw)
To: Avi Kivity
Cc: Andi Kleen, Benjamin LaHaise, Jeff Garzik, Andrew Grover, netdev,
linux-kernel, john.ronciak, christopher.leech
In-Reply-To: <4385DB32.7010605@argo.co.il>
On Thu, Nov 24, 2005 at 05:24:34PM +0200, Avi Kivity wrote:
> Andi Kleen wrote:
>
> >>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.
> >
> >
> >
> As an example, an NFS server reads some data pages using iSCSI and sends
> them using NFS/TCP (or vice versa).
For TX this can be done zero copy using a sendfile like setup.
For RX it may help - but my point was that most applications
are not structured in this simple way.
> >>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
> >
> >
> >
> As long as they can be turned off. Not all usespace applications want to
> touch the data immediately.
Perhaps. And lots of others might. Of course the simple
network benchmarks don't so the number on them look good.
Just pointing out that it's not clear it will always be a big help.
-Andi
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Avi Kivity @ 2005-11-24 15:35 UTC (permalink / raw)
To: Andi Kleen
Cc: Benjamin LaHaise, Jeff Garzik, Andrew Grover, netdev,
linux-kernel, john.ronciak, christopher.leech
In-Reply-To: <20051124152924.GB5921@wotan.suse.de>
Andi Kleen wrote:
>>>
>>>
>>As an example, an NFS server reads some data pages using iSCSI and sends
>>them using NFS/TCP (or vice versa).
>>
>>
>
>For TX this can be done zero copy using a sendfile like setup.
>
>
Yes, or with aio send for anonymous memory.
>For RX it may help - but my point was that most applications
>are not structured in this simple way.
>
>
>
Agreed. But those that do care, care very much. The data mover
applications, simply because they don't touch the data, expect very high
bandwidth.
>>As long as they can be turned off. Not all usespace applications want to
>>touch the data immediately.
>>
>>
>
>Perhaps. And lots of others might. Of course the simple
>network benchmarks don't so the number on them look good.
>
>
>
There are very real non-benchmark applications that want this.
>Just pointing out that it's not clear it will always be a big help.
>
>
>
Agree it should default to in-cache.
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Andi Kleen @ 2005-11-24 15:37 UTC (permalink / raw)
To: Avi Kivity
Cc: Andi Kleen, Benjamin LaHaise, Jeff Garzik, Andrew Grover, netdev,
linux-kernel, john.ronciak, christopher.leech
In-Reply-To: <4385DDBE.3040208@argo.co.il>
> >Just pointing out that it's not clear it will always be a big help.
> >
> >
> >
> Agree it should default to in-cache.
This would mean no DMA engine by default.
Clearly there needs to be some heuristic to decide by default. We'll see how
effective it will be in the end.
-Andi
^ 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