On Thu, Apr 26, 2007 at 04:12:40PM +0200, Blaisorblade wrote:
> If there are so many interfaces and they were just reordered, this could be
> caused by a (non-existant) change in link order. Or (I don't know how) it
> could derive some way from the fact that interfaces are initialized later
> (i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Jeff Dike wrote:
> On Thu, Apr 26, 2007 at 04:12:40PM +0200, Blaisorblade wrote:
>> If there are so many interfaces and they were just reordered, this could be
>> caused by a (non-existant) change in link order. Or (I don't know how) it
>> could de
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
>> The easiest way to work around this is to provide a MAC on the UML
>> command line.
> Except, pcap doesn't have the option.
> I am looking at pcap_user.c and pcap_kern.c trying to figure out where I
> can add parsing for that.
in: check_transport(
On Fri, Apr 27, 2007 at 04:21:11PM +0100, Antoine Martin wrote:
> Question remains as to why the mac address was the same until 2.6.20 and
> is now different.
We started providing randomized MACs at bootup instead of deriving
them from the IP when the interface was brought up. The old behavior
br
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Jeff Dike wrote:
> On Fri, Apr 27, 2007 at 04:21:11PM +0100, Antoine Martin wrote:
>> Question remains as to why the mac address was the same until 2.6.20 and
>> is now different.
>
> We started providing randomized MACs at bootup instead of derivin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Antoine Martin wrote:
> Jeff Dike wrote:
>> On Fri, Apr 27, 2007 at 04:21:11PM +0100, Antoine Martin wrote:
>>> Question remains as to why the mac address was the same until 2.6.20 and
>>> is now different.
>> We started providing randomized MACs at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Antoine Martin wrote:
> Antoine Martin wrote:
>> Jeff Dike wrote:
>>> On Fri, Apr 27, 2007 at 04:21:11PM +0100, Antoine Martin wrote:
Question remains as to why the mac address was the same until 2.6.20 and
is now different.
>>> We started
On Fri, Apr 27, 2007 at 07:27:48PM +0200, Sam Ravnborg wrote:
> Then atomic.h should include system.h and not rely on someone else doing it.
> Yes - then system.h may be included twice but that's ok.
I tried that - Andi didn't like it. My current thinking is to pull the
cmpxchg stuff out of syste
From: Miklos Szeredi <[EMAIL PROTECTED]>
I get lot's of these on i386:
In file included from include/asm/atomic.h:10,
from include/linux/file.h:9,
from mm/fadvise.c:12:
include/asm/arch/atomic.h: In function ‘atomic_add_unless’:
include/asm/arch/atomic.h:240: wa
From: Miklos Szeredi <[EMAIL PROTECTED]>
These haven't been fixed for ages. Just make comments out of them.
arch/um/kernel/skas/process.c:181:2: warning: #warning Need to look up
userspace_pid by cpu
arch/um/kernel/skas/process.c:187:2: warning: #warning Need to look up
userspace_pid by cpu
ar
On Fri, Apr 27, 2007 at 06:18:02PM +0200, Miklos Szeredi wrote:
>
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> I get lot's of these on i386:
>
> In file included from include/asm/atomic.h:10,
> from include/linux/file.h:9,
> from mm/fadvise.c:12:
> include/asm
On Fri, Apr 27, 2007 at 05:46:29PM +0100, Antoine Martin wrote:
> Attached.
>
> Not sure which approach is best:
>
> 1) this one requires a command line like:
> "vmlinux eth0=pcap,eth0,,mac=00:01:02:03:04:05"
> 2) or this one: which just assumes that the mac address is any option
> that isn't [n
12 matches
Mail list logo
