Re: cname replace in mail address? [off-topic] (Re: Attn Ronald Klop)

[Don Lewis]

On 27 Aug, Ronald Klop wrote:
> Mandatory? I'm googling, but can't find a document that declares it  
> mandatory and only sendmail seems to do it.
> I think it is lame to use DNS info to rewrite e-mail addresses, but the  
> person who made it 'mandatory' will have good reasons for it.
> 
> Does somebody have a pointer to the specs about this?



  5.2.2  Canonicalization: RFC-821 Section 3.1

 The domain names that a Sender-SMTP sends in MAIL and RCPT
 commands MUST have been  "canonicalized," i.e., they must be
 fully-qualified principal names or domain literals, not
 nicknames or domain abbreviations.  A canonicalized name either
 identifies a host directly or is an MX name; it cannot be a
 CNAME.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.1-PRERELEASE: CPU packages not detected correctly

[Jung-uk Kim]

On Friday 27 August 2010 06:46 pm, Andriy Gapon wrote:
> on 28/08/2010 01:33 Jung-uk Kim said the following:
> > Also, don't forget jhb's work based on ACPI affinity tables.
>
> Not sure how they are applicable here.

Only SRAT is implemented ATM but SLIT should provide CPU affinity 
information without messing with CPUID.  In fact, I'd prefer that 
over messing with Intel's CPUID hacks, which gets messier whenever 
they release a new core. ;-)

Jung-uk Kim
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.1-PRERELEASE: CPU packages not detected correctly

[Andriy Gapon]

on 28/08/2010 01:33 Jung-uk Kim said the following:
> If you are really up to this, it has to be a two-pass process.  Even 
> then, the dmesg won't be pretty because the topology can only be 
> "announced" after all APs have been started.  I mean, nobody's going 
> to like to see a message like this from dmesg output:
> 
> ...
> ACPI APIC Table: 
> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
>  cpu0 (BSP): APIC ID:  0
>  cpu1 (AP): APIC ID:  1
> 
> --- >8 --- Snip several hundred lines! --- >8 ---
> 
> SMP: AP CPU #1 Launched!
> FreeBSD/SMP: 1 package(s) x 2 core(s)
> Root mount waiting for: usbus5 usbus2
> Root mount waiting for: usbus5 usbus2
> ...
> 
> In fact, I implemented something like that while I was writing the 
> patch but I discarded it for an obvious reason. ;-)

Well, I was just going to write that I would still keep the assumption that
physical packages are identical :-)
Not nice, but messing with APs I don't want :)

> Also, don't forget jhb's work based on ACPI affinity tables.

Not sure how they are applicable here.

-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.1-PRERELEASE: CPU packages not detected correctly

[Jung-uk Kim]

On Friday 27 August 2010 06:02 pm, Andriy Gapon wrote:
> on 28/08/2010 00:43 Jung-uk Kim said the following:
> >> Things like that probably do not happen with real hardware much,
> >> but they could.
> >
> > AFAIK, it never happened on a real hardware.
> >
> >> The only way to deal with this is by following the correct
> >> procedure instead of making assumptions based on BSP.  But that
> >> may be hard.
> >
> > Feel free to rewrite the patch.  I never intended to commit the
> > patch, any way.  If I ever did, it was a year ago. :-)
> >
> :-)
>
> BTW, it may be not that hard.
> It seems that 0x4 topology building involves knowing the masks and
> we already have that data (just interpreted differently), and APIC
> IDs of the CPUs and it seems that we also have that.  We don't need
> to bind to CPUs to learn their IDs, we can just iterate over
> cpu_apic_ids[].
>
> The only problem is that currently topo_probe() is called before
> assign_cpu_ids() which populates cpu_apic_ids.
> assign_cpu_ids depends on topo_probe to know hyperthreading_cpus
> value. So, either cpu_apic_ids could be split out or alternatively
> we could use cpu_info[] similarly to how it's done in
> topo_probe_0xb (skipping !cpu_present and cpu_disabled entries).

If you are really up to this, it has to be a two-pass process.  Even 
then, the dmesg won't be pretty because the topology can only be 
"announced" after all APs have been started.  I mean, nobody's going 
to like to see a message like this from dmesg output:

...
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1

--- >8 --- Snip several hundred lines! --- >8 ---

SMP: AP CPU #1 Launched!
FreeBSD/SMP: 1 package(s) x 2 core(s)
Root mount waiting for: usbus5 usbus2
Root mount waiting for: usbus5 usbus2
...

In fact, I implemented something like that while I was writing the 
patch but I discarded it for an obvious reason. ;-)

Also, don't forget jhb's work based on ACPI affinity tables.

Jung-uk Kim
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.1-PRERELEASE: CPU packages not detected correctly

[Andriy Gapon]

on 28/08/2010 01:03 Jung-uk Kim said the following:
> On Friday 27 August 2010 04:19 pm, Andriy Gapon wrote:
>> I still don't get your point.
>> My point is that if the Intel's code gets the topology right, then
>> the hardware is emulated properly and the problem is with the
>> patch.
>> What is your point? :)
> 
> My point is "right" topology means nothing in this context if CPU 
> affinity of guest OS does not reflect hypervisor's point of view.

I see.  And I just cared about the pretty message in dmesg, nothing more :-)


-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.1-PRERELEASE: CPU packages not detected correctly

[Jung-uk Kim]

On Friday 27 August 2010 04:19 pm, Andriy Gapon wrote:
> I still don't get your point.
> My point is that if the Intel's code gets the topology right, then
> the hardware is emulated properly and the problem is with the
> patch.
> What is your point? :)

My point is "right" topology means nothing in this context if CPU 
affinity of guest OS does not reflect hypervisor's point of view.

Jung-uk Kim
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.1-PRERELEASE: CPU packages not detected correctly

[Andriy Gapon]

on 28/08/2010 00:43 Jung-uk Kim said the following:
>> Things like that probably do not happen with real hardware much,
>> but they could.
> 
> AFAIK, it never happened on a real hardware.
> 
>> The only way to deal with this is by following the correct procedure
>> instead of making assumptions based on BSP.  But that may be hard.
> 
> Feel free to rewrite the patch.  I never intended to commit the patch, 
> any way.  If I ever did, it was a year ago. :-)

:-)
BTW, it may be not that hard.
It seems that 0x4 topology building involves knowing the masks and we already
have that data (just interpreted differently), and APIC IDs of the CPUs and it
seems that we also have that.  We don't need to bind to CPUs to learn their IDs,
we can just iterate over cpu_apic_ids[].

The only problem is that currently topo_probe() is called before
assign_cpu_ids() which populates cpu_apic_ids.
assign_cpu_ids depends on topo_probe to know hyperthreading_cpus value.
So, either cpu_apic_ids could be split out or alternatively we could use
cpu_info[] similarly to how it's done in topo_probe_0xb (skipping !cpu_present
and cpu_disabled entries).


-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.1-PRERELEASE: CPU packages not detected correctly

[Jung-uk Kim]

On Friday 27 August 2010 05:25 pm, Andriy Gapon wrote:
> on 27/08/2010 23:18 pluknet said the following:
> > First, sorry for late replay, and thanks Andriy for kicking me ;)
> >
> > Something really weird there .
> > topo_probe_0xb() falls early on 1st iteration back to
> > topo_probe_0x4(). topo_probe_0x4() returns incorrect data as
> > well.
> >
> > topo_probe: cpu_high = b
> > topo_probe: cpu_vendor_id = 8086
> > topo_probe_0xb: i = 0, p[1] = 0
> > topo_probe_0x4: cpu_procinfo = 200800
> > topo_probe_0x4: cpu_logical = 32
> > topo_probe_0x4: i = 0, type = 1
> > topo_probe_0x4: i = 0, level = 1
> > topo_probe_0x4: i = 0, logical = 1
> > topo_probe_0x4: i = 0, cores = 16
> > topo_probe_0x4: i = 1, type = 2
> > topo_probe_0x4: i = 1, level = 1
> > topo_probe_0x4: i = 1, logical = 1
> > topo_probe_0x4: i = 1, cores = 16
> > topo_probe_0x4: i = 2, type = 3
> > topo_probe_0x4: i = 2, level = 2
> > topo_probe_0x4: i = 2, logical = 1
> > topo_probe_0x4: i = 2, cores = 16
> > topo_probe#1: mp_ncpus = 3
> > topo_probe#1: cpu_cores = 1
> > topo_probe#1: cpu_logical = 32
> > topo_probe#1: hyperthreading_cpus = 32
> > topo_probe#2: mp_ncpus = 3
> > topo_probe#2: cpu_cores = 1
> > topo_probe#2: cpu_logical = 32
> > topo_probe#2: hyperthreading_cpus = 32
>
> My interpretation:
>
> 1. Current (unpatched) code reports correct results either by a
> chance or because Jeff knows some magic patterns.
> cpu_high (CPUID_Leaf_Max in Intel's lingo) is 0xb,
> but CPUID.(EAX=11, ECX=0):EBX == 0,
> which means that we should fallback to 0x4 method.
> But the code doesn't do that and instead simply sets cpu_logical to
> 1 and cpu_cores stays zero, which is later translated to mp_ncpus,
> which happens to match the reality.
>
> 2. Intel reports correct results, because it properly probes the
> topology. It binds to each of the logical processors available and
> checks their APIC IDs against masks and builds topology info.
>
> 3. Patched code works incorrectly, because essentially it only
> calculates masks for CPU (and cache, for some reason) topology
> building.  Instead of checking IDs against those masks, the code
> assumes numbers of cores and threads are at their maximum values
> allowed by the masks[*].  But that is not true and the numbers do
> not add up and we get that strange incorrect result.

Yes, your interpretation is correct, I believe.

> Things like that probably do not happen with real hardware much,
> but they could.

AFAIK, it never happened on a real hardware.

> The only way to deal with this is by following the correct procedure
> instead of making assumptions based on BSP.  But that may be hard.

Feel free to rewrite the patch.  I never intended to commit the patch, 
any way.  If I ever did, it was a year ago. :-)

> [*] E.g. that page says:
> CPUID.1:EBX[23:16] represents the maximum number of addressable IDs
> (initial APIC ID) that can be assigned to logical processors in a
> physical package. The value may not be the same as the number of
> logical processors that are present in the hardware of a physical
> package. The value of (1 + (CPUID.(EAX=4, ECX=0):EAX[31:26] ))
> represents the maximum number of addressable IDs (Core_ID) that can
> be used to enumerate different processor cores in a physical
> package. The value also can be different than the actual number of
> processor cores that are present in the hardware of a physical
> package.

Yes, I already know that.

Jung-uk Kim
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.1-PRERELEASE: CPU packages not detected correctly

[Andriy Gapon]

on 27/08/2010 23:18 pluknet said the following:
> First, sorry for late replay, and thanks Andriy for kicking me ;)
> 
> Something really weird there .
> topo_probe_0xb() falls early on 1st iteration back to topo_probe_0x4().
> topo_probe_0x4() returns incorrect data as well.
> 
> topo_probe: cpu_high = b
> topo_probe: cpu_vendor_id = 8086
> topo_probe_0xb: i = 0, p[1] = 0
> topo_probe_0x4: cpu_procinfo = 200800
> topo_probe_0x4: cpu_logical = 32
> topo_probe_0x4: i = 0, type = 1
> topo_probe_0x4: i = 0, level = 1
> topo_probe_0x4: i = 0, logical = 1
> topo_probe_0x4: i = 0, cores = 16
> topo_probe_0x4: i = 1, type = 2
> topo_probe_0x4: i = 1, level = 1
> topo_probe_0x4: i = 1, logical = 1
> topo_probe_0x4: i = 1, cores = 16
> topo_probe_0x4: i = 2, type = 3
> topo_probe_0x4: i = 2, level = 2
> topo_probe_0x4: i = 2, logical = 1
> topo_probe_0x4: i = 2, cores = 16
> topo_probe#1: mp_ncpus = 3
> topo_probe#1: cpu_cores = 1
> topo_probe#1: cpu_logical = 32
> topo_probe#1: hyperthreading_cpus = 32
> topo_probe#2: mp_ncpus = 3
> topo_probe#2: cpu_cores = 1
> topo_probe#2: cpu_logical = 32
> topo_probe#2: hyperthreading_cpus = 32


My interpretation:

1. Current (unpatched) code reports correct results either by a chance or
because Jeff knows some magic patterns.
cpu_high (CPUID_Leaf_Max in Intel's lingo) is 0xb,
but CPUID.(EAX=11, ECX=0):EBX == 0,
which means that we should fallback to 0x4 method.
But the code doesn't do that and instead simply sets cpu_logical to 1 and
cpu_cores stays zero, which is later translated to mp_ncpus, which happens to
match the reality.

2. Intel reports correct results, because it properly probes the topology.
It binds to each of the logical processors available and checks their APIC IDs
against masks and builds topology info.

3. Patched code works incorrectly, because essentially it only calculates masks
for CPU (and cache, for some reason) topology building.  Instead of checking IDs
against those masks, the code assumes numbers of cores and threads are at their
maximum values allowed by the masks[*].  But that is not true and the numbers do
not add up and we get that strange incorrect result.

Things like that probably do not happen with real hardware much, but they could.
The only way to deal with this is by following the correct procedure instead of
making assumptions based on BSP.  But that may be hard.

[*] E.g. that page says:
CPUID.1:EBX[23:16] represents the maximum number of addressable IDs (initial
APIC ID) that can be assigned to logical processors in a physical package. The
value may not be the same as the number of logical processors that are present
in the hardware of a physical package. The value of (1 + (CPUID.(EAX=4,
ECX=0):EAX[31:26] )) represents the maximum number of addressable IDs (Core_ID)
that can be used to enumerate different processor cores in a physical package.
The value also can be different than the actual number of processor cores that
are present in the hardware of a physical package.

-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.1-PRERELEASE: CPU packages not detected correctly

[Andriy Gapon]

on 27/08/2010 23:15 Jung-uk Kim said the following:
> I quickly looked over Xen sources.  It seems the CPUID instruction is
> translated by this code:
> 
> http://lxr.xensource.com/lxr/source/tools/libxc/xc_cpuid_x86.c
> 
> For HVM case, this is how the CPUID_HTT_CORES is set:
> 
> 185 case 0x0001:
> 186 /*
> 187  * EBX[23:16] is Maximum Logical Processors Per Package.
> 188  * Update to reflect vLAPIC_ID = vCPU_ID * 2.
> 189  */
> 190 regs[1] = (regs[1] & 0xu) | ((regs[1] & 0x007fu) << 
> 1);
> 
> But CPUID 0x0b is not handled and falls here:

Does it have to be handled?  0x4 should still work.

> 265 default:
> 266 regs[0] = regs[1] = regs[2] = regs[3] = 0;
> 267 break;
> 
> I am not a Xen developer, so please don't shoot me. ;-)

I still don't get your point.
My point is that if the Intel's code gets the topology right, then the hardware
is emulated properly and the problem is with the patch.
What is your point? :)

-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.1-PRERELEASE: CPU packages not detected correctly

[pluknet]

On 19 August 2010 20:56, pluknet  wrote:
> On 19 August 2010 20:39, Andriy Gapon  wrote:
>> on 10/08/2010 19:55 pluknet said the following:
>>> On 16 July 2010 19:47, Jung-uk Kim  wrote:
 The patch should apply fine on both sys/amd64/amd64/mp_machdep.c and
 sys/i386/i386/mp_machdep.c.

 http://people.freebsd.org/~jkim/mp_machdep2.diff

>>>
>>>
>>> Hi.
>>>
>>> Just checked on Xen HVM with 3 cores.
>>> 1) 8.1 unmodified:
>>> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs
>>> FreeBSD/SMP: 1 package(s) x 3 core(s)
>>>
>>> 2) 8.1 + patch
>>> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs
>>> FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads
>>> WARNING: Non-uniform processors.
>>> WARNING: Using suboptimal topology.
>>
>> Can you debug, e.g. with printfs, what exactly goes wrong?
>> I wonder if in this case code follows some unusual/unexpected path.
>
> Sorry, I'm a bit busy right now.
> I hope to debug this somewhere in the next week.

First, sorry for late replay, and thanks Andriy for kicking me ;)

Something really weird there .
topo_probe_0xb() falls early on 1st iteration back to topo_probe_0x4().
topo_probe_0x4() returns incorrect data as well.

topo_probe: cpu_high = b
topo_probe: cpu_vendor_id = 8086
topo_probe_0xb: i = 0, p[1] = 0
topo_probe_0x4: cpu_procinfo = 200800
topo_probe_0x4: cpu_logical = 32
topo_probe_0x4: i = 0, type = 1
topo_probe_0x4: i = 0, level = 1
topo_probe_0x4: i = 0, logical = 1
topo_probe_0x4: i = 0, cores = 16
topo_probe_0x4: i = 1, type = 2
topo_probe_0x4: i = 1, level = 1
topo_probe_0x4: i = 1, logical = 1
topo_probe_0x4: i = 1, cores = 16
topo_probe_0x4: i = 2, type = 3
topo_probe_0x4: i = 2, level = 2
topo_probe_0x4: i = 2, logical = 1
topo_probe_0x4: i = 2, cores = 16
topo_probe#1: mp_ncpus = 3
topo_probe#1: cpu_cores = 1
topo_probe#1: cpu_logical = 32
topo_probe#1: hyperthreading_cpus = 32
topo_probe#2: mp_ncpus = 3
topo_probe#2: cpu_cores = 1
topo_probe#2: cpu_logical = 32
topo_probe#2: hyperthreading_cpus = 32


%%%
static void
topo_probe_0x4(void)
{
u_int p[4];
int cores;
int i;
int level;
int logical;
int type;

cpu_logical = (cpu_feature & CPUID_HTT) != 0 ?
(cpu_procinfo & CPUID_HTT_CORES) >> 16 : 1;
printf("topo_probe_0x4: cpu_procinfo = %x\n", cpu_procinfo);
printf("topo_probe_0x4: cpu_logical = %d\n", cpu_logical);
if (cpu_logical == 1) {
cpu_cores = 1;
return;
}

/* We only support three levels for now. */
for (i = 0; i < 3; i++) {
cpuid_count(0x04, i, p);
type = p[0] & 0x1f;
printf("topo_probe_0x4: i = %d, type = %d\n", i, type);
level = (p[0] >> 5) & 0x7;
printf("topo_probe_0x4: i = %d, level = %d\n", i, level);
logical = ((p[0] >> 14) & 0xfff) + 1;
printf("topo_probe_0x4: i = %d, logical = %d\n", i, logical);
cores = ((p[0] >> 26) & 0x3f) + 1;
printf("topo_probe_0x4: i = %d, cores = %d\n", i, cores);
if (type == 0)
break;
if (level == 1 && cpu_logical == logical * cores) {
cpu_cores = cores;
cpu_logical = logical;
break;
}
}
if (cpu_cores == 0)
cpu_cores = 1;
if (cpu_logical > 1)
hyperthreading_cpus = logical_cpus = cpu_logical;
}

static void
topo_probe_0xb(void)
{
u_int p[4];
int bits;
int cnt;
int i;
int logical;
int type;
int x;

/* We only support three levels for now. */
for (i = 0; i < 3; i++) {
cpuid_count(0x0b, i, p);

/*
 * Fall back if it is not really supported.
 */
if (i == 0 && p[1] == 0) {
printf("topo_probe_0xb: i = %d, p[1] = %d\n", i, p[1]);
topo_probe_0x4();
return;
}
[...]
}

static void
topo_probe(void)
{
static int cpu_topo_probed = 0;

if (cpu_topo_probed)
return;

printf("topo_probe: cpu_high = %x\n", cpu_high);
printf("topo_probe: cpu_vendor_id = %x\n", cpu_vendor_id);
logical_cpus = logical_cpus_mask = 0;
if (cpu_vendor_id == CPU_VENDOR_AMD)
topo_probe_amd();
else if (cpu_vendor_id == CPU_VENDOR_INTEL) {
if (cpu_high >= 0xb)
topo_probe_0xb();
else if (cpu_high >= 0x4)
topo_probe_0x4();
}
printf("topo_probe#1: mp_ncpus = %d\n", mp_ncpus);
printf("topo_probe#1: cpu_cores = %d\n", cpu_cores);
printf("topo_probe#1: cpu_logical = %d\n", cpu_logical);
printf("topo_probe#1: hyperthreadin

Re: 8.1-PRERELEASE: CPU packages not detected correctly

[Jung-uk Kim]

On Friday 27 August 2010 03:47 pm, Andriy Gapon wrote:
> on 27/08/2010 22:36 Jung-uk Kim said the following:
> > Now, back to my original question.  My point was, we should never
> > trust any CPUIDs on emulated CPU if they are translated.  What
> > should happen if you have four physical cores and you "assign"
> > just one for VirtualBox, for example?  What should we "announce"
> > if you are emulating two cores on UP host?  How do we know
> > whether it is "the" real BSP or not?  Is it really bound to a
> > CPU?  Is "CPUID leaf 11" emulated properly?  If not, is it an
> > emulator bug or a guest OS bug? Do we really care about "physical
> > topology" in these cases?  IMHO, the answer is no, we don't, and
> > we should say "all cores are independent".  If anyone really
> > cares and wants prettier printing, we may say "N virtual cores",
> > though.
>
> Thanks a lot for the rest of the info that I snipped, very
> interesting and useful!
>
> To this issue - I'd say let the developers of virtual machines
> worry that their machines look like real hardware, not us.
> More specifically, in this thread we saw that current FreeBSD code
> (without the patch) and Intel's code detect the same topology and
> that topology looks reasonable for the person who started the
> thread.  With the patch though, detected topology looks different.
> So I'd rather not worry about the general case of virtual machines
> right now. Let's first see more evidence of whether we should trust
> them or not.

I quickly looked over Xen sources.  It seems the CPUID instruction is
translated by this code:

http://lxr.xensource.com/lxr/source/tools/libxc/xc_cpuid_x86.c

For HVM case, this is how the CPUID_HTT_CORES is set:

185 case 0x0001:
186 /*
187  * EBX[23:16] is Maximum Logical Processors Per Package.
188  * Update to reflect vLAPIC_ID = vCPU_ID * 2.
189  */
190 regs[1] = (regs[1] & 0xu) | ((regs[1] & 0x007fu) << 1);

But CPUID 0x0b is not handled and falls here:

265 default:
266 regs[0] = regs[1] = regs[2] = regs[3] = 0;
267 break;

I am not a Xen developer, so please don't shoot me. ;-)

Jung-uk Kim
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Crashes on X7SPE-HF with em

[Philipp Wuensche]

Jack Vogel wrote:
> 
> 
> On Fri, Aug 27, 2010 at 6:04 AM, Philipp Wuensche  > wrote:
> 
> Jack Vogel wrote:
> >
> >
> > On Thu, Aug 26, 2010 at 3:15 PM, Jeremy Chadwick
> > mailto:free...@jdc.parodius.com>
> >>
> wrote:
> >
> > On Thu, Aug 26, 2010 at 11:56:48PM +0200, Philipp Wuensche wrote:
> > > Jeremy Chadwick wrote:
> > > >
> > > > CC'ing Jack Vogel of Intel and Yong-Hyeon PYUN who might
> have some
> > > > ideas.  OP's backtrace is here:
> > > >
> > > >
> >
> http://lists.freebsd.org/pipermail/freebsd-stable/2010-August/058425.html
> > > >
> > > > Philipp, can you please provide the following output?
> > > >
> > > > * dmesg | egrep 'em[0-9]'
> > >
> > > em0:  port
> > 0xdc00-0xdc1f mem
> > > 0xfe9e-0xfe9f,0xfe9dc000-0xfe9d irq 16 at device 0.0
> > on pci2
> > > em0: Using MSI interrupt
> > > em0: [FILTER]
> > > em0: Ethernet address: 00:25:90:04:6e:fa
> > > em1:  port
> > 0xec00-0xec1f mem
> > > 0xfeae-0xfeaf,0xfeadc000-0xfead irq 17 at device 0.0
> > on pci3
> > > em1: Using MSI interrupt
> > > em1: [FILTER]
> > > em1: Ethernet address: 00:25:90:04:6e:fb
> > >
> > > > * uname -a (you can XXX out the machine name if
> need be)
> > >
> > > FreeBSD XXX 8.1-STABLE FreeBSD 8.1-STABLE #2: Wed Aug 25
> 10:38:50 CEST
> > > 2010 r...@xxx:/usr/obj/usr/src/sys/XXX  amd64
> > >
> > > Date of source is Aug 17 14:09 CEST 2010. It happend with
> 8.1-RELEASE
> > > too, I can go back to RELEASE or any SVN revision you would
> like,
> > if it
> > > is helping in any way.
> > >
> > > Kernel-config:
> > >
> > > include GENERIC
> > >
> > > ident   XXX
> > >
> > > options IPSEC
> > >
> > > options   DEVICE_POLLING
> > > options ACCEPT_FILTER_HTTP
> > >
> > > options ALTQ
> > >
> > > options ALTQ_CBQ
> > > options ALTQ_RED
> > > options ALTQ_RIO
> > > options ALTQ_HFSC
> > > options ALTQ_PRIQ
> > >
> > > devicecrypto
> > > deviceenc
> > >
> > >
> > > > * pciconf -lvc (only include the em(4) items please)
> > >
> > > e...@pci0:2:0:0:   class=0x02 card=0x060a15d9
> > chip=0x10d38086 rev=0x00
> > > hdr=0x00
> > > vendor = 'Intel Corporation'
> > > device = 'Intel 82574L Gigabit Ethernet Controller
> (82574L)'
> > > class  = network
> > > subclass   = ethernet
> > > cap 01[c8] = powerspec 2  supports D0 D3  current D0
> > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with
> 1 message
> > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256)
> link x1(x1)
> > > cap 11[a0] = MSI-X supports 5 messages in map 0x1c
> > > e...@pci0:3:0:0:   class=0x02 card=0x060a15d9
> > chip=0x10d38086 rev=0x00
> > > hdr=0x00
> > > vendor = 'Intel Corporation'
> > > device = 'Intel 82574L Gigabit Ethernet Controller
> (82574L)'
> > > class  = network
> > > subclass   = ethernet
> > > cap 01[c8] = powerspec 2  supports D0 D3  current D0
> > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with
> 1 message
> > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256)
> link x1(x1)
> > > cap 11[a0] = MSI-X supports 5 messages in map 0x1c
> > >
> > > > * vmstat -i
> > >
> > > interrupt  total   rate
> > > irq1: atkbd0   9  0
> > > cpu0: timer 36544552   1994
> > > irq256: em0 3801  0
> > > irq257: em1 32963909   1799
> > > irq258: ahci0 175662  9
> > > cpu1: timer 36543525   1994
> > > cpu2: timer 36543525   1994
> > > cpu3: timer 36543525   1994
> > > Total  179318508   9786
> > >
> > > There is an shared IPMI interface on em0, but the interface
> is not
> > used
> > > by FreeBSD. em1 is used by four VLANs. Polling is only in the
> > > Kernelconfig, not activated on the devices.
> >

Re: 8.1-PRERELEASE: CPU packages not detected correctly

[Andriy Gapon]

on 27/08/2010 22:36 Jung-uk Kim said the following:
> Now, back to my original question.  My point was, we should never 
> trust any CPUIDs on emulated CPU if they are translated.  What should 
> happen if you have four physical cores and you "assign" just one for 
> VirtualBox, for example?  What should we "announce" if you are 
> emulating two cores on UP host?  How do we know whether it is "the" 
> real BSP or not?  Is it really bound to a CPU?  Is "CPUID leaf 11" 
> emulated properly?  If not, is it an emulator bug or a guest OS bug?  
> Do we really care about "physical topology" in these cases?  IMHO, 
> the answer is no, we don't, and we should say "all cores are 
> independent".  If anyone really cares and wants prettier printing, we 
> may say "N virtual cores", though.


Thanks a lot for the rest of the info that I snipped, very interesting and 
useful!

To this issue - I'd say let the developers of virtual machines worry that their
machines look like real hardware, not us.
More specifically, in this thread we saw that current FreeBSD code (without the
patch) and Intel's code detect the same topology and that topology looks
reasonable for the person who started the thread.  With the patch though,
detected topology looks different.
So I'd rather not worry about the general case of virtual machines right now.
Let's first see more evidence of whether we should trust them or not.

-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.1-PRERELEASE: CPU packages not detected correctly

[Jung-uk Kim]

On Friday 27 August 2010 01:33 pm, Andriy Gapon wrote:
> on 19/08/2010 20:26 Jung-uk Kim said the following:
> > One thing I am not sure is whether those CPUID instructions are
> > executed on *real* CPUs or translated in HVM.  On top of that, I
> > am not even sure they will be executed on *correct* cores.  I bet
> > they won't.
>
> Hmm, I have an impression that we try to detect the topology by
> doing stuff only on BSP and that's why we handle properly only
> uniform topologies.  So that would make your point about correct
> cores moot.
> Am I mistaken?

No, you're correct.  Here goes little background information.

Originally, Jeff tried to implement Intel's algorithm[1] as described 
here, if my understanding is correct:

http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/

Unfortunately, this algorithm needed to execute CPUID instruction on 
every core and aggregate them later.  Thus, he had to compromise and 
made it simpler, I believe[2].  However, this compromise had some 
side effects and my patch was an attempt to correct them (sorry, I 
forgot the details).  It was never committed because Jeff said "I 
will look it over in more detail soon" at the time.  Then, I had to 
return the CPU, which was an engineering sample[3] and now in 
production.  That's how my patch has been neglected for long time and 
just re-discovered from trashcan of rejected patches, thanks to this 
thread. ;-)

Now, back to my original question.  My point was, we should never 
trust any CPUIDs on emulated CPU if they are translated.  What should 
happen if you have four physical cores and you "assign" just one for 
VirtualBox, for example?  What should we "announce" if you are 
emulating two cores on UP host?  How do we know whether it is "the" 
real BSP or not?  Is it really bound to a CPU?  Is "CPUID leaf 11" 
emulated properly?  If not, is it an emulator bug or a guest OS bug?  
Do we really care about "physical topology" in these cases?  IMHO, 
the answer is no, we don't, and we should say "all cores are 
independent".  If anyone really cares and wants prettier printing, we 
may say "N virtual cores", though.

I hope it makes sense.

Jung-uk Kim

[1] I believe he referenced an older revision, though.

[2] It was committed as r191648:

http://svn.freebsd.org/viewvc/base?view=revision&revision=191648

Also, this commit is related to kern/145385:

http://www.freebsd.org/cgi/query-pr.cgi?pr=145385

[3] AMD is working on an SMT-capable CPU (code-named Bulldozer) and my 
patch won't work on them.  If anyone has a Bulldozer sample, please 
look into it.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.1-PRERELEASE: CPU packages not detected correctly

[Andriy Gapon]

on 19/08/2010 20:26 Jung-uk Kim said the following:
> One thing I am not sure is whether those CPUID instructions are 
> executed on *real* CPUs or translated in HVM.  On top of that, I am 
> not even sure they will be executed on *correct* cores.  I bet they 
> won't.

Hmm, I have an impression that we try to detect the topology by doing stuff only
on BSP and that's why we handle properly only uniform topologies.  So that would
make your point about correct cores moot.
Am I mistaken?

-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: cname replace in mail address? [off-topic] (Re: Attn Ronald Klop)

[Doug Barton]

On 08/27/2010 01:03 AM, Ronald Klop wrote:

offtopic, but why do some mailers replace a CNAME in a mail-address?

r...@sheeva2:/var/vmail# host klop.yi.org
klop.yi.org CNAME thuis.klop.ws
thuis.klop.ws A 212.123.145.58

It is not the first time that I'm bitten by this, but I never understood
it.


You've already received all the right answers but I figured I'd respond 
too since this is my area. Given that klop.yi.org is a CNAME, and that 
the target hostname (thuis.klop.ws) has no MX record, the fact that you 
receive any mail at all is a tribute to the robustness principle. :)


If you're going to receive mail at thuis.klop.ws then you should really 
have an MX record for it. See http://dougbarton.us/DNS/MX.html for more 
information if you need more information or references to the standards. 
The simplest way to solve your mail delivery problem is to have the 
@hostname refer to a canonical host (I.e., with an A and/or  record) 
which also has an MX record. If you insist on using klop.yi.org the 
_best_ way to do that would be to duplicate those 2 records from 
thuis.klop.ws. By adding an MX to thuis you are more likely to get mail 
if klop.yi.org is a CNAME to it, even though it's still not "right."



hth,

Doug

--

Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/

Computers are useless. They can only give you answers.
-- Pablo Picasso

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Crashes on X7SPE-HF with em

[Jack Vogel]

On Fri, Aug 27, 2010 at 6:04 AM, Philipp Wuensche wrote:

> Jack Vogel wrote:
> >
> >
> > On Thu, Aug 26, 2010 at 3:15 PM, Jeremy Chadwick
> > mailto:free...@jdc.parodius.com>> wrote:
> >
> > On Thu, Aug 26, 2010 at 11:56:48PM +0200, Philipp Wuensche wrote:
> > > Jeremy Chadwick wrote:
> > > >
> > > > CC'ing Jack Vogel of Intel and Yong-Hyeon PYUN who might have
> some
> > > > ideas.  OP's backtrace is here:
> > > >
> > > >
> >
> http://lists.freebsd.org/pipermail/freebsd-stable/2010-August/058425.html
> > > >
> > > > Philipp, can you please provide the following output?
> > > >
> > > > * dmesg | egrep 'em[0-9]'
> > >
> > > em0:  port
> > 0xdc00-0xdc1f mem
> > > 0xfe9e-0xfe9f,0xfe9dc000-0xfe9d irq 16 at device 0.0
> > on pci2
> > > em0: Using MSI interrupt
> > > em0: [FILTER]
> > > em0: Ethernet address: 00:25:90:04:6e:fa
> > > em1:  port
> > 0xec00-0xec1f mem
> > > 0xfeae-0xfeaf,0xfeadc000-0xfead irq 17 at device 0.0
> > on pci3
> > > em1: Using MSI interrupt
> > > em1: [FILTER]
> > > em1: Ethernet address: 00:25:90:04:6e:fb
> > >
> > > > * uname -a (you can XXX out the machine name if need be)
> > >
> > > FreeBSD XXX 8.1-STABLE FreeBSD 8.1-STABLE #2: Wed Aug 25 10:38:50
> CEST
> > > 2010 r...@xxx:/usr/obj/usr/src/sys/XXX  amd64
> > >
> > > Date of source is Aug 17 14:09 CEST 2010. It happend with
> 8.1-RELEASE
> > > too, I can go back to RELEASE or any SVN revision you would like,
> > if it
> > > is helping in any way.
> > >
> > > Kernel-config:
> > >
> > > include GENERIC
> > >
> > > ident   XXX
> > >
> > > options IPSEC
> > >
> > > options   DEVICE_POLLING
> > > options ACCEPT_FILTER_HTTP
> > >
> > > options ALTQ
> > >
> > > options ALTQ_CBQ
> > > options ALTQ_RED
> > > options ALTQ_RIO
> > > options ALTQ_HFSC
> > > options ALTQ_PRIQ
> > >
> > > devicecrypto
> > > deviceenc
> > >
> > >
> > > > * pciconf -lvc (only include the em(4) items please)
> > >
> > > e...@pci0:2:0:0:   class=0x02 card=0x060a15d9
> > chip=0x10d38086 rev=0x00
> > > hdr=0x00
> > > vendor = 'Intel Corporation'
> > > device = 'Intel 82574L Gigabit Ethernet Controller
> (82574L)'
> > > class  = network
> > > subclass   = ethernet
> > > cap 01[c8] = powerspec 2  supports D0 D3  current D0
> > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1
> message
> > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link
> x1(x1)
> > > cap 11[a0] = MSI-X supports 5 messages in map 0x1c
> > > e...@pci0:3:0:0:   class=0x02 card=0x060a15d9
> > chip=0x10d38086 rev=0x00
> > > hdr=0x00
> > > vendor = 'Intel Corporation'
> > > device = 'Intel 82574L Gigabit Ethernet Controller
> (82574L)'
> > > class  = network
> > > subclass   = ethernet
> > > cap 01[c8] = powerspec 2  supports D0 D3  current D0
> > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1
> message
> > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link
> x1(x1)
> > > cap 11[a0] = MSI-X supports 5 messages in map 0x1c
> > >
> > > > * vmstat -i
> > >
> > > interrupt  total   rate
> > > irq1: atkbd0   9  0
> > > cpu0: timer 36544552   1994
> > > irq256: em0 3801  0
> > > irq257: em1 32963909   1799
> > > irq258: ahci0 175662  9
> > > cpu1: timer 36543525   1994
> > > cpu2: timer 36543525   1994
> > > cpu3: timer 36543525   1994
> > > Total  179318508   9786
> > >
> > > There is an shared IPMI interface on em0, but the interface is not
> > used
> > > by FreeBSD. em1 is used by four VLANs. Polling is only in the
> > > Kernelconfig, not activated on the devices.
> >
> > So much complexity here.  Tracking this down might be difficult.
> >
> > One thing that does concern me is the interrupt rate for em1.  Jack
> et
> > al, is this normal?  I don't see this behaviour on my 8.x systems
> with
> > em(4) driver 7.0.5, but my systems all use 82573E and 82573L, and
> don't
> > have MSI-X support.
> >
> >
> > He is only using one vector anyway it seems, so MSIX isnt making things
> > much more complex than your 573.
> >
> > The interrupt rate seems high but I'm not sure if its abnormal for a busy
> > interface.
> >
> > I tend to agree with Yongari, let's eliminate all the complicating

Re: NFS uid/gid mapping

[Rick Macklem]

> hi,
> 
> I can't seem to find how to manually remap uid & gid information while
> using NFS, e.g. something similar to this:
> 
> http://www.kernelcrash.com/blog/nfs-uidgid-mapping/2007/09/10/
> 
> Is such mapping really unimplemented?
> 
Except for root or all uids, no. There is no generic mapping
facility.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: cname replace in mail address? [off-topic] (Re: Attn Ronald Klop)

[Peter C. Lai]

Does the recipient MTA actually receive for both klop.yi.org *and*
thuis.klop.ws? The recipient MTA will dereference the CNAME and rewrite the
envelope for the reason that it can only relay to an RR that points to a 
real host.

You might be able to fix it if you configure the mta on thuis.klop.ws to 
accept mail for the thuis.klop.ws domain in addition to klop.yi.org (which I 
assume is how you have it setup).

In a situation like this if you have domain CNAME originaldomain then
you better make sure that someone can send to either 
@domain AND @originaldomain otherwise it doesn't make sense.

On 2010-08-27 10:03:52AM +0200, Ronald Klop wrote:
> offtopic, but why do some mailers replace a CNAME in a mail-address?
> 
> r...@sheeva2:/var/vmail# host klop.yi.org
> klop.yi.org CNAME   thuis.klop.ws
> thuis.klop.ws   A   212.123.145.58
> 
> It is not the first time that I'm bitten by this, but I never understood  
> it.
> 
> Ronald.
> 
> On Tue, 24 Aug 2010 22:05:46 +0200, Andriy Gapon  wrote:
> 
> >
> > Ronald,
> >
> > your email address bounces, that's inconvenient.
> >
> >
> >  Original Message 
> > Subject: Returned mail: Service unavailable
> > Date: Tue, 24 Aug 2010 23:03:33 +0300 (EEST)
> > From: Mail Delivery Subsystem 
> > To: 
> >
> > The original message was received at Tue, 24 Aug 2010 23:03:27 +0300  
> > (EEST)
> > from porto-e.starpoint.kiev.ua [212.40.38.100]
> >
> >- The following addresses had permanent fatal errors -
> > 
> >
> >- Transcript of session follows -
> > ... while talking to thuis.klop.ws.:
>  RCPT To:
> > <<< 554 5.7.1 : Relay access denied
> > 554 ... Service unavailable
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

-- 
===
Peter C. Lai | Bard College at Simon's Rock
Systems Administrator| 84 Alford Rd.
Information Technology Svcs. | Gt. Barrington, MA 01230 USA
peter AT simons-rock.edu | (413) 528-7428
===

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Crashes on X7SPE-HF with em

[Philipp Wuensche]

Jack Vogel wrote:
> 
> 
> On Thu, Aug 26, 2010 at 3:15 PM, Jeremy Chadwick
> mailto:free...@jdc.parodius.com>> wrote:
> 
> On Thu, Aug 26, 2010 at 11:56:48PM +0200, Philipp Wuensche wrote:
> > Jeremy Chadwick wrote:
> > >
> > > CC'ing Jack Vogel of Intel and Yong-Hyeon PYUN who might have some
> > > ideas.  OP's backtrace is here:
> > >
> > >
> http://lists.freebsd.org/pipermail/freebsd-stable/2010-August/058425.html
> > >
> > > Philipp, can you please provide the following output?
> > >
> > > * dmesg | egrep 'em[0-9]'
> >
> > em0:  port
> 0xdc00-0xdc1f mem
> > 0xfe9e-0xfe9f,0xfe9dc000-0xfe9d irq 16 at device 0.0
> on pci2
> > em0: Using MSI interrupt
> > em0: [FILTER]
> > em0: Ethernet address: 00:25:90:04:6e:fa
> > em1:  port
> 0xec00-0xec1f mem
> > 0xfeae-0xfeaf,0xfeadc000-0xfead irq 17 at device 0.0
> on pci3
> > em1: Using MSI interrupt
> > em1: [FILTER]
> > em1: Ethernet address: 00:25:90:04:6e:fb
> >
> > > * uname -a (you can XXX out the machine name if need be)
> >
> > FreeBSD XXX 8.1-STABLE FreeBSD 8.1-STABLE #2: Wed Aug 25 10:38:50 CEST
> > 2010 r...@xxx:/usr/obj/usr/src/sys/XXX  amd64
> >
> > Date of source is Aug 17 14:09 CEST 2010. It happend with 8.1-RELEASE
> > too, I can go back to RELEASE or any SVN revision you would like,
> if it
> > is helping in any way.
> >
> > Kernel-config:
> >
> > include GENERIC
> >
> > ident   XXX
> >
> > options IPSEC
> >
> > options   DEVICE_POLLING
> > options ACCEPT_FILTER_HTTP
> >
> > options ALTQ
> >
> > options ALTQ_CBQ
> > options ALTQ_RED
> > options ALTQ_RIO
> > options ALTQ_HFSC
> > options ALTQ_PRIQ
> >
> > devicecrypto
> > deviceenc
> >
> >
> > > * pciconf -lvc (only include the em(4) items please)
> >
> > e...@pci0:2:0:0:   class=0x02 card=0x060a15d9
> chip=0x10d38086 rev=0x00
> > hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)'
> > class  = network
> > subclass   = ethernet
> > cap 01[c8] = powerspec 2  supports D0 D3  current D0
> > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
> > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
> > cap 11[a0] = MSI-X supports 5 messages in map 0x1c
> > e...@pci0:3:0:0:   class=0x02 card=0x060a15d9
> chip=0x10d38086 rev=0x00
> > hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)'
> > class  = network
> > subclass   = ethernet
> > cap 01[c8] = powerspec 2  supports D0 D3  current D0
> > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
> > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
> > cap 11[a0] = MSI-X supports 5 messages in map 0x1c
> >
> > > * vmstat -i
> >
> > interrupt  total   rate
> > irq1: atkbd0   9  0
> > cpu0: timer 36544552   1994
> > irq256: em0 3801  0
> > irq257: em1 32963909   1799
> > irq258: ahci0 175662  9
> > cpu1: timer 36543525   1994
> > cpu2: timer 36543525   1994
> > cpu3: timer 36543525   1994
> > Total  179318508   9786
> >
> > There is an shared IPMI interface on em0, but the interface is not
> used
> > by FreeBSD. em1 is used by four VLANs. Polling is only in the
> > Kernelconfig, not activated on the devices.
> 
> So much complexity here.  Tracking this down might be difficult.
> 
> One thing that does concern me is the interrupt rate for em1.  Jack et
> al, is this normal?  I don't see this behaviour on my 8.x systems with
> em(4) driver 7.0.5, but my systems all use 82573E and 82573L, and don't
> have MSI-X support.
> 
> 
> He is only using one vector anyway it seems, so MSIX isnt making things
> much more complex than your 573.
> 
> The interrupt rate seems high but I'm not sure if its abnormal for a busy
> interface.
> 
> I tend to agree with Yongari, let's eliminate all the complicating factors
> like IPSEC and ALTQ and see if it still occurs.

Crashed couply of minutes ago, the kernel without ALTQ and IPSEC is now
running.

greetings,
philipp
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe,

Re: cname replace in mail address? [off-topic] (Re: Attn Ronald Klop)

[Matthias Andree]

Am 27.08.2010 11:22, schrieb Ronald Klop:
> Mandatory? I'm googling, but can't find a document that declares it  
> mandatory and only sendmail seems to do it.
> I think it is lame to use DNS info to rewrite e-mail addresses, but the  
> person who made it 'mandatory' will have good reasons for it.

May have been RFC0974, perhaps in connection with others - January 1986...

-- 
Matthias Andree
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: cname replace in mail address? [off-topic] (Re: Attn Ronald Klop)

[Pete French]

> Mandatory? I'm googling, but can't find a document that declares it  
> mandatory and only sendmail seems to do it.
> I think it is lame to use DNS info to rewrite e-mail addresses, but the  
> person who made it 'mandatory' will have good reasons for it.

Rewiting may not be mandatory, but it is certainly true that a domain
needs to have either an A record or an MX record to recieve email
according to the spec. Your has neither, and given the presence of
a CNAME then rewriting the address to use that CNAME doesnt seem like
an unreasonable thing to do.

You should add an MX record to that domain - but mixing MX and CNAME
is a fairly bad idea too (and that should be easily found in google).

-pete.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: cname replace in mail address? [off-topic] (Re: Attn Ronald Klop)

[Jeremy Chadwick]

On Fri, Aug 27, 2010 at 11:22:05AM +0200, Ronald Klop wrote:
> Mandatory? I'm googling, but can't find a document that declares it
> mandatory and only sendmail seems to do it.
> I think it is lame to use DNS info to rewrite e-mail addresses, but
> the person who made it 'mandatory' will have good reasons for it.
> 
> Does somebody have a pointer to the specs about this?

First hit on Google:

http://www.ferris.com/2008/09/08/why-you-shouldnt-mix-cname-and-mx/

Bottom line: don't use CNAMEs, ever, unless you know ***exactly*** what
you're doing.  It's been like this for a very long time.

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: cname replace in mail address? [off-topic] (Re: Attn Ronald Klop)

[Ronald Klop]

Mandatory? I'm googling, but can't find a document that declares it  
mandatory and only sendmail seems to do it.
I think it is lame to use DNS info to rewrite e-mail addresses, but the  
person who made it 'mandatory' will have good reasons for it.


Does somebody have a pointer to the specs about this?

Ronald.

On Fri, 27 Aug 2010 10:21:27 +0200, Mark Andrews  wrote:



In message , "Ronald  
Klop" writ

es:

offtopic, but why do some mailers replace a CNAME in a mail-address?


Because it used to be manditory to do so.  If you don't want it to
be done use a MX record.

klop.yi.org MX 0 thuis.klop.ws

If you need klop.yi.org to have a address record then give it one.

klop.yi.org A 212.123.145.58

Mark


r...@sheeva2:/var/vmail# host klop.yi.org
klop.yi.org CNAME   thuis.klop.ws
thuis.klop.ws   A   212.123.145.58

It is not the first time that I'm bitten by this, but I never  
understood =

=20
it.

Ronald.

On Tue, 24 Aug 2010 22:05:46 +0200, Andriy Gapon   
wrote:


>
> Ronald,
>
> your email address bounces, that's inconvenient.
>
>
>  Original Message 
> Subject: Returned mail: Service unavailable
> Date: Tue, 24 Aug 2010 23:03:33 +0300 (EEST)
> From: Mail Delivery Subsystem 
> To: 
>
> The original message was received at Tue, 24 Aug 2010 23:03:27 +0300  
=20

> (EEST)
> from porto-e.starpoint.kiev.ua [212.40.38.100]
>
>- The following addresses had permanent fatal errors -
> 
>
>- Transcript of session follows -
> ... while talking to thuis.klop.ws.:
 RCPT To:
> <<< 554 5.7.1 : Relay access denied
> 554 ... Service unavailable
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to  
"freebsd-stable-unsubscr...@freebsd.org"

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: cname replace in mail address? [off-topic] (Re: Attn Ronald Klop)

[Mark Andrews]

In message , "Ronald Klop" writ
es:
> offtopic, but why do some mailers replace a CNAME in a mail-address?

Because it used to be manditory to do so.  If you don't want it to
be done use a MX record.

klop.yi.org MX 0 thuis.klop.ws

If you need klop.yi.org to have a address record then give it one.

klop.yi.org A 212.123.145.58

Mark

> r...@sheeva2:/var/vmail# host klop.yi.org
> klop.yi.org CNAME   thuis.klop.ws
> thuis.klop.ws   A   212.123.145.58
> 
> It is not the first time that I'm bitten by this, but I never understood =
> =20
> it.
> 
> Ronald.
> 
> On Tue, 24 Aug 2010 22:05:46 +0200, Andriy Gapon  wrote:
> 
> >
> > Ronald,
> >
> > your email address bounces, that's inconvenient.
> >
> >
> >  Original Message 
> > Subject: Returned mail: Service unavailable
> > Date: Tue, 24 Aug 2010 23:03:33 +0300 (EEST)
> > From: Mail Delivery Subsystem 
> > To: 
> >
> > The original message was received at Tue, 24 Aug 2010 23:03:27 +0300 =20
> > (EEST)
> > from porto-e.starpoint.kiev.ua [212.40.38.100]
> >
> >- The following addresses had permanent fatal errors -
> > 
> >
> >- Transcript of session follows -
> > ... while talking to thuis.klop.ws.:
>  RCPT To:
> > <<< 554 5.7.1 : Relay access denied
> > 554 ... Service unavailable
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

cname replace in mail address? [off-topic] (Re: Attn Ronald Klop)

[Ronald Klop]

offtopic, but why do some mailers replace a CNAME in a mail-address?

r...@sheeva2:/var/vmail# host klop.yi.org
klop.yi.org CNAME   thuis.klop.ws
thuis.klop.ws   A   212.123.145.58

It is not the first time that I'm bitten by this, but I never understood  
it.


Ronald.

On Tue, 24 Aug 2010 22:05:46 +0200, Andriy Gapon  wrote:



Ronald,

your email address bounces, that's inconvenient.


 Original Message 
Subject: Returned mail: Service unavailable
Date: Tue, 24 Aug 2010 23:03:33 +0300 (EEST)
From: Mail Delivery Subsystem 
To: 

The original message was received at Tue, 24 Aug 2010 23:03:27 +0300  
(EEST)

from porto-e.starpoint.kiev.ua [212.40.38.100]

   - The following addresses had permanent fatal errors -


   - Transcript of session follows -
... while talking to thuis.klop.ws.:

RCPT To:

<<< 554 5.7.1 : Relay access denied
554 ... Service unavailable

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: wpa_supplicant does not create pidfile

[Bernhard Schmidt]

On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey  wrote:
> wpa_supplicant doesn't create the pidfile if the target directory
> does not exist. Because /var/run is wiped with every boot I added
> the following line to my rc.local to workaround this issue:
>
> /bin/mkdir -p /var/run/wpa_supplicant
>
> I'm running RELENG_8.

How about this?

Index: etc/mtree/BSD.var.dist
===
--- etc/mtree/BSD.var.dist>.(revision 211568)
+++ etc/mtree/BSD.var.dist>.(working copy)
@@ -64,6 +64,8 @@
 ..
 ppp gname=network mode=0770
 ..
+wpa_supplicant
+..
 ..
 rwhogname=daemon mode=0775
 ..


-- 
Bernhard
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: wpa_supplicant does not create pidfile

[Bernhard Schmidt]

On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey  wrote:
> On 27/08/2010 09:28, Bernhard Schmidt wrote:
>> On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey  wrote:
>>> wpa_supplicant doesn't create the pidfile if the target directory
>>> does not exist. Because /var/run is wiped with every boot I added
>>> the following line to my rc.local to workaround this issue:
>>>
>>> /bin/mkdir -p /var/run/wpa_supplicant
>>>
>>> I'm running RELENG_8.
>>
>> How about this?
>>
>> Index: etc/mtree/BSD.var.dist
>> ===
>> --- etc/mtree/BSD.var.dist>.(revision 211568)
>> +++ etc/mtree/BSD.var.dist>.(working copy)
>> @@ -64,6 +64,8 @@
>>          ..
>>          ppp             gname=network mode=0770
>>          ..
>> +        wpa_supplicant
>> +        ..
>>      ..
>>      rwho            gname=daemon mode=0775
>>      ..
>
> Is the mtree built every time the system boots? Because my /var/run
> is a tmpfs. And even if it wasn't, I think it's wiped every boot
> any way.

Not build but, according to /etc/rc.d/var mtree is run on every boot.
I actually tried that and it works just fine.

-- 
Bernhard
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: wpa_supplicant does not create pidfile

[Dominic Fandrey]

On 27/08/2010 09:28, Bernhard Schmidt wrote:
> On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey  wrote:
>> wpa_supplicant doesn't create the pidfile if the target directory
>> does not exist. Because /var/run is wiped with every boot I added
>> the following line to my rc.local to workaround this issue:
>>
>> /bin/mkdir -p /var/run/wpa_supplicant
>>
>> I'm running RELENG_8.
> 
> How about this?
> 
> Index: etc/mtree/BSD.var.dist
> ===
> --- etc/mtree/BSD.var.dist>.(revision 211568)
> +++ etc/mtree/BSD.var.dist>.(working copy)
> @@ -64,6 +64,8 @@
>  ..
>  ppp gname=network mode=0770
>  ..
> +wpa_supplicant
> +..
>  ..
>  rwhogname=daemon mode=0775
>  ..

Is the mtree built every time the system boots? Because my /var/run
is a tmpfs. And even if it wasn't, I think it's wiped every boot
any way.

Regards

-- 
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail? 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"