On Friday, October 13, 2006 10:14 PM, Eric Dumazet wrote:
>
> Martin, I played with libnetfilter_queue
> (http://www.netfilter.org/projects/libnetfilter_queue/index.html)
>
> With this single iptables rules, I was able to do what you want :
> transmit the SYN message to a user application, that ma
Joan Raventos wrote:
>>>Is this a bug in PF_PACKET? Should the socket queue be
>>>emptied by packet_set_ring (called via setsockopt when
>>>PACKET_RX_RING is used) so the above cannot happen?
>>>Should the user-space app drain the socket queue with
>>>recvfrom prior to (4) -quite unlikely in practi
From: Marcel Holtmann <[EMAIL PROTECTED]>
Date: Sun, 15 Oct 2006 18:10:24 +0200
> Please pull from
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6.git
>
Pulled, thanks a lot Marcel.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the bo
Andrew Morton wrote:
>
>>http://bugzilla.kernel.org/show_bug.cgi?id=7366
>>___
>>Oct 15 17:38:40 test kernel: BUG: unable to handle kernel paging request at
>>virtual address d0cb03e0
>>Oct 15 17:38:40 test kernel: printing eip:
>>Oct 15 17:38:40 test kernel: d08fc19b
(plesae provide updates via reply-to-all email, not via the bugzilla
interface)
Looks like a netfilter regression.
On Sun, 15 Oct 2006 14:00:33 -0700
[EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=7366
>
>Summary: BUG: unable to handle kernel paging request
From: Stefano Brivio <[EMAIL PROTECTED]>
The current bcm43xx driver does not contain code to handle PCI-E interfaces
such as the BCM4311 and BCM4312. This patch, originally written by Stefano
Brivio adds the necessary code to enable these interfaces.
Signed-off-by: Stefano Brivio <[EMAIL PROTECT
On Sunday 15 October 2006 6:10 pm, Andrew Morton wrote:
> - A printk if something went bad
Where "bad" would I hope exclude cases where the device
doesn't support MWI ... that is, the "go faster if you can"
advice from the driver, where it isn't an error to run into
the common case of _this_ impl
On Mon, 16 Oct 2006 07:26:37 +1000, Benjamin Herrenschmidt said:
> Somebody patented FIFO thresholds ? Gack ?
The US PTO is fundamentally busticated.
http://www.engadget.com/2006/10/14/cisco-patents-the-triple-play/
Cisco got a patent on the concept of delivering voice, internet, and
cable TV ov
On Mon, 16 Oct 2006 10:44:30 +1000
Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Andrew Morton writes:
>
> > Let me restore the words from my earlier email which you removed so that
> > you could say that:
> >
> > For you the driver author to make assumptions about what's happening
> > inside
Andrew Morton writes:
> Let me restore the words from my earlier email which you removed so that
> you could say that:
>
> For you the driver author to make assumptions about what's happening
> inside pci_set_mwi() is a layering violation. Maybe the bridge got
> hot-unplugged. Maybe the a
On Sun, 15 Oct 2006 17:16:35 -0700
David Brownell <[EMAIL PROTECTED]> wrote:
>
> > You, the driver author _do not know_ what pci_set_mwi() does at present, on
> > all platforms, nor do you know what it does in the future.
>
> I know that it enables MWI accesses ... or fails. Beyond that, there
> > If the drivers doesn't care and if it makes no difference to performance
> > then just delete the call to pci_set_mwi().
> >
> > But if MWI _does_ make a difference to performance then we should tell
> > someone that it isn't working rather than silently misbehaving?
To repeat: it's not "mis
> > I agree that set_mwo() should set MWI if possible, and fail cleanly
> > if it couldn't (for whatever reason). Thing is, choosing to treat
> > that as an error must be the _driver's_ choice ... it'd be wrong to force
> > that policy into the _interface_ by forcing must_check etc.
>
> No. If
On Mon, 16 Oct 2006 10:00:25 +1000 Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Andrew Morton writes:
>
> > If the drivers doesn't care and if it makes no difference to performance
> > then just delete the call to pci_set_mwi().
> >
> > But if MWI _does_ make a difference to performance then we s
Andrew Morton writes:
> If the drivers doesn't care and if it makes no difference to performance
> then just delete the call to pci_set_mwi().
>
> But if MWI _does_ make a difference to performance then we should tell
> someone that it isn't working rather than silently misbehaving?
That sounds
On Mon, 16 Oct 2006 01:02:40 +0100
Alan Cox <[EMAIL PROTECTED]> wrote:
> Ar Sul, 2006-10-15 am 16:18 -0700, ysgrifennodd Andrew Morton:
> > No. If pci_set_mwi() detects an unexpected error then the driver should
> > take some action: report it, recover from it, fail to load, etc. If the
> > driv
Ar Sul, 2006-10-15 am 16:18 -0700, ysgrifennodd Andrew Morton:
> No. If pci_set_mwi() detects an unexpected error then the driver should
> take some action: report it, recover from it, fail to load, etc. If the
> driver fails to do any of this then it's a buggy driver.
Wrong and there are severa
Evgeniy Polyakov wrote:
Existing design does not allow overflow.
And I've pointed out a number of times that this is not practical at
best. There are event sources which can create events which cannot be
coalesced into one single event as it would be required with your design.
Signals are
On Sun, 15 Oct 2006 15:45:58 -0700
David Brownell <[EMAIL PROTECTED]> wrote:
> > In that case its interface is misdesigned, because it doesn't discriminate
> > between "yes-it-does/no-it-doesn't" (which we don't want to report, because
> > either is expected and legitimate) and "something screwed
Evgeniy Polyakov wrote:
In context you have cut, one updated signal mask between calls to event
delivery mechanism (using for example signal()), so it has exactly the
same price.
No, it does not. If the signal mask is recomputed by the program for
each new wait call then you have a lot more w
> > Most drivers should be able to say "enable MWI if possible, but
> > don't worry if it's not possible". Only a few controllers need
> > additional setup to make MWI actually work ... if they couldn't
> > do that setup, that'd be worth a warning before they backed off
> > to run in a non-MWI mod
Ar Llu, 2006-10-16 am 07:26 +1000, ysgrifennodd Benjamin Herrenschmidt:
> On Sat, 2006-10-14 at 15:55 -0400, Jesse Huang wrote:
> > From: Jesse Huang <[EMAIL PROTECTED]>
> >
> > Change Logs:
> > For patent issue need to remove TxStartThresh and RxEarlyThresh. This
> > patent
> > is cut-through p
On Sunday, 15 October 2006 23:35, you wrote:
> > Hi,
> > I'd be thankful for your opinions about that idea. Please forgive me any
> > nuances that I didn't know about.
>
> This limits the system to only talking to one other system on the same
> link. I guess you could have per-MAC keys and asso
On Sun, 15 Oct 2006, Dawid Ciezarkiewicz wrote:
> Hi,
> I'd be thankful for your opinions about that idea. Please forgive me any
> nuances that I didn't know about.
This limits the system to only talking to one other system on the same
link. I guess you could have per-MAC keys and associate th
On Sat, 2006-10-14 at 15:55 -0400, Jesse Huang wrote:
> From: Jesse Huang <[EMAIL PROTECTED]>
>
> Change Logs:
> For patent issue need to remove TxStartThresh and RxEarlyThresh. This patent
> is cut-through patent. If use this function, Tx will start to transmit after
> few data be move in to Tx
Ar Sul, 2006-10-15 am 10:45 -0700, ysgrifennodd Andrew Morton:
> If the drivers doesn't care and if it makes no difference to performance
> then just delete the call to pci_set_mwi().
>
> But if MWI _does_ make a difference to performance then we should tell
> someone that it isn't working rather
On Sun, 15 Oct 2006 12:16:31 -0700
David Brownell <[EMAIL PROTECTED]> wrote:
> (From Alan Cox:)
> > The underlying bug is that someone marked pci_set_mwi must-check, that's
> > wrong for most of the drivers that use it. If you remove the must check
> > annotation from it then the problem and a tho
(From Alan Cox:)
> The underlying bug is that someone marked pci_set_mwi must-check, that's
> wrong for most of the drivers that use it. If you remove the must check
> annotation from it then the problem and a thousand other spurious
> warnings go away.
Yes, there seems to be abuse of this new "mu
This patch correctly initializes the force_unicast_rateidx
and max_ratectrl_rateidx. This was not done previously
and caused a bug in rf80211_simple where when
rate_control_simple_get_rate() was called, the incorrect
rate was selected from the list.
Signed-off-by Modestas Vainius <[EMAIL PROTECTED
Hi Patrick,
Thx for your prompt reply! Plz see some comments inline.
>>
>> Is this a bug in PF_PACKET? Should the socket queue be
>> emptied by packet_set_ring (called via setsockopt when
>> PACKET_RX_RING is used) so the above cannot happen?
>> Should the user-space app drain the socket queue w
On Sun, 15 Oct 2006 07:54:41 -0600
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> On Sat, Oct 14, 2006 at 11:53:59PM -0700, Andrew Morton wrote:
> > It seems to have stopped happening. I don't know why.
>
> Argh. Possibly a mistake during the bisect procedure?
I don't think so - I spent a lot of
On Sun, 15 Oct 2006 07:57:56 -0600
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> On Sun, Oct 15, 2006 at 03:21:22PM +0100, Alan Cox wrote:
> > Ar Sul, 2006-10-15 am 00:08 -0700, ysgrifennodd David Brownell:
> > > Since it's not an error, there should be no such printk ... which
> > > is exactly how
Hi,
I'd be thankful for your opinions about that idea. Please forgive me any
nuances that I didn't know about.
diff --git a/Documentation/networking/ccrypt.txt
b/Documentation/networking/ccrypt.txt
new file mode 100644
index 000..8e46f1e
--- /dev/null
+++ b/Documentation/networking/ccrypt.
Hi Dave,
here are my pending bugfixes for the 2.6.19 kernel. They should resolve
various Bugzilla reports and other issues reported over the last couple
of weeks. Please forward them to Linus as soon as possible.
Regards
Marcel
Please pull from
git://git.kernel.org/pub/scm/linux/kerne
Joan Raventos wrote:
> Hello,
>
> In order to use PF_PACKET/SOCK_RAW with PACKET_RX_RING
> one would possibly do (as described in
> Documentation/networking/packet_mmap.txt):
> 1. setup PF_PACKET socket via socket call.
> 2. use setsockopt to change the PF_PACKET socket into
> PACKET_RX_RING mode
On Sun, Oct 15, 2006 at 03:21:22PM +0100, Alan Cox wrote:
> Ar Sul, 2006-10-15 am 00:08 -0700, ysgrifennodd David Brownell:
> > Since it's not an error, there should be no such printk ... which
> > is exactly how it's coded above.
>
> The underlying bug is that someone marked pci_set_mwi must-chec
On Sun, Oct 15, 2006 at 12:08:09AM -0700, David Brownell wrote:
> > But the only effect of returning EINVAL is a printk (for this particular
> > driver):
> >
> > /* PCI Memory-Write-Invalidate cycle support is optional (uncommon)
> > */
> > retval = pci_set_mwi(pdev);
> > i
Ar Sul, 2006-10-15 am 00:08 -0700, ysgrifennodd David Brownell:
> Since it's not an error, there should be no such printk ... which
> is exactly how it's coded above.
The underlying bug is that someone marked pci_set_mwi must-check, that's
wrong for most of the drivers that use it. If you remove t
On Sat, Oct 14, 2006 at 11:53:59PM -0700, Andrew Morton wrote:
> It seems to have stopped happening. I don't know why.
Argh. Possibly a mistake during the bisect procedure?
> gregkh-pci-pci-prevent-user-config-space-access-during-power-state-transitions.patch
> still breaks suspend though: http
> But the only effect of returning EINVAL is a printk (for this particular
> driver):
>
> /* PCI Memory-Write-Invalidate cycle support is optional (uncommon) */
> retval = pci_set_mwi(pdev);
> if (!retval)
> ehci_dbg(ehci, "MWI active\n");
Erm, I've lost con
40 matches
Mail list logo
