one in n-zillion times a
message collides and is retransmitted on the APIC bus.
skb->len is unsigned so <= 0 can be == 0. More importantly the subtraction
before the test will wrap and is completely unsafe (see at_xmit_frame)
Alan
-
To unsubscribe from this list: send the line "unsubsc
s this OK or is there any doubt whether this information is true?
As I understand it a small number of such devices were produced, but I
have no objection to it going away. Even if someone had such a card it
would not actually be useful any more.
Alan
-
To unsubscribe from this list: send the l
On Thu, 04 Jan 2007 15:39:24 +1100
ahendry <[EMAIL PROTECTED]> wrote:
> Trivial. Newlines missing on the SOCK_DEBUG's for X.25 facility negotiation.
>
> Signed-off-by: Andrew Hendry <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[EMAIL PROTECTED]>
-
To unsubscri
> + struct sk_buff *skbn;
> + skbn = skb_clone(skb, GFP_ATOMIC);
> +
If this fails then you starting passing NULL around. I'm also a bit
confused as to where you free the copy in all the error cases ?
Is there any reason for creating skbn here rather than in
skb_forward_call ?
-
To unsub
le_path since with
sendfile/sendpath hacking around there didn't seem to be much gain.
I'm even more sceptical of the header buffer stuff as while other OS's do
that as a hack to make TCP packetising work we simply fixed the root
problem with TCP_CORK
Alan
-
To unsubscribe from this list:
The timeout is a long, we return it truncated if it is huge. Basically
harmless as the only caller does a boolean check, but tidy it up anyway.
Signed-off-by: Alan Cox
---
net/llc/af_llc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/llc/af_llc.c b/net/llc/af_llc.c
The timeout is a long, we return it truncated if it is huge. Basically
harmless as the only caller does a boolean check, but tidy it up anyway.
(64bit build tested this time. Thank you 0day)
Signed-off-by: Alan Cox
---
net/llc/af_llc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions
sp_get() and sp_put(). However network layer activity via
sp_xmit() is not protected this way. We must therefore stop the queue
otherwise the user gets to dump a buffer mostly of their choice into freed
kernel pages.
Signed-off-by: Alan Cox
---
drivers/net/hamradio/6pack.c |6 ++
1 file
logic is not protected by the semaphore.
Signed-off-by: Alan Cox
---
drivers/net/hamradio/mkiss.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/hamradio/mkiss.c b/drivers/net/hamradio/mkiss.c
index 0b72b9d..85828f1 100644
--- a/drivers/net/hamradio/mkiss.c
+++ b/drivers/net
(As asked by Dave in Februrary)
Signed-off-by: Alan Cox
---
net/llc/af_llc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/llc/af_llc.c b/net/llc/af_llc.c
index 8ae3ed9..db916cf 100644
--- a/net/llc/af_llc.c
+++ b/net/llc/af_llc.c
@@ -38,7 +38,7 @@ static u16
ove them into the decoded buffer before
returning.
Signed-off-by: Alan Cox
---
drivers/net/hamradio/6pack.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/net/hamradio/6pack.c b/drivers/net/hamradio/6pack.c
index 5a1e985..470b3dc 100644
--- a/drivers/net/hamr
On Mon, 5 Nov 2007 18:05:57 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> There's no no point in keeping documentation for a driver that was
> removed many years ago.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Defintiely very dead
Acked-by: Alan
On Mon, 5 Nov 2007 18:04:45 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> The drivers have already been removed 3.5 years ago.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line
> > pata_pdc202xx_old excessive ATA bus errors
> > http://bugzilla.kernel.org/show_bug.cgi?id=9337
> > 2.6.24-rc2
>
> No response from developers
Untrue. We've been discussing it on list in the past and its now on
bugzilla. Not obvious from outside I realise. That one I'm afraid is
probably a lon
of boot options to
try. A lot of errors can be localised simply by asking the reported to
boot with things like "iommu=off", "pci=routeirq", "apci=off" etc
That takes a lot less time to run through and can be very informative.
Alan
-
To unsubscribe from this list:
You can. Perhaps that bugzilla needs to point to some kind of
[EMAIL PROTECTED] list for the various ARM platform
maintainers ?
Alan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
> Bug fixing is not about finding someone to blame, it's about getting the
> bug fixed.
Partly - its also about understanding why the bug occurred and making it
not happen again.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More
unmap path for fragmented packets is broken with any kind
of iommu
Alan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
> Then init_net needs to be not GPL limited. Sorry, we need to allow
> non GPL network drivers. There is a fine line between keeping the
Why - they aren't exactly likely to be permissible by law
> binary seething masses from accessing random kernel functions, and allowing
> reasonable (but still
> Then change the license, explicitly and get it approved, forcing license
> changes by technically subversive means is bad policy. It is like Euro
> bureaucrats
I don't need to - the licence has been the same since about 0.12
Alan
--
To unsubscribe from this list: send the lin
d loads against current
> 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again I
> don't
> give a damn, but the enterprise distro vendors certainly care.
Enterprise distro vendors ship kernels from the 2.6.19 era, so I don't
see why they care.
Alan
--
To
how magically OK, and I don't agree with Linus.
The GPL very clearly says that you can make your own unredistributed
modifications and keep them that way.
Alan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
M
can always send Linus a copy and ask but if its just finished then
far better to send it to Andrew so that it can get testing and picked at
in -mm then merged next time around when polished.
Alan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a mess
isable_irq because otherwise you will get delayed
interrupts on the APIC bus deadlocking the transmit path.
Quite hairy but the chip simply wasn't designed for SMP and you can't
even ACK an interrupt without risking corrupting other parallel
activities on the chip.
Alan
-
To
On Thu, 26 Jul 2007 14:44:01 +0200
Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Very below is my patch proposal with a comment, which in my opinion
> is precious enough to save it for future help in reading and
> understanding the code.
>
> I hope Alan will
> So the whole locking is to be able to keep irqs enabled for a long time,
> without risking entry of the same IRQ handler on this same CPU, correct?
As implemented - on any CPU.
We also need to know that the IRQ handler is not doing useful work on
another processor which is why we take the lock
gt; Since the last time this patch was posted I radically
> simplified cdrom_sysctl_helper to meet address Alan's objections.
>
> Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line &
any security association?
Thanks for any answers. I may think up more questions later...
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 15 May 2007 10:29:18 -0700
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Is select(0, ..) is a valid operation ?
Yes. It's a fairly classic old BSD way to do timeouts
Alan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
t
(as happens sometimes ;)) right
to insist on the code being clean and efficient.
Alan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 18 Jun 2007 12:43:40 +0200
Thomas Graf <[EMAIL PROTECTED]> wrote:
> * Miklos Szeredi <[EMAIL PROTECTED]> 2007-06-18 12:39
> > You are wrong. Look in unix_release_sock():
> >
> > if (atomic_read(&unix_tot_inflight))
> > unix_gc(); /* Garbage collect fds */
> >
On Sun, 12 Aug 2007 23:23:36 -0700
[EMAIL PROTECTED] wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 90c1b81..ac2226b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -697,6 +697,7 @@ ARPD SUPP
On Mon, 13 Aug 2007 15:43:30 +0530
Surya Prabhakar N <[EMAIL PROTECTED]> wrote:
> Hi,
>Replacing kmalloc with kzalloc and cleaning up memset in
> drivers/net/tokenring/3c359.c
>
>
> Signed-off-by: Surya Prabhakar <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[E
On Mon, 13 Aug 2007 08:46:06 -0700
Joe Perches <[EMAIL PROTECTED]> 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/MAINT
On Mon, 13 Aug 2007 10:04:19 -0700
Joe Perches <[EMAIL PROTECTED]> 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:Mai
On Wed, 15 Aug 2007 10:10:38 +0200
Stefan Richter <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> >> > Actually I think the entire thing is a
> >> > bad idea but thats another matter.
>
> > Working off the git tree as it shows who actually is making
&
> > to remove the BSD/other license. Jiri can release *his* code as GPLv2
> > only, but I suspect the files as a whole really should be dual BSD/GPLv2,
> > due to the numerous other stakeholders in those files.
>
> This mess has been occurring in the kernel for years. The DRM graphics
> drivers
d reshipping them under the BSD license
> without the author explicitly agreeing to this.
>
> What if a patch spans both code that is pure GPL and code imported
> from BSD, how do you license it?
See the acpi codebase for a worked example.
Alan
-
To unsubscribe from this list: send the l
o the case Theo tries to discuss.
> In http://lkml.org/lkml/2007/8/29/183, Alan Cox managed to summarize
> what Jiri Slaby and Luis Rodriguez were trying to do by proposing a
> modification of a Dual Licenced file without the consent of all the
> authors. Alan asks "So whats the pro
> co-operation. Together we advance our detective work and knowledge of
> the Macintosh platforms to the good of all Macintosh users dumped"
>
> Alan Cox circa 1999.
>
> http://lists.freedesktop.org/archives/xorg/2007-August/027419.html
>
> "well I'd be qu
> - If you receive ISC or BSD licensed code, you may not delete the
> license. Same principle, since the notice says so. It's the law.
> Really.
You can shout this all you like but you would be wrong. You can remove
the licence if you have permission to do so. For the ath c files there
was per
On Sun, 02 Sep 2007 13:20:27 +0200 (CEST)
Igor Sobrado <[EMAIL PROTECTED]> wrote:
> On Sun, 2 Sep 2007, Alan Cox wrote:
> > You can shout this all you like but you would be wrong. You can remove
> > the licence if you have permission to do so. For the ath c files there
> &
rned itself GPL by adding that file as
according to your argument "it must be distributed under *all* these
licensing terms concurrently".
Alan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo
we do not like.
If the author has conveyed that right to you, then you may usually do so.
Alan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
me as Linux) let me know and I'll work on
> > getting the spec changed.
>
> The whole AF_UNSPEC thing I'm almost certain comes from BSD, which has
> behaved that way for centuries.
We got it from the 1003.4g draft socket specification if I remember
rightly. Its entirely pl
h is a valid address in some protocols. If I remember rightly then
appletalk net 0 node 0 port 0 is valid although I'd want to look in the
book to check that - ditto AF_ECONET although I doubt anyone cares too
much 8)
Alan
-
To unsubscribe from this list: send the line "unsubscribe netdev&q
/hard drive.
dgrs should be using the request_firmware interface. Actually dgrs is
probably a good candidate for /dev/null
Alan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
> According to an earlier thread, dgrs was never really maintained,
> written for hardware that was never really distributed widely, and very
> likely hasn't had users in years... if ever.
>
> If that picture is accurate (it's a story I was told), then I am
> definitely queueing up a deletion p
On Sat, Sep 22, 2007 at 08:14:15PM +0400, Evgeniy Polyakov wrote:
> of operations. There are four ways where bind can fail:
>
> 1. unsufficient rights - nothing can help here
> 2. there is no memory - async binding can not help here too, since it
> some memory just has to be allocated to sav
On Sat, Sep 22, 2007 at 10:58:18PM -0700, David Miller wrote:
> From: Ulrich Drepper <[EMAIL PROTECTED]>
> Date: Sat, 22 Sep 2007 10:11:01 -0700
>
> > There was no public mail. I asked RH engineering for proposals for
> > changes to the POSIX spec and Alan replied.
preciated.
--
Regards,
Gaurav Aggarwal
You may also see the information on the linux-net wiki:
http://linux-net.osdl.org/index.php/Main_Page.
Also, read some threads on netdev list. It has a lot of information
there too.
--
--
Best Regards
Alan Menegotto
-
To unsubscribe from this list:
> +/**
> + * try_to_cancel_delayed_work - Try to kill pending scheduled, delayed work
> + * @work: the work to cancel
> + *
> + * Try to kill off a pending schedule_delayed_work().
> + * - The timer may still be running afterwards, and if so, the work may still
> + * be pending
> + * - Returns -1
> > very odd line split
>
> It's not really odd. The "static" and "inline" don't actually add anything to
> the function template. They're merely scope limiters / optimisation
> controllers, and so make a lot of sense placed on their own line.
As do many things but the goal of the coding style
> Sockets of AF_RXRPC family are:
>
> (1) created as type SOCK_RPC;
There is no such socket type and please don't invent one
If your messages are datagrams and unreliable -> SOCK_DGRAM
If your messages are datagrams and reliable -> SOCK_RDM
If your messages are datagrams, reliable and ordered
On Fri, 16 Mar 2007 14:23:13 +
David Howells <[EMAIL PROTECTED]> wrote:
> Alan Cox <[EMAIL PROTECTED]> wrote:
>
> > If your messages are datagrams and unreliable -> SOCK_DGRAM
>
> Nope.
>
> > If your messages are datagrams and reliable -> SO
> I know what they are; and I don't think that what's available covers it.
>
> > and use a proper standard socket type.
>
> Assuming that that list is exhaustive...
SOCK_RDM seems to match perfectly well here. The point isn't to enumerate
everything in the universe the point is to find "works li
> IMHO the problem with classifying RxRPC as a "reliable datagram"
> socket is that even an atomic unidirectional communication isn't a
> single datagram, it's at least 3; there is shared connection state
Thats fine. Any *reliable* protocol sends more than one packet per
message you send. RD
> message transmission. You yourself defined RDM to be a datagram service.
> RxRPC is not, in my opinion, a datagram service, and neither is it a stream
> service.
Message is what I should have said.
> Interestingly, searching for SOCK_RDM definitions with google shows there's
> some disagreemen
> > Other RPC types use normal socket types.
>
> They do? Examples please. I didn't think Linux, at least, has any other RPC
> socket families, though I could be wrong as I haven't made a thorough study of
> them.
SunRPC is implemented in user space and uses the existing TCP/IP layer
and socket
O> No, it's not. SOCK_DGRAM is an unreliable, unidirectional datagram passing
> service.
Thats funny UDP receives and sends packets.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/m
> (*) SOCK_RPC has been removed. AF_RXRPC sockets now simply ignore the "type"
> argument to socket().
This is also incorrect
NAK
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.or
> These patches together supply secure client-side RxRPC connectivity as a Linux
> kernel socket family. Only the transport/session side is supplied - the
> presentation side (marshalling the data) is left to the client. Copies of the
> patches can be found here:
Some of them don't seem to be ma
Ok quickly going over the code that hasn't made the list
- recvmsg not supporting MSG_TRUNC is rather weird and really ought to be
fixed one day as its useful to find out the sizeof message pending when
combined with MSG_PEEK
- RXRPC_MIN_SECURITY_LEVEL reads into rx->min_sec_level and then if it
n you can't put the exact back trace in "[xxx]" and the ones we
see on the stack which dont look like call trace as ?xxx? It makes the
code a bit trickier but we depend on the quality of traces
Alan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the
On Wed, Mar 28, 2007 at 10:44:31AM +0530, Shani wrote:
> Hi,
>
> Replacing with time_after in drivers/net/eexpress.c
> Applies and compiles clean on latest tree.Not tested.
>
> thanks.
>
> Signed-off-by: Shani Moideen <[EMAIL PROTECTED]>
NAK as not tested. The existing code is known to work so
Rank 7: uart_write
> Warning at drivers/serial/serial_core.c:490 in uart_write()
> Reported 2 times
Seems to be more of the Bluetooth stuf
Alan
--
"DASD is not really IBM - it has a vowel"
-Arjan van de Ven
--
To unsubsc
ges... And wondering how to properly elevate
> > this issue (prompt Greg about it, new thread, bug #, ...?)
It looks like Greg misused the debugfs API -- which is ironic, because
he wrote debugfs in the first place! :-)
Let me know if this patch fixes the problem. If it does, I'll subm
ded and fixing that would
be much more productive.
Alan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ot be compiling their own modules
but loading in ones to test provided by their vendor - which may of
course then need different ksyms
Alan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
st enable CONFIG_DEBUGFS is USB_DEBUG is enabled and
> then simplify this logic a bunch at the same time.
Most distributions enable CONFIG_DEBUGFS by default, don't they? So
this problem only comes up when people make up their own configs.
Having USB_DEBUG enabled and DEBUGFS disabled seem
On Tue, 1 Jan 2008 15:47:35 +0200
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This patch contains the scheduled removal of the shaper driver.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[EMAIL PROTECTED]>
--
To unsubscribe from this list:
On Tue, 1 Jan 2008, Greg KH wrote:
> On Mon, Dec 31, 2007 at 11:26:43AM -0800, Greg KH wrote:
> > On Mon, Dec 31, 2007 at 12:49:52PM -0500, Alan Stern wrote:
> > > On Sun, 30 Dec 2007, Greg KH wrote:
> > >
> > > > > It looks like Greg misused t
> and the parallel portions/comments in unix_dgram_recvmsg(),
> it looks like there's been a lot of uncertainty as to how
> file descriptor passing should be handled durning MSG_PEEK
> operations. To quote:
The specs basically don't answer the question. What is critical is that
the behaviour does
give them a 1-800 Intel number to
phone, but they should be able to continue as well.
Alan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
d don't re-enable the timer if it is set. Even
without any memory barriers, the timer routine won't iterate more than
once or twice.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
(if possible) to be sure that the timer won't run
> anymore?
> (Taking in the account the fact that it re-enables itself)
Use del_timer_sync(). It guarantees that when it returns, the timer
will be stopped and the timer routine will no longer be running on any
CPU.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
time I looked at the source code, that's what it did. I'll look
again... Yep, it still does. It checks to see if the timer routine is
currently running; if so then it waits a little while and tries again.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe
.
Regards
Alan
-Original Message-
From: David Miller [mailto:da...@davemloft.net]
Sent: 31 May 2016 19:39
To: Alan Davey
Cc: netdev@vger.kernel.org; kuz...@ms2.inr.ac.ru; jmor...@namei.org;
yoshf...@linux-ipv6.org; ka...@trash.net
Subject: Re: [PATCH] net: Fragment large datagrams even when
ket failing.
What is your thinking on taking the patch?
Regards
Alan
c() (net/ipv4/raw.c). Datagrams are no longer limited to the
interface MTU size if the IP_HDRINCL option is set, but are fragmented, if
necessary, in the same way as all other datagrams.
Signed-off-by: Alan Davey
---
net/ipv4/raw.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/net/ipv4/raw.c b/n
ection (or more generally, to change the interval at
which it occurs).
But checking the runtime_auto flag is probably not a great idea. Even
if it isn't set, collecting statistics is likely to wait up a device
that otherwise would have remained suspended.
Perhaps the best solution is to collect the statistics only when the
device is not suspended or is about to suspend.
Alan Stern
On Mon, 21 Mar 2016, Oliver Neukum wrote:
> On Mon, 2016-03-21 at 10:57 -0400, Alan Stern wrote:
>
> > One possible solution is to export a sysfs parameter to prevent
> > statistics collection (or more generally, to change the interval at
> > which it occurs).
>
statistics interval to
the autosuspend timeout (or 0 if autosuspend is disabled) plus some
fixed value.
Alan Stern
On Mon, 21 Mar 2016, Oliver Neukum wrote:
> On Mon, 2016-03-21 at 14:24 -0400, Alan Stern wrote:
> > On Mon, 21 Mar 2016, Oliver Neukum wrote:
> >
> > > On Mon, 2016-03-21 at 10:57 -0400, Alan Stern wrote:
> > >
> > > > One possible solut
the autosuspend timeout. That's why I suggested making the
> > interval adjustable.
>
> What do you mean statistics interval?
> Interval calling ndo_get_stats64 or another thread/timer or else getting
> statistics?
The time between calls to ndo_get_stats64, since that's the routine
which queries the device.
Alan Stern
On Tue, 22 Mar 2016, Oliver Neukum wrote:
> On Mon, 2016-03-21 at 15:30 -0400, Alan Stern wrote:
> > On Mon, 21 Mar 2016, Oliver Neukum wrote:
> >
>
> > > We have an autosuspend timeout because we think that IO, if it will
> > > come at all, is likeliest
On Tue, 22 Mar 2016, Oliver Neukum wrote:
> On Tue, 2016-03-22 at 10:21 -0400, Alan Stern wrote:
> > I don't see any point in resuming the device just in order to collect
> > operating statistics. If it was already suspended then it wasn't
> > operating, so
AX.25 case the header is variable length so this still doesn't fix
the regression as far as I can see.
Alan
On 02/23/2016 04:29 AM, Alexander Aring wrote:
Alan, do you have some comments about that?
Currently the mrf24j40 goes into a deadlock if a frame with security
enable bit is set. As you see, I helped myself to create this patch and solve
this stupid default behaviour of mrf24j40. :-)
Hi Alex
The TX part,
3. The RX part.
The patch description only really describes the RX part.
Other than that, the actual code seems OK to me.
Alan.
On Fri, 2016-02-26 at 12:33 -0500, Willem de Bruijn wrote:
> On Fri, Feb 26, 2016 at 9:44 AM, Alan Cox
> wrote:
> > On Thu, 2016-02-25 at 15:26 -0500, David Miller wrote:
> > > From: Heikki Hannikainen
> > > Date: Thu, 25 Feb 2016 21:36:07 +0200 (EET)
> > >
properly, but the more validation we do for a privileged interface the
more we prevent applications for testing network behaviour from being
able to run on Linux. Possibly there should be a CAP_SYS_RAWIO test but
making it impossible is a bad step.
Alan
s not set.
A user with CAP_SYS_RAWIO already has the power to control the device
by banging registers so the check is not a security loss.
Alan
ontrol endpoint. And calls the existing
> usbnet_resume thereafter
You know, the USB core already issues a Set-Interface request on the
control endpoint whenever a reset-resume occurs (unless the interface
was using altsetting 0 beforehand). Issuing another Set-Interface
shouldn't make any dif
n that should be true for both runtime suspend and system
suspend.
To put it another way, as far as the device is concerned a suspend is
just a suspend -- there's no different between a runtime suspend and a
system suspend.
Alan Stern
--
To unsubscribe from this list: send the line "unsubs
On Thu, 24 Dec 2015, Oliver Neukum wrote:
> On Wed, 2015-12-23 at 20:32 -0500, Alan Stern wrote:
>
> > I don't understand why the wakeup conditions are different. It seems
> > to me that the choice of which packets will generate a wakeup ought to
> > depend on the
On Thu, 24 Dec 2015, Oliver Neukum wrote:
> On Thu, 2015-12-24 at 10:14 -0500, Alan Stern wrote:
> > On Thu, 24 Dec 2015, Oliver Neukum wrote:
> >
> > > On Wed, 2015-12-23 at 20:32 -0500, Alan Stern wrote:
>
> > > But you cannot keep that setting if the sys
known bug.
Please let me know if you have any questions.
Regards
Alan Davey
that's race-free and cross-platform
involving the use of /dev/null and dup2(), see Listing Five on
http://www.drdobbs.com/parallel/file-descriptors-and-multithreaded-progr/212001285
but I haven't confirmed it works yet.
Thanks,
--
Alan Burlison
--
--
To unsubscribe from this list: s
On 20/10/2015 02:45, Eric Dumazet wrote:
On Tue, 2015-10-20 at 02:12 +0100, Alan Burlison wrote:
Another problem is that if I call close() on a Linux socket that's in
accept() the accept call just sits there until there's an incoming
connection, which succeeds even though the
1 - 100 of 474 matches
Mail list logo
