Re: How's 11.0-RELEASE coming?

[Glen Barber]

On Fri, Sep 09, 2016 at 10:08:50AM -0400, Shawn Webb wrote:
> Hey Glen,
> 
> I'm just checking in to see if you saw this bug report I filed:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212418
> 
> It affects 11.0-RC2.
> 

Sorry for the delayed reply.  No, I did not.

Superficially, it looks like an EN candidate, I believe.

Glen



signature.asc
Description: PGP signature

Re: X2APIC support

[Slawa Olhovchenkov]

On Mon, Sep 12, 2016 at 08:05:33PM +0300, Andriy Gapon wrote:

> On 12/09/2016 19:44, Slawa Olhovchenkov wrote:
> > I am not kernel developer: please point what I am need insert and file
> > for edit.
> 
> In sys/amd64/amd64/mp_machdep.c (assuming you use amd64), in function
> cpu_mp_start, in this place
>   /* Set boot_cpu_id if needed. */
>   if (boot_cpu_id == -1) {
>   boot_cpu_id = PCPU_GET(apic_id);
>   cpu_info[boot_cpu_id].cpu_bsp = 1;
>   } else
> 
> right after boot_cpu_id = PCPU_GET(apic_id) line please insert
>   printf("boot_cpu_id = %d\n", boot_cpu_id);

VT(vga): text 80x25
CPU: Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz (2200.05-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x406f1  Family=0x6  Model=0x4f  Stepping=1
  
Features=0xbfebfbff
  
Features2=0x7ffefbff
  AMD Features=0x2c100800
  AMD Features2=0x121
  Structured Extended 
Features=0x21cbfbb
  XSAVE Features=0x1
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr
  TSC: P-state invariant, performance statistics
real memory  = 137438953472 (131072 MB)
avail memory = 133407973376 (127227 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
boot_cpu_id = 255
kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = ff
fault virtual address   = 0x0
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80537e74
stack pointer   = 0x28:0x814b3a60
frame pointer   = 0x28:0x814b3a70
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 0 ()
trap number = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
#0 0x805272e7 at kdb_backtrace+0x67
#1 0x804dd662 at vpanic+0x182
#2 0x804dd4d3 at panic+0x43
#3 0x807a37a1 at trap_fatal+0x351
#4 0x807a3993 at trap_pfault+0x1e3
#5 0x807a2f1c at trap+0x26c
#6 0x80787ca1 at calltrap+0x8
#7 0x8083b53a at topo_probe+0x61a
#8 0x8078fe93 at cpu_mp_start+0x1c3
#9 0x805382ca at mp_start+0x3a
#10 0x80465cd8 at mi_startup+0x118
#11 0x8028dfac at btext+0x2c
Uptime: 1s
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: X2APIC support

[Andriy Gapon]

On 12/09/2016 19:44, Slawa Olhovchenkov wrote:
> I am not kernel developer: please point what I am need insert and file
> for edit.

In sys/amd64/amd64/mp_machdep.c (assuming you use amd64), in function
cpu_mp_start, in this place
/* Set boot_cpu_id if needed. */
if (boot_cpu_id == -1) {
boot_cpu_id = PCPU_GET(apic_id);
cpu_info[boot_cpu_id].cpu_bsp = 1;
} else

right after boot_cpu_id = PCPU_GET(apic_id) line please insert
printf("boot_cpu_id = %d\n", boot_cpu_id);

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

Re: X2APIC support

[Slawa Olhovchenkov]

On Mon, Sep 12, 2016 at 04:44:09PM +0300, Andriy Gapon wrote:

> On 12/09/2016 12:39, Slawa Olhovchenkov wrote:
> > On Sun, Sep 04, 2016 at 08:14:07PM +0300, Andriy Gapon wrote:
> > 
> >> On 04/09/2016 19:29, Konstantin Belousov wrote:
> >>> This is possible, of course.  But it would not affect "SMP: Added CPU ..."
> >>> lines.
> >>
> >> Well, looking at the code it seems that only if mptable is used, then those
> >> lines are expected to correctly identify a BSP.  With MADT there is no
> >> information to identify the BSP and that is supposed to happen in 
> >> cpu_mp_start().
> >>
> >>
> >> static void
> >> madt_add_cpu(u_int acpi_id, u_int apic_id, u_int flags)
> >> {
> >> struct lapic_info *la;
> >>
> >> /*
> >>  * The MADT does not include a BSP flag, so we have to let the
> >>  * MP code figure out which CPU is the BSP on its own.
> >>  */
> >> ...
> >>
> >> In other words, those "SMP: Added CPU ..." are truly a cosmetic issue.
> >> And it's my guess (just a guess) that BSP LAPIC ID is incorrect in the
> >> problematic configuration.
> > 
> > For next day or two I am have new server with same hardware before put
> > in prodution.
> > Can I do some test for you?
> > 
> 
> >From my earlier email:
> "my guess can be checked by adding a printf to cpu_mp_start() right after
> boot_cpu_id assignment".

I am not kernel developer: please point what I am need insert and file
for edit.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Intel NVMe troubles?

[Jim Harris]

On Mon, Aug 1, 2016 at 11:49 AM, Jim Harris  wrote:

>
>
> On Mon, Aug 1, 2016 at 7:38 AM, Borja Marcos  wrote:
>
>>
>> >
>> > It looks like all of the TRIM commands are formatted properly.  The
>> failures do not happen until about 10 seconds after the last TRIM to each
>> drive was submitted, and immediately before TRIMs start to the next drive,
>> so I'm assuming the failures are for the the last few TRIM commands but
>> cannot say for sure.  Could you apply patch v2 (attached) which will dump
>> the TRIM payload contents inline with the failure messages?
>>
>> Sure, this is the complete /var/log/messages starting with the system
>> boot. Before booting I destroyed the pool
>> so that you could capture what happens when booting, zpool create, etc.
>>
>> Remember that the drives are in LBA format #3 (4 KB blocks). As far as I
>> know that’s preferred to the old 512 byte blocks.
>>
>> Thank you very much and sorry about the belated response.
>
>
> Hi Borja,
>
> Thanks for the additional testing.  This has all of the detail that I need
> for now.
>
> -Jim
>
>
>
There is an updated DCT 3.0.2 at:  https://downloadcenter.intel.
com/download/26221/Intel-SSD-Data-Center-Tool which has a fix for this
issue.

Borja has already downloaded this update and confirmed it looks good so
far.  Posting the update and results here so it is archived on the STABLE
mailing list.

Thanks,

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

Re: X2APIC support

[Andriy Gapon]

On 12/09/2016 12:39, Slawa Olhovchenkov wrote:
> On Sun, Sep 04, 2016 at 08:14:07PM +0300, Andriy Gapon wrote:
> 
>> On 04/09/2016 19:29, Konstantin Belousov wrote:
>>> This is possible, of course.  But it would not affect "SMP: Added CPU ..."
>>> lines.
>>
>> Well, looking at the code it seems that only if mptable is used, then those
>> lines are expected to correctly identify a BSP.  With MADT there is no
>> information to identify the BSP and that is supposed to happen in 
>> cpu_mp_start().
>>
>>
>> static void
>> madt_add_cpu(u_int acpi_id, u_int apic_id, u_int flags)
>> {
>> struct lapic_info *la;
>>
>> /*
>>  * The MADT does not include a BSP flag, so we have to let the
>>  * MP code figure out which CPU is the BSP on its own.
>>  */
>> ...
>>
>> In other words, those "SMP: Added CPU ..." are truly a cosmetic issue.
>> And it's my guess (just a guess) that BSP LAPIC ID is incorrect in the
>> problematic configuration.
> 
> For next day or two I am have new server with same hardware before put
> in prodution.
> Can I do some test for you?
> 

>From my earlier email:
"my guess can be checked by adding a printf to cpu_mp_start() right after
boot_cpu_id assignment".

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

Re: X2APIC support

[Slawa Olhovchenkov]

On Sun, Sep 04, 2016 at 08:14:07PM +0300, Andriy Gapon wrote:

> On 04/09/2016 19:29, Konstantin Belousov wrote:
> > This is possible, of course.  But it would not affect "SMP: Added CPU ..."
> > lines.
> 
> Well, looking at the code it seems that only if mptable is used, then those
> lines are expected to correctly identify a BSP.  With MADT there is no
> information to identify the BSP and that is supposed to happen in 
> cpu_mp_start().
> 
> 
> static void
> madt_add_cpu(u_int acpi_id, u_int apic_id, u_int flags)
> {
> struct lapic_info *la;
> 
> /*
>  * The MADT does not include a BSP flag, so we have to let the
>  * MP code figure out which CPU is the BSP on its own.
>  */
> ...
> 
> In other words, those "SMP: Added CPU ..." are truly a cosmetic issue.
> And it's my guess (just a guess) that BSP LAPIC ID is incorrect in the
> problematic configuration.

For next day or two I am have new server with same hardware before put
in prodution.
Can I do some test for you?
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"