* Re: [3/4] 2.6.23-rc3: known regressions
From: Michal Piotrowski @ 2007-08-13 17:59 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, LKML, Netdev, Stephen Hemminger, Thomas Meyer,
Uwe Bugla, Daniel K., Shish, Karl Meyer
In-Reply-To: <46C098FD.1030601@googlemail.com>
Hi all,
Here is a list of some known regressions in 2.6.23-rc3.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
Name Regressions fixed since 21-Jun-2007
Adrian Bunk 9
Andi Kleen 5
Linus Torvalds 5
Andrew Morton 4
Al Viro 3
Cornelia Huck 3
Jens Axboe 3
Tejun Heo 3
Networking
Subject : NETDEV WATCHDOG: eth0: transmit timed out
References : http://lkml.org/lkml/2007/8/13/737
Last known good : ?
Submitter : Karl Meyer <adhocrocker@gmail.com>
Caused-By : ?
Handled-By : ?
Status : unknown
Subject : Weird network problems with 2.6.23-rc2
References : http://lkml.org/lkml/2007/8/11/40
Last known good : ?
Submitter : Shish <shish@shishnet.org>
Caused-By : ?
Handled-By : ?
Status : unknown
Subject : BUG: when using 'brctl stp'
References : http://lkml.org/lkml/2007/8/10/441
Last known good : 2.6.23-rc1
Submitter : Daniel K. <daniel@cluded.net>
Caused-By : ?
Handled-By : ?
Status : unknown
Subject : IP v4 routing is broken
References : http://www.stardust.webpages.pl/files/tbf/bugs/bug_report01.txt
Last known good : 2.6.22-git2
Submitter : Uwe Bugla <uwe.bugla@gmx.de>
Caused-By : ?
Handled-By : ?
Status : unknown
Subject : New wake ups from sky2
References : http://lkml.org/lkml/2007/7/20/386
Last known good : ?
Submitter : Thomas Meyer <thomas@m3y3r.de>
Caused-By : Stephen Hemminger <shemminger@osdl.org>
commit eb35cf60e462491249166182e3e755d3d5d91a28
Handled-By : Stephen Hemminger <shemminger@osdl.org>
Status : unknown
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
^ permalink raw reply
* Re: [PATCH] [5/2many] MAINTAINERS - 3CR990 NETWORK DRIVER
From: Dave Dillow @ 2007-08-13 17:09 UTC (permalink / raw)
To: joe; +Cc: torvalds, netdev, linux-kernel, akpm
In-Reply-To: <46bff86d.3nPB+/nZUm72NBI6%joe@perches.com>
On Sun, 2007-08-12 at 23:21 -0700, joe@perches.com wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Dave Dillow <dave@thedillows.org>
^ permalink raw reply
* Re: [PATCH] [70/2many] MAINTAINERS - ARPD SUPPORT
From: Alan Cox @ 2007-08-13 17:51 UTC (permalink / raw)
To: Joe Perches; +Cc: torvalds, netdev, linux-kernel, akpm
In-Reply-To: <1187024659.10249.125.camel@localhost>
On Mon, 13 Aug 2007 10:04:19 -0700
Joe Perches <joe@perches.com> wrote:
> On Mon, 2007-08-13 at 17:35 +0100, Alan Cox wrote:
> > I wouldn't add a pattern for this.
>
> Back to:ARPD SUPPORT
> P: Jonathan Layes
> L: netdev@vger.kernel.org
> S: Maintained
>
> > Actually I think the entire thing is a
> > bad idea but thats another matter.
>
> Of course it's not an end-all solution,
> but what might work better?
Working off the git tree as it shows who actually is making
changes/updating stuff recently and why which is a major clue when
tracing bugs
^ permalink raw reply
* Re: RealTek 8169 support question
From: Chuck Lever @ 2007-08-13 13:52 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev ML
In-Reply-To: <20070811082450.GA23531@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 334 bytes --]
Francois Romieu wrote:
> Chuck Lever <chuck.lever@oracle.com> :
> [...]
>> Not yet. I wanted to check with "the Maintainer" to see if it was worth
>> trying. :-) The last time I tried a kernel build on one of these
>
> It is worth trying.
FYI: I tested a 2.6.23-rc2 kernel over the weekend, and the NICs worked
without issue.
[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 290 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
url:http://oss.oracle.com/~cel
version:2.1
end:vcard
^ permalink raw reply
* Disabling 64-bit DMA on atl1?
From: Chris Snook @ 2007-08-13 17:09 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Jay Cliburn, netdev, atl1-devel, Luca Tettamanti
Jeff --
Can we please get Luca's patch merged for 2.6.23? The bug is a data corrupter,
and the workaround doesn't cost us much. Both Jay and I have already acked it.
http://lkml.org/lkml/2007/6/25/293
We'll do it "the right way" once Atheros tracks it down with hardware
analyzers, but for now, let's fix the data corrupter.
-- Chris
^ permalink raw reply
* Re: [PATCH] [459/2many] MAINTAINERS - SPIDERNET NETWORK DRIVER for CELL
From: Joe Perches @ 2007-08-13 17:07 UTC (permalink / raw)
To: Linas Vepstas; +Cc: torvalds, netdev, linux-kernel, akpm
In-Reply-To: <20070813154548.GA4338@austin.ibm.com>
On Mon, 2007-08-13 at 10:45 -0500, Linas Vepstas wrote:
> Note quite right. spider-pic is not part of spider_net.
SPIDERNET NETWORK DRIVER for CELL
P: Linas Vepstas
M: linas@austin.ibm.com
L: netdev@vger.kernel.org
S: Supported
F: Documentation/networking/spider_net.txt
F: drivers/net/spider_net*
^ permalink raw reply
* Problem with semantics?
From: Shay Goikhman @ 2007-08-13 17:07 UTC (permalink / raw)
To: netdev; +Cc: davem
Dear Linux maintainers,
I'm doing :
setsockopt(s, SO_RCVTIMEO, t1 ); // set time-out
t1 on socket while block receiving on it
select(,,, &fd_set_including(s), .., &errs, t2); // block till
receive or time-out t 2 jointly on a set of sockets
Apparently, I could no find reference on the coupled behavior of the two
above statements in Linux documentation.
As I understand the blocking semantics, I would expect that if t1<t2 ,
select should return after t1 with the descriptor 's' in 'errs' if 's' does
not become readable in the t1 interval.
It is not so in life -- select ignores t1 altogether.
Do you have some enlightening knowledge on the matter?
Thanks,
-Shay
^ permalink raw reply
* Re: [PATCH] [70/2many] MAINTAINERS - ARPD SUPPORT
From: Joe Perches @ 2007-08-13 17:04 UTC (permalink / raw)
To: Alan Cox; +Cc: torvalds, netdev, linux-kernel, akpm
In-Reply-To: <20070813173522.685dab9e@the-village.bc.nu>
On Mon, 2007-08-13 at 17:35 +0100, Alan Cox wrote:
> I wouldn't add a pattern for this.
Back to:ARPD SUPPORT
P: Jonathan Layes
L: netdev@vger.kernel.org
S: Maintained
> Actually I think the entire thing is a
> bad idea but thats another matter.
Of course it's not an end-all solution,
but what might work better?
^ permalink raw reply
* Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
From: Francois Romieu @ 2007-08-13 16:58 UTC (permalink / raw)
To: Karl Meyer; +Cc: linux-kernel, netdev
In-Reply-To: <be1b757c0708130435y689b9dd8raf9ac9f9c0fcc976@mail.gmail.com>
(netdev Cced)
Karl Meyer <adhocrocker@gmail.com> :
[...]
> I am having trouble with the 2.6.23 kernel. With all versions since
> 2.6.23-rc1 I have trouble with my network connection. When using the
> network over a certain level (just browsing the web seems not to be
> enough) e.g. when installing packages over the nvsv4 share, all
> network stuff freezes for some time and syslog tells me:
> Aug 13 13:16:09 frege NETDEV WATCHDOG: eth0: transmit timed out
> Aug 13 13:16:39 frege NETDEV WATCHDOG: eth0: transmit timed out
> Aug 13 13:17:09 frege NETDEV WATCHDOG: eth0: transmit timed out
> Aug 13 13:17:57 frege NETDEV WATCHDOG: eth0: transmit timed out
Can you:
- send a complete dmesg + /proc/interrupts + .config
- use git bisect to find a suspect changeset
I do not expect any change of behavior between 2.6.22 and
25805dcf9d83098cf5492117ad2669cd14cc9b24 if it can help you narrow
things down (assuming it is a r8169 regression).
--
Ueimor
^ permalink raw reply
* Re: [PATCH] [70/2many] MAINTAINERS - ARPD SUPPORT
From: Alan Cox @ 2007-08-13 16:35 UTC (permalink / raw)
To: Joe Perches; +Cc: torvalds, netdev, linux-kernel, akpm
In-Reply-To: <1187019966.10249.75.camel@localhost>
On Mon, 13 Aug 2007 08:46:06 -0700
Joe Perches <joe@perches.com> wrote:
> On Mon, 2007-08-13 at 11:49 +0100, Alan Cox wrote:
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 90c1b81..ac2226b 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -697,6 +697,7 @@ ARPD SUPPORT
> > > P: Jonathan Layes
> > > L: netdev@vger.kernel.org
> > > S: Maintained
> > > +F: net/ipv4/arp.c
> >
> > NAK
> >
> > arp.c is the netdev people, ARPD is a corner case bit of code within it,
> > something your patterns don't actually cope with
>
> Suggestions?
I wouldn't add a pattern for this. Actually I think the entire thing is a
bad idea but thats another matter.
^ permalink raw reply
* Re: possible BUG while using CUPS
From: Udo van den Heuvel @ 2007-08-13 15:46 UTC (permalink / raw)
To: Michal Piotrowski; +Cc: linux-kernel, Netdev
In-Reply-To: <6bffcb0e0708130839v27b4269dqfde702c410b33fd0@mail.gmail.com>
Michal Piotrowski wrote:
> On 11/08/07, Udo van den Heuvel <udovdh@xs4all.nl> wrote:
>> Using Cups 1.2.12 on Linux 2.6.22.1.
(...)
>> I clikc that link and hear the ping-ping of the BUG:
>
> This is very interesting. Can you reproduce this bug?
I think so. (at least: I have seen it before: clicking around in Cups
and this crash/bug/whatever.)
>> This is on a VIA Epia EK8000. ksymoops did not really help me, this is
>> all output I got.
>>
>> Ideas?
>
> BTW. Please try 2.6.22.2.
Compiling...
^ permalink raw reply
* Re: [PATCH] [70/2many] MAINTAINERS - ARPD SUPPORT
From: Joe Perches @ 2007-08-13 15:46 UTC (permalink / raw)
To: Alan Cox; +Cc: torvalds, netdev, linux-kernel, akpm
In-Reply-To: <20070813114942.04a5483c@the-village.bc.nu>
On Mon, 2007-08-13 at 11:49 +0100, Alan Cox wrote:
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 90c1b81..ac2226b 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -697,6 +697,7 @@ ARPD SUPPORT
> > P: Jonathan Layes
> > L: netdev@vger.kernel.org
> > S: Maintained
> > +F: net/ipv4/arp.c
>
> NAK
>
> arp.c is the netdev people, ARPD is a corner case bit of code within it,
> something your patterns don't actually cope with
Suggestions?
^ permalink raw reply
* Re: [PATCH] [459/2many] MAINTAINERS - SPIDERNET NETWORK DRIVER for CELL
From: Linas Vepstas @ 2007-08-13 15:45 UTC (permalink / raw)
To: joe; +Cc: torvalds, netdev, linux-kernel, akpm
In-Reply-To: <46bffbfa.6q67BtSh8n+UV4q4%joe@perches.com>
On Sun, Aug 12, 2007 at 11:36:42PM -0700, joe@perches.com wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <joe@perches.com>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b616562..fa8fb1c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4377,6 +4377,9 @@ P: Linas Vepstas
> M: linas@austin.ibm.com
> L: netdev@vger.kernel.org
> S: Supported
> +F: Documentation/networking/spider_net.txt
> +F: arch/powerpc/platforms/cell/spider-pic.c
> +F: drivers/net/spider_net*
Note quite right. spider-pic is not part of spider_net.
The rest loks fine.
--linas
^ permalink raw reply
* Re: possible BUG while using CUPS
From: Michal Piotrowski @ 2007-08-13 15:39 UTC (permalink / raw)
To: Udo van den Heuvel; +Cc: linux-kernel, Netdev
In-Reply-To: <46BD762F.4060801@xs4all.nl>
Hi Udo,
On 11/08/07, Udo van den Heuvel <udovdh@xs4all.nl> wrote:
> Using Cups 1.2.12 on Linux 2.6.22.1.
> Managing a printer from a Win2K workstation via the http interface.
> I am at: http://box:631/printers
> I click Set as default.
> I see:
> 426 Upgrade Required
>
> You must access this page using the URL
> https://box:631/admin/?op=set-as-default&printer_name=HP_DESKJET_3820_USB_1.
>
> I clikc that link and hear the ping-ping of the BUG:
This is very interesting. Can you reproduce this bug?
>
> BUG: unable to handle kernel paging request at virtual address 730ca542
> printing eip:
> 730ca542
> *pde = 00000000
> Oops: 0000 [#1]
> PREEMPT
> Modules linked in: pwc nls_utf8 cifs sch_tbf ipt_recent xt_string
> xt_MARK xt_length xt_tcpmss xt_mac xt_mark w83627hf hwmon_vid eeprom sit
> tunnel4 nf_nat_h323 nf_conntrack_h323 nf_nat_ftp nf_conntrack_ftp
> ipt_tos ipt_REDIRECT nf_nat_irc nf_conntrack_irc ipt_owner ipt_ttl ipv6
> ipt_MASQUERADE iptable_nat nf_nat xt_NOTRACK iptable_raw ipt_TOS
> iptable_mangle ipt_LOG xt_TCPMSS xt_limit xt_state ipt_TARPIT ipt_REJECT
> iptable_filter binfmt_misc lp nvram loop snd_via82xx snd_ac97_codec
> ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq
> snd_pcm_oss snd_mixer_oss snd_pcm compat_ioctl32 videodev snd_timer
> snd_page_alloc snd_mpu401_uart snd_rawmidi v4l2_common snd_seq_device
> v4l1_compat parport_pc parport snd usblp i2c_viapro uhci_hcd
> CPU: 0
> EIP: 0060:[<730ca542>] Not tainted VLI
> EFLAGS: 00010292 (2.6.22.1 #2)
> EIP is at 0x730ca542
> eax: 00000000 ebx: a69845a0 ecx: 00000000 edx: 00000000
> esi: 1057e3db edi: 67c88dd0 ebp: 898c1ad5 esp: d9f97f18
> ds: 007b es: 007b fs: 0000 gs: 0033 ss: 0068
> Process cupsd (pid: 2220, ti=d9f96000 task=db549420 task.ti=d9f96000)
> Stack: b717a69a 240c98ab c2e35cdc 2f6eea16 64cf0972 c0a5a2b1 ba2d3d30
> f026206d
> 3301069b 39222156 d15922e5 eb1da2a4 656caba4 023f7970 33d43992
> cc0c5c41
> 63ed81fc 5c760bf7 fe3db5c3 7cdbd9fc ba114508 0ff827b8 b51f3690
> 9e64614f
> Call Trace:
> [<c0103aa5>] show_trace_log_lvl+0x1a/0x2f
> [<c0103b57>] show_stack_log_lvl+0x9d/0xa5
> [<c0103d2c>] show_registers+0x1cd/0x2e3
> [<c0103f40>] die+0xfe/0x200
> [<c010f899>] do_page_fault+0x432/0x505
> [<c02ff72a>] error_code+0x6a/0x70
> =======================
> Code: Bad EIP value.
> EIP: [<730ca542>] 0x730ca542 SS:ESP 0068:d9f97f18
>
>
> This is on a VIA Epia EK8000. ksymoops did not really help me, this is
> all output I got.
>
> Ideas?
BTW. Please try 2.6.22.2.
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
^ permalink raw reply
* Re: [KJ] replacing kmalloc with kzalloc in drivers/net/sb1250-mac.c
From: Robert P. J. Day @ 2007-08-13 15:24 UTC (permalink / raw)
To: Surya Prabhakar N; +Cc: netdev, Linux Kernel
In-Reply-To: <1186999123.29518.18.camel@bluegenie>
On Mon, 13 Aug 2007, Surya Prabhakar N wrote:
> Hi,
> Replacing kmalloc with kzalloc and cleaning up memset in
> drivers/net/sb1250-mac.c
>
>
> Signed-off-by: Surya Prabhakar <surya.prabhakar@wipro.com>
> ---
>
> diff --git a/drivers/net/sb1250-mac.c b/drivers/net/sb1250-mac.c
> index e7fdcf1..2dca5a7 100644
> --- a/drivers/net/sb1250-mac.c
> +++ b/drivers/net/sb1250-mac.c
> @@ -760,7 +760,7 @@ static void sbdma_initctx(sbmacdma_t *d,
>
> d->sbdma_dscrtable_unaligned =
> d->sbdma_dscrtable = (sbdmadscr_t *)
^^^^^^^^^^^^^^^
> - kmalloc((d->sbdma_maxdescr+1)*sizeof(sbdmadscr_t), GFP_KERNEL);
> + kzalloc((d->sbdma_maxdescr+1)*sizeof(sbdmadscr_t), GFP_KERNEL);
i'm fairly sure you can drop all of those superfluous casts when
calling one of those memory allocation routines.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
^ permalink raw reply
* Re: [patch 27/28] Introduce U16_MAX and U32_MAX
From: Satyam Sharma @ 2007-08-13 15:29 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev
In-Reply-To: <20070810.153819.76325424.davem@davemloft.net>
Hi David,
On Fri, 10 Aug 2007, David Miller wrote:
> From: akpm@linux-foundation.org
> Date: Fri, 10 Aug 2007 14:12:10 -0700
>
> > From: Satyam Sharma <satyam@infradead.org>
> >
> > ... in kernel.h and clean up home-grown macros elsewhere in the tree.
> >
> > Leave out the one in reiserfs_fs.h as it is in the userspace-visible part
> > of that header. Still, #undef the (equivalent) kernel version there to
> > avoid seeing "redefined, previous definition was here" gcc warnings.
> >
> > [akpm@linux-foundation.org: fix U16_MAX, U32_MAX defns]
> > Signed-off-by: Satyam Sharma <satyam@infradead.org>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>
> I won't apply this one, for two reasons:
>
> 1) The reiserfs definition is better, it is _type_ based.
> Please use (~(__u16)0) and (~(__u32)0), respectively.
Hmm, in that case ((__u16)0xffff) and ((__u32)0xffffffff) are probably
better and clearer -- as that's what u16_max and u32_max are, after all.
We do require the (~0) thing for the max int/uint/long types, but that's
because those are types where the number-of-bits is not known when writing
the macro definition -- but that's not case with u16 and u32, so the
0xff... variants are clearer, IMHO.
> 2) The reiserfs definition is going to define an equivalent
> value, so just adding an #undef and still letting reiserfs
> override is wrong. Why put a common define in kernel.h
> if other headers still keep their own crufty copy too?
Because removing the (re-)definition of U32_MAX from in there in
reiserfs_fs.h will break builds of all userspace users of U32_MAX and
max_reiserfs_offset(), would it not? I haven't looked at any reiserfs
userspace tools source code, so possibly none such (that use
max_reiserfs_offset) exist, but I thought it better to be safe.
I'll have a look at the reiserfs-utils package, just in case.
Thanks,
Satyam
^ permalink raw reply
* Re: [PATCH] [3/2many] MAINTAINERS - 3C359 NETWORK DRIVER
From: Arjan van de Ven @ 2007-08-13 14:01 UTC (permalink / raw)
To: joe; +Cc: torvalds, netdev, mikep, linux-tr, linux-kernel, akpm
In-Reply-To: <46bff703.S76S51omMOUeUM3N%joe@perches.com>
Hi,
please in the future send just one patch for this; there's no real
reason to split this up this finegrained...
^ permalink raw reply
* What does -EIOCBQUEUED do?
From: Tetsuo Handa @ 2007-08-13 13:27 UTC (permalink / raw)
To: netdev, linux-fsdevel
Hello.
There are several locations that handle
-EIOCBQUEUED error code.
According to include/linux/errno.h ,
it seems this code is NFS related and
caller will receive completion event later.
But I couldn't figure out where is the beginning point
and what is happening.
What functions are called before aio_complete() is called?
(For example, is udp_recvmsg() called if sock_recvmsg() for
UDP socket returned -EIOCBQUEUED?)
What memory regions are accessed before aio_complete() is called?
(For example, is "struct msghdr"->msg_name accessed
if sock_recvmsg() for UDP socket returned -EIOCBQUEUED?)
Regards.
^ permalink raw reply
* Re: drivers/net/tokenring/3c359.c
From: Alan Cox @ 2007-08-13 13:59 UTC (permalink / raw)
To: surya.prabhakar; +Cc: mikep, netdev, linux-tr, Linux Kernel, kernel-janitors
In-Reply-To: <1187000010.29518.27.camel@bluegenie>
On Mon, 13 Aug 2007 15:43:30 +0530
Surya Prabhakar N <surya.prabhakar@wipro.com> wrote:
> Hi,
> Replacing kmalloc with kzalloc and cleaning up memset in
> drivers/net/tokenring/3c359.c
>
>
> Signed-off-by: Surya Prabhakar <surya.prabhakar@wipro.com>
Acked-by: Alan Cox <alan@redhat.com>
^ permalink raw reply
* Re: [PATCH for 2.6.24] SCTP: Rewrite of sctp buffer management code
From: Neil Horman @ 2007-08-13 13:49 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: davem, netdev, lksctp-developers
In-Reply-To: <11870114401993-git-send-email-vladislav.yasevich@hp.com>
On Mon, Aug 13, 2007 at 09:24:00AM -0400, Vlad Yasevich wrote:
> Dave, Neil
>
> Sorry about that. Not sure what happened to that patch. Here is
> the good patch with witespace cleanups.
>
> -vlad
>
Thank you Vlad, that looks much better. Not sure what happened either
Regards
Neil
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*nhorman@tuxdriver.com
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
^ permalink raw reply
* Re: [PATCH for 2.6.24] SCTP: Rewrite of sctp buffer management code
From: Vlad Yasevich @ 2007-08-13 13:24 UTC (permalink / raw)
To: davem; +Cc: netdev, lksctp-developers, nhorman, Vlad Yasevich
In-Reply-To: <20070811003529.GA19807@hmsreliant.think-freely.org>
Dave, Neil
Sorry about that. Not sure what happened to that patch. Here is
the good patch with witespace cleanups.
-vlad
--
SCTP: Rewrite of sctp buffer management code
This patch introduces autotuning to the sctp buffer management code
similar to the TCP. The buffer space can be grown if the advertised
receive window still has room. This might happen if small message
sizes are used, which is common in telecom environmens.
New tunables are introduced that provide limits to buffer growth
and memory pressure is entered if to much buffer spaces is used.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
include/net/sctp/sctp.h | 5 +++
net/sctp/endpointola.c | 1
net/sctp/protocol.c | 32 +++++++++++++++++++++
net/sctp/sm_statefuns.c | 73 +++++++++++-------------------------------------
net/sctp/socket.c | 67 ++++++++++++++++++++++++++++++++++++--------
net/sctp/sysctl.c | 33 +++++++++++++++++++++
net/sctp/ulpevent.c | 18 +++++++++++
net/sctp/ulpqueue.c | 1
8 files changed, 163 insertions(+), 67 deletions(-)
---
include/net/sctp/sctp.h | 5 +++
net/sctp/endpointola.c | 1 +
net/sctp/protocol.c | 32 ++++++++++++++++++++
net/sctp/sm_statefuns.c | 74 +++++++++++-----------------------------------
net/sctp/socket.c | 69 ++++++++++++++++++++++++++++++++++++-------
net/sctp/sysctl.c | 33 +++++++++++++++++++++
net/sctp/ulpevent.c | 18 +++++++++++
net/sctp/ulpqueue.c | 1 +
8 files changed, 165 insertions(+), 68 deletions(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index d529045..46d7d09 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -468,6 +468,11 @@ static inline void sctp_skb_set_owner_r(struct sk_buff *skb, struct sock *sk)
skb->sk = sk;
skb->destructor = sctp_sock_rfree;
atomic_add(event->rmem_len, &sk->sk_rmem_alloc);
+ /*
+ * This mimics the behavior of
+ * sk_stream_set_owner_r
+ */
+ sk->sk_forward_alloc -= event->rmem_len;
}
/* Tests if the list has one and only one entry. */
diff --git a/net/sctp/endpointola.c b/net/sctp/endpointola.c
index 1404a9e..aba9258 100644
--- a/net/sctp/endpointola.c
+++ b/net/sctp/endpointola.c
@@ -103,6 +103,7 @@ static struct sctp_endpoint *sctp_endpoint_init(struct sctp_endpoint *ep,
/* Use SCTP specific send buffer space queues. */
ep->sndbuf_policy = sctp_sndbuf_policy;
+
sk->sk_write_space = sctp_write_space;
sock_set_flag(sk, SOCK_USE_WRITE_QUEUE);
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index e98579b..a746ebf 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -51,6 +51,7 @@
#include <linux/netdevice.h>
#include <linux/inetdevice.h>
#include <linux/seq_file.h>
+#include <linux/bootmem.h>
#include <net/protocol.h>
#include <net/ip.h>
#include <net/ipv6.h>
@@ -82,6 +83,10 @@ static struct sctp_af *sctp_af_v6_specific;
struct kmem_cache *sctp_chunk_cachep __read_mostly;
struct kmem_cache *sctp_bucket_cachep __read_mostly;
+extern int sysctl_sctp_mem[3];
+extern int sysctl_sctp_rmem[3];
+extern int sysctl_sctp_wmem[3];
+
/* Return the address of the control sock. */
struct sock *sctp_get_ctl_sock(void)
{
@@ -969,6 +974,8 @@ SCTP_STATIC __init int sctp_init(void)
int i;
int status = -EINVAL;
unsigned long goal;
+ unsigned long limit;
+ int max_share;
int order;
/* SCTP_DEBUG sanity check. */
@@ -1059,6 +1066,31 @@ SCTP_STATIC __init int sctp_init(void)
/* Initialize handle used for association ids. */
idr_init(&sctp_assocs_id);
+ /* Set the pressure threshold to be a fraction of global memory that
+ * is up to 1/2 at 256 MB, decreasing toward zero with the amount of
+ * memory, with a floor of 128 pages.
+ * Note this initalizes the data in sctpv6_prot too
+ * Unabashedly stolen from tcp_init
+ */
+ limit = min(num_physpages, 1UL<<(28-PAGE_SHIFT)) >> (20-PAGE_SHIFT);
+ limit = (limit * (num_physpages >> (20-PAGE_SHIFT))) >> (PAGE_SHIFT-11);
+ limit = max(limit, 128UL);
+ sysctl_sctp_mem[0] = limit / 4 * 3;
+ sysctl_sctp_mem[1] = limit;
+ sysctl_sctp_mem[2] = sysctl_sctp_mem[0] * 2;
+
+ /* Set per-socket limits to no more than 1/128 the pressure threshold*/
+ limit = (sysctl_sctp_mem[1]) << (PAGE_SHIFT - 7);
+ max_share = min(4UL*1024*1024, limit);
+
+ sysctl_sctp_rmem[0] = PAGE_SIZE; /* give each asoc 1 page min */
+ sysctl_sctp_rmem[1] = (1500 *(sizeof(struct sk_buff) + 1));
+ sysctl_sctp_rmem[2] = max(sysctl_sctp_rmem[1], max_share);
+
+ sysctl_sctp_wmem[0] = SK_STREAM_MEM_QUANTUM;
+ sysctl_sctp_wmem[1] = 16*1024;
+ sysctl_sctp_wmem[2] = max(64*1024, max_share);
+
/* Size and allocate the association hash table.
* The methodology is similar to that of the tcp hash tables.
*/
diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index 71cad56..8032789 100644
--- a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -5262,10 +5262,8 @@ static int sctp_eat_data(const struct sctp_association *asoc,
sctp_verb_t deliver;
int tmp;
__u32 tsn;
- int account_value;
struct sctp_tsnmap *map = (struct sctp_tsnmap *)&asoc->peer.tsn_map;
struct sock *sk = asoc->base.sk;
- int rcvbuf_over = 0;
data_hdr = chunk->subh.data_hdr = (sctp_datahdr_t *)chunk->skb->data;
skb_pull(chunk->skb, sizeof(sctp_datahdr_t));
@@ -5275,48 +5273,6 @@ static int sctp_eat_data(const struct sctp_association *asoc,
/* ASSERT: Now skb->data is really the user data. */
- /*
- * If we are established, and we have used up our receive buffer
- * memory, think about droping the frame.
- * Note that we have an opportunity to improve performance here.
- * If we accept one chunk from an skbuff, we have to keep all the
- * memory of that skbuff around until the chunk is read into user
- * space. Therefore, once we accept 1 chunk we may as well accept all
- * remaining chunks in the skbuff. The data_accepted flag helps us do
- * that.
- */
- if ((asoc->state == SCTP_STATE_ESTABLISHED) && (!chunk->data_accepted)) {
- /*
- * If the receive buffer policy is 1, then each
- * association can allocate up to sk_rcvbuf bytes
- * otherwise, all the associations in aggregate
- * may allocate up to sk_rcvbuf bytes
- */
- if (asoc->ep->rcvbuf_policy)
- account_value = atomic_read(&asoc->rmem_alloc);
- else
- account_value = atomic_read(&sk->sk_rmem_alloc);
- if (account_value > sk->sk_rcvbuf) {
- /*
- * We need to make forward progress, even when we are
- * under memory pressure, so we always allow the
- * next tsn after the ctsn ack point to be accepted.
- * This lets us avoid deadlocks in which we have to
- * drop frames that would otherwise let us drain the
- * receive queue.
- */
- if ((sctp_tsnmap_get_ctsn(map) + 1) != tsn)
- return SCTP_IERROR_IGNORE_TSN;
-
- /*
- * We're going to accept the frame but we should renege
- * to make space for it. This will send us down that
- * path later in this function.
- */
- rcvbuf_over = 1;
- }
- }
-
/* Process ECN based congestion.
*
* Since the chunk structure is reused for all chunks within
@@ -5376,18 +5332,9 @@ static int sctp_eat_data(const struct sctp_association *asoc,
* seems a bit troublesome in that frag_point varies based on
* PMTU. In cases, such as loopback, this might be a rather
* large spill over.
- * NOTE: If we have a full receive buffer here, we only renege if
- * our receiver can still make progress without the tsn being
- * received. We do this because in the event that the associations
- * receive queue is empty we are filling a leading gap, and since
- * reneging moves the gap to the end of the tsn stream, we are likely
- * to stall again very shortly. Avoiding the renege when we fill a
- * leading gap is a good heuristic for avoiding such steady state
- * stalls.
- */
- if (!asoc->rwnd || asoc->rwnd_over ||
- (datalen > asoc->rwnd + asoc->frag_point) ||
- (rcvbuf_over && (!skb_queue_len(&sk->sk_receive_queue)))) {
+ */
+ if ((!chunk->data_accepted) && (!asoc->rwnd || asoc->rwnd_over ||
+ (datalen > asoc->rwnd + asoc->frag_point))) {
/* If this is the next TSN, consider reneging to make
* room. Note: Playing nice with a confused sender. A
@@ -5408,6 +5355,21 @@ static int sctp_eat_data(const struct sctp_association *asoc,
}
/*
+ * Also try to renege to limit our memory usage in the event that
+ * we are under memory pressure
+ * If we can't renege, don't worry about it, the sk_stream_rmem_schedule
+ * in sctp_ulpevent_make_rcvmsg will drop the frame if we grow our
+ * memory usage too much
+ */
+ if (*sk->sk_prot_creator->memory_pressure) {
+ if (sctp_tsnmap_has_gap(map) &&
+ (sctp_tsnmap_get_ctsn(map) + 1) == tsn) {
+ SCTP_DEBUG_PRINTK("Under Pressure! Reneging for tsn:%u\n", tsn);
+ deliver = SCTP_CMD_RENEGE;
+ }
+ }
+
+ /*
* Section 3.3.10.9 No User Data (9)
*
* Cause of error
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 01c6364..80de574 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -107,23 +107,42 @@ static void sctp_sock_migrate(struct sock *, struct sock *,
struct sctp_association *, sctp_socket_type_t);
static char *sctp_hmac_alg = SCTP_COOKIE_HMAC_ALG;
+extern struct kmem_cache *sctp_bucket_cachep;
+extern int sysctl_sctp_mem[3];
+extern int sysctl_sctp_rmem[3];
+extern int sysctl_sctp_wmem[3];
+
+int sctp_memory_pressure;
+atomic_t sctp_memory_allocated;
+atomic_t sctp_sockets_allocated;
+
+static void sctp_enter_memory_pressure(void)
+{
+ sctp_memory_pressure = 1;
+}
+
+
/* Get the sndbuf space available at the time on the association. */
static inline int sctp_wspace(struct sctp_association *asoc)
{
- struct sock *sk = asoc->base.sk;
- int amt = 0;
+ int amt;
- if (asoc->ep->sndbuf_policy) {
- /* make sure that no association uses more than sk_sndbuf */
- amt = sk->sk_sndbuf - asoc->sndbuf_used;
+ if (asoc->ep->sndbuf_policy)
+ amt = asoc->sndbuf_used;
+ else
+ amt = atomic_read(&asoc->base.sk->sk_wmem_alloc);
+
+ if (amt >= asoc->base.sk->sk_sndbuf) {
+ if (asoc->base.sk->sk_userlocks & SOCK_SNDBUF_LOCK)
+ amt = 0;
+ else {
+ amt = sk_stream_wspace(asoc->base.sk);
+ if (amt < 0)
+ amt = 0;
+ }
} else {
- /* do socket level accounting */
- amt = sk->sk_sndbuf - atomic_read(&sk->sk_wmem_alloc);
+ amt = asoc->base.sk->sk_sndbuf - amt;
}
-
- if (amt < 0)
- amt = 0;
-
return amt;
}
@@ -155,6 +174,7 @@ static inline void sctp_set_owner_w(struct sctp_chunk *chunk)
sizeof(struct sctp_chunk);
atomic_add(sizeof(struct sctp_chunk), &sk->sk_wmem_alloc);
+ sk_charge_skb(sk, chunk->skb);
}
/* Verify that this is a valid address. */
@@ -3314,6 +3334,7 @@ SCTP_STATIC int sctp_init_sock(struct sock *sk)
sp->hmac = NULL;
SCTP_DBG_OBJCNT_INC(sock);
+ atomic_inc(&sctp_sockets_allocated);
return 0;
}
@@ -3327,7 +3348,7 @@ SCTP_STATIC int sctp_destroy_sock(struct sock *sk)
/* Release our hold on the endpoint. */
ep = sctp_sk(sk)->ep;
sctp_endpoint_free(ep);
-
+ atomic_dec(&sctp_sockets_allocated);
return 0;
}
@@ -5747,6 +5768,12 @@ static void sctp_wfree(struct sk_buff *skb)
atomic_sub(sizeof(struct sctp_chunk), &sk->sk_wmem_alloc);
+ /*
+ * This undoes what is done via sk_charge_skb
+ */
+ sk->sk_wmem_queued -= skb->truesize;
+ sk->sk_forward_alloc += skb->truesize;
+
sock_wfree(skb);
__sctp_write_space(asoc);
@@ -5764,6 +5791,11 @@ void sctp_sock_rfree(struct sk_buff *skb)
struct sctp_ulpevent *event = sctp_skb2event(skb);
atomic_sub(event->rmem_len, &sk->sk_rmem_alloc);
+
+ /*
+ * Mimic the behavior of sk_stream_rfree
+ */
+ sk->sk_forward_alloc += event->rmem_len;
}
@@ -6153,6 +6185,7 @@ static void sctp_sock_migrate(struct sock *oldsk, struct sock *newsk,
sctp_release_sock(newsk);
}
+
/* This proto struct describes the ULP interface for SCTP. */
struct proto sctp_prot = {
.name = "SCTP",
@@ -6175,6 +6208,12 @@ struct proto sctp_prot = {
.unhash = sctp_unhash,
.get_port = sctp_get_port,
.obj_size = sizeof(struct sctp_sock),
+ .sysctl_mem = sysctl_sctp_mem,
+ .sysctl_rmem = sysctl_sctp_rmem,
+ .sysctl_wmem = sysctl_sctp_wmem,
+ .memory_pressure = &sctp_memory_pressure,
+ .enter_memory_pressure = sctp_enter_memory_pressure,
+ .memory_allocated = &sctp_memory_allocated,
};
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
@@ -6199,5 +6238,11 @@ struct proto sctpv6_prot = {
.unhash = sctp_unhash,
.get_port = sctp_get_port,
.obj_size = sizeof(struct sctp6_sock),
+ .sysctl_mem = sysctl_sctp_mem,
+ .sysctl_rmem = sysctl_sctp_rmem,
+ .sysctl_wmem = sysctl_sctp_wmem,
+ .memory_pressure = &sctp_memory_pressure,
+ .enter_memory_pressure = sctp_enter_memory_pressure,
+ .memory_allocated = &sctp_memory_allocated,
};
#endif /* defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) */
diff --git a/net/sctp/sysctl.c b/net/sctp/sysctl.c
index e2c679b..ba75ef4 100644
--- a/net/sctp/sysctl.c
+++ b/net/sctp/sysctl.c
@@ -52,6 +52,15 @@ static int int_max = INT_MAX;
static long sack_timer_min = 1;
static long sack_timer_max = 500;
+int sysctl_sctp_mem[3];
+int sysctl_sctp_rmem[3];
+int sysctl_sctp_wmem[3];
+
+/*
+ * per assoc memory limitationf for sends
+ */
+int sysctl_sctp_wmem[3];
+
static ctl_table sctp_table[] = {
{
.ctl_name = NET_SCTP_RTO_INITIAL,
@@ -226,6 +235,30 @@ static ctl_table sctp_table[] = {
.extra1 = &sack_timer_min,
.extra2 = &sack_timer_max,
},
+ {
+ .ctl_name = CTL_UNNUMBERED,
+ .procname = "sctp_mem",
+ .data = &sysctl_sctp_mem,
+ .maxlen = sizeof(sysctl_sctp_mem),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec,
+ },
+ {
+ .ctl_name = CTL_UNNUMBERED,
+ .procname = "sctp_rmem",
+ .data = &sysctl_sctp_rmem,
+ .maxlen = sizeof(sysctl_sctp_rmem),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec,
+ },
+ {
+ .ctl_name = CTL_UNNUMBERED,
+ .procname = "sctp_wmem",
+ .data = &sysctl_sctp_wmem,
+ .maxlen = sizeof(sysctl_sctp_wmem),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec,
+ },
{ .ctl_name = 0 }
};
diff --git a/net/sctp/ulpevent.c b/net/sctp/ulpevent.c
index bfecb35..5dc094b 100644
--- a/net/sctp/ulpevent.c
+++ b/net/sctp/ulpevent.c
@@ -685,6 +685,24 @@ struct sctp_ulpevent *sctp_ulpevent_make_rcvmsg(struct sctp_association *asoc,
struct sctp_ulpevent *event = NULL;
struct sk_buff *skb;
size_t padding, len;
+ int rx_count;
+
+ /*
+ * check to see if we need to make space for this
+ * new skb, expand the rcvbuffer if needed, or drop
+ * the frame
+ */
+ if (asoc->ep->rcvbuf_policy)
+ rx_count = atomic_read(&asoc->rmem_alloc);
+ else
+ rx_count = atomic_read(&asoc->base.sk->sk_rmem_alloc);
+
+ if (rx_count >= asoc->base.sk->sk_rcvbuf) {
+
+ if ((asoc->base.sk->sk_userlocks & SOCK_RCVBUF_LOCK) ||
+ (!sk_stream_rmem_schedule(asoc->base.sk, chunk->skb)))
+ goto fail;
+ }
/* Clone the original skb, sharing the data. */
skb = skb_clone(chunk->skb, gfp);
diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
index 34eb977..33e49b5 100644
--- a/net/sctp/ulpqueue.c
+++ b/net/sctp/ulpqueue.c
@@ -978,6 +978,7 @@ void sctp_ulpq_renege(struct sctp_ulpq *ulpq, struct sctp_chunk *chunk,
sctp_ulpq_partial_delivery(ulpq, chunk, gfp);
}
+ sk_stream_mem_reclaim(asoc->base.sk);
return;
}
--
1.5.2.4
^ permalink raw reply related
* Re: [PATCH] [374/2many] MAINTAINERS - PCNET32 NETWORK DRIVER
From: Hans-Jürgen Koch @ 2007-08-13 13:11 UTC (permalink / raw)
To: Al Viro
Cc: Joe Perches, David Miller, torvalds, pcnet32, netdev,
linux-kernel, akpm
In-Reply-To: <20070813071806.GG21089@ftp.linux.org.uk>
Am Montag 13 August 2007 09:18 schrieb Al Viro:
> On Sun, Aug 12, 2007 at 11:46:49PM -0700, Joe Perches wrote:
> > On Sun, 2007-08-12 at 23:36 -0700, David Miller wrote:
> > > Ok, 374 patches is just rediculious.
> > >
> > > So many patches eats up an enormous amount of mailing list resources,
> > > and for these patches in particular there are few reasons to split
> > > them up at all. The fact that the split up landed you at 300+ patches
> > > is a very good indication of that.
> >
> > More than ridiculous. Completely agree.
> >
> > I tried to send 1 patch over the last couple of days.
> > Unfortunately, it's > 100KB and disappears into the void.
>
> So put it on anonftp/webpage/git tree and post the URI, damnit.
> Of all ridiculous reasons for a mailbomb...
Or make it 3 or 4 or even 40 patches, but not 500.
Hans
^ permalink raw reply
* [kj] is_power_of_2 in net/core/neighbour.c
From: vignesh babu @ 2007-08-13 13:03 UTC (permalink / raw)
To: roque, kuznet, netdev; +Cc: netdev, Kernel Janitors List
Replacing n & (n - 1) for power of 2 check by is_power_of_2(n)
Signed-off-by: vignesh babu <vignesh.babu@wipro.com>
---
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index ca2a153..f7de8f2 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -33,6 +33,7 @@
#include <linux/rtnetlink.h>
#include <linux/random.h>
#include <linux/string.h>
+#include <linux/log2.h>
#define NEIGH_DEBUG 1
@@ -311,7 +312,7 @@ static void neigh_hash_grow(struct neigh_table *tbl, unsigned long new_entries)
NEIGH_CACHE_STAT_INC(tbl, hash_grows);
- BUG_ON(new_entries & (new_entries - 1));
+ BUG_ON(!is_power_of_2(new_entries));
new_hash = neigh_hash_alloc(new_entries);
if (!new_hash)
return;
--
Vignesh Babu BM
_____________________________________________________________
"Why is it that every time I'm with you, makes me believe in magic?"
^ permalink raw reply related
* Re: Block device throttling [Re: Distributed storage.]
From: Daniel Phillips @ 2007-08-13 13:04 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: Jens Axboe, netdev, linux-kernel, linux-fsdevel, Peter Zijlstra
In-Reply-To: <20070813121802.GB5992@2ka.mipt.ru>
On Monday 13 August 2007 05:18, Evgeniy Polyakov wrote:
> > Say you have a device mapper device with some physical device
> > sitting underneath, the classic use case for this throttle code.
> > Say 8,000 threads each submit an IO in parallel. The device mapper
> > mapping function will be called 8,000 times with associated
> > resource allocations, regardless of any throttling on the physical
> > device queue.
>
> Each thread will sleep in generic_make_request(), if limit is
> specified correctly, then allocated number of bios will be enough to
> have a progress.
The problem is, the sleep does not occur before the virtual device
mapping function is called. Let's consider two devices, a physical
device named pdev and a virtual device sitting on top of it called
vdev. vdev's throttle limit is just one element, but we will see that
in spite of this, two bios can be handled by the vdev's mapping method
before any IO completes, which violates the throttling rules. According
to your patch it works like this:
Thread 1 Thread 2
<no wait because vdev->bio_queued is zero>
vdev->q->bio_queued++
<enter devmapper map method>
blk_set_bdev(bio, pdev)
vdev->bio_queued--
<no wait because vdev->bio_queued is zero>
vdev->q->bio_queued++
<enter devmapper map method>
whoops! Our virtual device mapping
function has now allocated resources
for two in-flight bios in spite of having its
throttle limit set to 1.
Perhaps you never worried about the resources that the device mapper
mapping function allocates to handle each bio and so did not consider
this hole significant. These resources can be significant, as is the
case with ddsnap. It is essential to close that window through with
the virtual device's queue limit may be violated. Not doing so will
allow deadlock.
Regards,
Daniel
^ permalink raw reply
* Re: [PATCH] [504/2many] MAINTAINERS - USB PEGASUS DRIVER
From: Petko Manolov @ 2007-08-13 12:55 UTC (permalink / raw)
To: joe; +Cc: linux-usb-devel, petkan, netdev, linux-kernel, akpm, torvalds
In-Reply-To: <46bffc64.Are6NTp/45DX6lxZ%joe@perches.com>
On Sun, 12 Aug 2007, joe@perches.com wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <joe@perches.com>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d822865..fc87fa7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4764,6 +4764,7 @@ L: linux-usb-devel@lists.sourceforge.net
> L: netdev@vger.kernel.org
> W: http://pegasus2.sourceforge.net/
> S: Maintained
> +F: drivers/net/usb/pegasus.*
>
> USB PRINTER DRIVER (usblp)
> P: Pete Zaitcev
>
Well, what can i say? "NO, don't do it!" is probably not going to work so
i assume i will have to ACK. :-)
Petko
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
^ 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