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
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
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
> >
> > 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
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
>
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 didn'
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
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.
>
>
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 various
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)
>
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) 0x21ca0a9677ff0225acd0d3
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 Chris
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 wireless
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 exci
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
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
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? On
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 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 thinkin
19 matches
Mail list logo
