On Friday 08 September 2006 22:11, Herbert Poetzl wrote:
actually the light-weight ip isolation runs perfectly
fine _without_ CAP_NET_ADMIN, as you do not want the
guest to be able to mess with the 'configured' ips at
all (not to speak of interfaces here)
It was only an example. I'm thinking
Gnome42 Gnome42 wrote:
On 9/8/06, Patrick McHardy [EMAIL PROTECTED] wrote:
Can you see the decrypted packets on the incoming interface on the
other side?
No, not the decrypted ones only the encrypted ones. I never see the
decrypted packets. ( I should see them twice right? Once encrypted
On 9/9/06, Patrick McHardy [EMAIL PROTECTED] wrote:
Yes, I meant the SAs. But please use ip -s xfrm state and ip -s xfrm
policy (on both sides), they include a bit more information than
setkey.
Workstation running 2.6.18-rc5-mm1 is the initiator, and responder is
2.6.17-rc6-mm1. This is the
hello,
I've got a Toshiba A110-262 which comes with an 10ec:8136 ethernet chip,
which turns out to be an Realtek 8101E. Seems no in-kernel driver covers
such chips yet.
Realtek offers the GPL'd driver r1000, v1.04 at present, but seems it's not
compatible with current 2.6.x kernel at the module
Gnome42 wrote:
src 34.34.36.1 dst 34.34.36.6
proto esp spi 0x0dc3aba4(230927268) reqid 0(0x) mode tunnel
replay-window 4 seq 0x0001 flag (0x)
auth hmac(md5) 0xfea9e3e8d324265d8b7e17ec42d69b15 (128 bits)
enc cbc(aes)
On 9/9/06, Patrick McHardy [EMAIL PROTECTED] wrote:
src 34.34.36.1 dst 34.34.36.6
proto esp spi 0x0dc3aba4(230927268) reqid 0(0x) mode tunnel
replay-window 4 seq 0x991250886 flag (0x)
auth md5 0xfea9e3e8d324265d8b7e17ec42d69b15 (128 bits)
enc
On Sat, 2006-09-09 at 02:22 -0700, David Miller wrote:
From: Benjamin Herrenschmidt [EMAIL PROTECTED]
Date: Sat, 09 Sep 2006 07:46:02 +1000
I don't think that in general, you have ordering guarantees between
cacheable and non-cacheable stores unless you use explicit barriers.
In fact,
Ar Sul, 2006-09-10 am 08:36 +1000, ysgrifennodd Benjamin Herrenschmidt:
Well, some of you (Alan, you, etc...) seem to imply that it's always
been the rule to have a memory store followed by an MMIO write be
strongly ordered.
It has always been the rule
However, if you look at drivers like
Hi Patrick,
It is working in 2.6.18-rc6-mm1. I thought it was the compile option
'optimize for size' that was causing a miscompilation because when I
compiled -rc6-mm1 I turned that option off and it suddenly started
working. But, then I recompiled -rc5-mm1 with that option off and it
still
Gnome42 wrote:
It is working in 2.6.18-rc6-mm1. I thought it was the compile option
'optimize for size' that was causing a miscompilation because when I
compiled -rc6-mm1 I turned that option off and it suddenly started
working. But, then I recompiled -rc5-mm1 with that option off and it
On Sat, Sep 09, 2006 at 11:57:24AM +0400, Dmitry Mishin wrote:
On Friday 08 September 2006 22:11, Herbert Poetzl wrote:
actually the light-weight ip isolation runs perfectly
fine _without_ CAP_NET_ADMIN, as you do not want the
guest to be able to mess with the 'configured' ips at
all (not
Herbert Poetzl [EMAIL PROTECTED] writes:
On Sat, Sep 09, 2006 at 11:57:24AM +0400, Dmitry Mishin wrote:
On Friday 08 September 2006 22:11, Herbert Poetzl wrote:
actually the light-weight ip isolation runs perfectly
fine _without_ CAP_NET_ADMIN, as you do not want the
guest to be able to
On Sat, 9 Sep 2006 21:37:07 -0700
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=7137
Summary: modprobe eth modules random loading order
Kernel Version: 2.6.17.x
Status: NEW
Severity: high
Owner: [EMAIL PROTECTED]
semantics. At least what is implemented currently on PowerPC is the
__raw_* versions which not only have no barriers at all (they don't even
order between MMIOs, for example, readl might cross writel), and do no
endian swap. Quite a mess of semantics if you ask me... Then there has
From: Benjamin Herrenschmidt [EMAIL PROTECTED]
Date: Sat, 09 Sep 2006 07:46:02 +1000
I don't think that in general, you have ordering guarantees between
cacheable and non-cacheable stores unless you use explicit barriers.
In fact, on most systems you absolutely do have ordering between
MMIO
On Fri, Sep 08, 2006 at 08:47:54PM -0500, Larry Finger wrote:
PLease send this upstream for inclusion in 2.6.18, if possible. This patch
will not work for
wireless-2.6. That patch will be sent to you soon.
Are you saying this will break the upstream branch of wireless-2.6?
I'm not too
John W. Linville wrote:
On Fri, Sep 08, 2006 at 08:47:54PM -0500, Larry Finger wrote:
PLease send this upstream for inclusion in 2.6.18, if possible. This patch
will not work for
wireless-2.6. That patch will be sent to you soon.
Are you saying this will break the upstream branch of
On 8/31/06, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
Sorry ofr long delay - I was on small vacations.
No vacation here, but travel nontheless.
- one point of critique which applied to many proposals over the years:
multiplexer syscalls a bad, really bad. [...]
Can you convince
John,
Larry Finger wrote:
I would like to get a listing of patches for bcm43xx-softmac that are
queued but not yet applied, and the order in which they will be applied.
I want to make sure nothing has fallen through the cracks, and that the
patches will apply cleanly.
I know you have
19 matches
Mail list logo
