Re: AMD CPU/APU temperature driver

2017-03-07 Thread Rozhuk Ivan 
On Mon, 6 Mar 2017 13:23:40 +0100
Olivier Cochard-Labbé  wrote:

> > New amdtemp driver needs more testers!
> > https://reviews.freebsd.org/D9759
> ​
> This patch apply correctly (on 12-head r314770), but a "make
> buildkernel" failed with
> 
> ​--- all_subdir_amdtemp ---
> /usr/src/sys/modules/amdtemp/../../dev/amdtemp/amdtemp.c:1083:54:
> error: too few arguments to function call, expected 11, have 10
> regs[i].oid_handler, regs[i].fmt, regs[i].descr);
>^

Try now with last version of patch.

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

Re: AMD CPU/APU temperature driver

2017-03-07 Thread Rozhuk Ivan 
On Mon, 6 Mar 2017 10:04:06 +0100
Matthias Apitz  wrote:

> > rus/eng: http://netlab.dhis.org/wiki/ru:software:freebsd:amdtemp  
> 
> The English version of the Wiki gives only: This topic does not exist
> yet. Is there an English version?
> 

Sory, now avaible.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Boot failure - svn up from this morning

2017-03-07 Thread Jonathan Anderson 

On 7 Mar 2017, at 16:50, Chris H wrote:

On Tue, 07 Mar 2017 16:27:59 -0330 "Jonathan Anderson" 


wrote


Hi,

On 5 Mar 2017, at 20:31, Chris H wrote:


OK copying the boot.efi from the install DVD will only
hose the system (EFI).


Before I attempt to do the same thing... what do you mean by "hose 
the

system"? Is the correct recovery path to build a new USB image with
"make release" post-r314828?

That was *my* bad. I inadvertently copied the *wrong* file
(I was in a hurry).
So. That said; if you move loader.efi aside -- say; to
_loader.efi.
Then copy loader.efi from the install DVD, or any other
system that's not too much older, and is good. You should
be fine. :-)
Make sure the permissions are correct, after the copy.

Sorry for the misinformation.


Thanks for the clarification! I am back up and running now.

Cheers,


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

RE: input/output error @boot

2017-03-07 Thread Dexuan Cui 
Hi guys,
Sorry, I had to commit a new patch (r314891) just now to really fix the 
off-by-one bug.
Thank Alex for reporting the issue in my previous patch (r314828).

Hope this issue is finally fixed this time! :-)

Thanks,
-- Dexuan

From: Roberto Rodriguez Jr [mailto:rob.rodz@gmail.com]
Sent: Tuesday, March 7, 2017 21:27
To: Dexuan Cui 
Cc: FreeBSD Current 
Subject: RE: input/output error @boot

I will test tonight. Thank you very much for your time

On Mar 6, 2017 11:52 PM, "Dexuan Cui" 
> wrote:
> From: Dexuan Cui
> I committed r314770 just now to minimize the impact:
> https://svnweb.freebsd.org/base?view=revision=314770
>
> Please let me know in case this can't solve the issue.
Sorry, r314770  has a bug, so I had to commit r314828:
https://svnweb.freebsd.org/base?view=revision=314828

Please make sure you use the latest code, i.e. >= r314828.

Thanks,
-- Dexuan

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

RE: Boot failure - svn up from this morning

2017-03-07 Thread Dexuan Cui 
> From: Alex Deiter [mailto:alex.dei...@gmail.com]
> Hello Dexuan,
> This issue reproduced at least for 4 different HW platform
> How can I help you resolve this issue ?
> 
> The same result for r314862:

Hi guys,
Sorry, I had to commit a new patch (r314891) just now to really fix
the off-by-one bug.
Thank Alex for reporting the issue in my previous patch (r314828).

Hope this issue is finally fixed this time! :-)

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

RE: Boot failure - svn up from this morning

2017-03-07 Thread Dexuan Cui 
> From: Alex Deiter [mailto:alex.dei...@gmail.com]
> Sent: Wednesday, March 8, 2017 09:39
> To: Dexuan Cui ; freebsd-current  curr...@freebsd.org>
> Cc: Chris H ; AN ; Ngie Cooper
> (yaneurabeya) ; Michael Tuexen
> ; Roberto Rodriguez Jr ; Guido
> Falsi ; Warner Losh ; Ultima
> ; Sepherosa Ziehau 
> Subject: Re: Boot failure - svn up from this morning
> 
> Hello Dexuan,
> 
> This issue reproduced at least for 4 different HW platform:
> 
> Supermicro 6037R-TXRF
> Supermicro A1SRM-2758F
> Supermicro X9SCM-F
> Gigabyte GA-C1037UN-EU
> 
> How can I help you resolve this issue ?
> 
> Thank you!
> 
> The same result for r314862:

Weird... :-(
I'm looking at the code again. Will report back soon.

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

Call for 2017Q1 quarterly status reports

2017-03-07 Thread Benjamin Kaduk 
Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is April 7,
2017, for work done in January through March.

Status report submissions do not need to be very long.  They may be about
anything happening in the FreeBSD project and community, and provide a great
way to inform FreeBSD users and developers about work that is underway and
completed.  Submission of reports is not restricted to committers; anyone
doing anything interesting and FreeBSD related can -- and should -- write one!

The preferred and easiest submission method is to use the XML generator [1]
with the results emailed to the status report team at mont...@freebsd.org .
(Do be sure, though, to save the form output and not the form itself!)  There
is also an XML template [2] that can be filled out manually and attached
if preferred.  For the expected content and style, please study our guidelines
on how to write a good status report [3].  You can also review previous issues
[4][5] for ideas on the style and format.

We look forward to seeing your 2016Q4 reports!

Thanks,

Ben (on behalf of monthly@)

[1] https://www.FreeBSD.org/cgi/monthly.cgi
[2] https://www.FreeBSD.org/news/status/report-sample.xml
[3] https://www.FreeBSD.org/news/status/howto.html
[4] https://www.FreeBSD.org/news/status/report-2016-07-2016-09.html
[5] https://www.FreeBSD.org/news/status/report-2016-10-2016-12.html

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

Re: Boot failure - svn up from this morning

2017-03-07 Thread Alex Deiter 
Hello Dexuan,

This issue reproduced at least for 4 different HW platform:

Supermicro 6037R-TXRF
Supermicro A1SRM-2758F
Supermicro X9SCM-F
Gigabyte GA-C1037UN-EU

How can I help you resolve this issue ?

Thank you! 

The same result for r314862:

>> FreeBSD EFI boot block
  Loader path: /boot/loader.efi

  Initializing modules: ZFS UFS
  Probing 16 block devices..*.+.. done
   ZFS found the following pools: zroot
   UFS found no partitions
Consoles: EFI console  
Staging area's size is reduced: 16384 -> 64!
Command line arguments: loader.efi
Image base: 0x6dc65000
EFI version: 2.31
EFI Firmware: American Megatrends (rev 5.08)

FreeBSD/amd64 EFI loader, Revision 1.1
EFI boot environment
Loading /boot/defaults/loader.conf
/boot/kernel/kernel text=0x9210f8 
elf64_loadimage: read failed
can't load file '/boot/kernel/kernel': input/output error
can't load file '/boot/kernel/kernel': input/output error

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel] in 2 seconds... 

Type '?' for a list of commands, 'help' for more detailed help.
OK  
OK  memmap
  Type Physical  Virtual   #Pages Attr
  BootServicesCode   0008 UC WC WT WB 
ConventionalMemory 8000  0027 UC WC WT WB 
  BootServicesData 0002f000  0011 UC WC WT WB 
  BootServicesCode 0004  0060 UC WC WT WB 
ConventionalMemory 0010  0100 UC WC WT WB 
  BootServicesData 0020  0040 UC WC WT WB 
ConventionalMemory 0024  0003fd80 UC WC WT WB 
LoaderData 3ffc  0040 UC WC WT WB 
ConventionalMemory 4000  00029c65 UC WC WT WB 
LoaderData 69c65000  4000 UC WC WT WB 
LoaderCode 6dc65000  0071 UC WC WT WB 
LoaderData 6dcd6000  2171 UC WC WT WB 
LoaderCode 6fe47000  001d UC WC WT WB 
MemoryMappedIO 6fe64000  0014 UC WC WT WB 
  BootServicesData 6fe78000  ec32 UC WC WT WB 
ConventionalMemory 7eaaa000  037b UC WC WT WB 
  BootServicesCode 7ee25000  0285 UC WC WT WB 
  Reserved 7f0aa000  0075 UC WC WT WB 
ConventionalMemory 7f11f000  00ae UC WC WT WB 
 ACPIMemoryNVS 7f1cd000  027b UC WC WT WB 
   RuntimeServicesData 7f448000  01a7 UC WC WT WB 
   RuntimeServicesCode 7f5ef000  005c UC WC WT WB 
  BootServicesData 7f64b000  01b5 UC WC WT WB 
ConventionalMemory 0001  0078 UC WC WT WB 
MemoryMappedIO e000  4000 UC 
MemoryMappedIO fed01000  0003 UC 
MemoryMappedIO fed08000  0001 UC 
MemoryMappedIO fed0c000  0004 UC 
MemoryMappedIO fed1c000  0001 UC 
MemoryMappedIO fef0  1100 UC 
OK 


Thank you!


Alex Deiter
alex.dei...@gmail.com



> On 7 Mar 2017, at 06:45, Dexuan Cui  wrote:
> 
>> From: Dexuan Cui
>> Sent: Tuesday, March 7, 2017 11:18
>> To: 'Alex Deiter' 
>> Cc: Chris H ; AN ; Ngie Cooper
>> (yaneurabeya) ; Michael Tuexen
>> ; Roberto Rodriguez Jr ; Guido
>> Falsi ; Warner Losh ; Ultima
>> ; Sepherosa Ziehau 
>> Subject: RE: Boot failure - svn up from this morning
>> 
>>> From: Alex Deiter [mailto:alex.dei...@gmail.com]
>>> Sent: Tuesday, March 7, 2017 11:04
>>> To: Dexuan Cui 
>> 
>> 
>> Hi Alex,
>> Thanks very much for the quick reply!
>> 
>> I found an off-by-one bug in my patch and here is the fix.
>> I'll commit it shortly.
> 
> Hi Alex,
> I committed Revision 314828 for this:
> https://svnweb.freebsd.org/base?view=revision=314828
> 
> I believe it should fix the issue for you now. :-)
> 
> Thanks,
> -- Dexuan

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

Re: Boot failure - svn up from this morning

2017-03-07 Thread Chris H 
On Tue, 07 Mar 2017 16:27:59 -0330 "Jonathan Anderson" 
wrote

> Hi,
> 
> On 5 Mar 2017, at 20:31, Chris H wrote:
> 
> > OK copying the boot.efi from the install DVD will only
> > hose the system (EFI).
> 
> Before I attempt to do the same thing... what do you mean by "hose the 
> system"? Is the correct recovery path to build a new USB image with 
> "make release" post-r314828?
That was *my* bad. I inadvertently copied the *wrong* file
(I was in a hurry).
So. That said; if you move loader.efi aside -- say; to
_loader.efi.
Then copy loader.efi from the install DVD, or any other
system that's not too much older, and is good. You should
be fine. :-)
Make sure the permissions are correct, after the copy.

Sorry for the misinformation.

--Chris
> 
> Thanks,
> 
> 
> Jon
> --
> jonat...@freebsd.org


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

Re: Boot failure - svn up from this morning

2017-03-07 Thread Jonathan Anderson 

Hi,

On 5 Mar 2017, at 20:31, Chris H wrote:


OK copying the boot.efi from the install DVD will only
hose the system (EFI).


Before I attempt to do the same thing... what do you mean by "hose the 
system"? Is the correct recovery path to build a new USB image with 
"make release" post-r314828?


Thanks,


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

Re: two recent snapshot installer problems

2017-03-07 Thread Toomas Soome 

> On 7. märts 2017, at 21:05, Michael W. Lucas  
> wrote:
> 
> Hi,
> 
> I want to open a bug report on this, but have no idea how to gather
> useful info.
> 
> Attempting to install
> FreeBSD-12.0-CURRENT-amd64-20170301-r314495-memstick.img onto an
> eight-drive iX system. This machine previously ran -current, but the
> OS has been sadly used by book testing and I decided to do a clean
> install.
> 
> Used the Guided ZFS install, no networking, no extra users, default
> security. 
> 
> I want a two-way mirror for the base install, and the BIOS didn't
> provide serial numbers for each disk, so I wound up doing multiple
> installs, thinking that once I installed to the disk that the BIOS
> expected to be a boot disk, it'd find the pool and boot.
> 
> Each of the four installs failed to boot, giving me:
> 
> gptzfsboot: error 1 lba 32
> error 1
> gptzfsboot: error 1 lba 4294967288
> gptzfsboot: error 1 lba 1
> gptzfsboot: No ZFS pools located, can't boot


The messages are from low level disk IO, INT13.

if (V86_CY(v86.efl)) {
printf("%s: error %u lba %u\n",
BOOTPROG, v86.eax >> 8 & 0xff, lba);
return (-1);
}

So the error 1 is:

01h Invalid Command

Which means the INT13 AX=0x4200  is not supported by this BIOS. So, the 
question is, does your HBA is set in bios to IDE or AHCI mode? Changing that  
may make an difference, also usual suggestion - check for bios update, and if 
the host supports it, check the uefi boot… Of course, the fact that it did run 
fbsd before, points towards bios settings change...

the invalid command from INT13 extended read is by itself quite odd, but there 
is also possible another reason - if by any reason somehow the memory buffer 
for this call is from memory above 640k and so the invalid memory area was 
provided…

rgds,
toomas


> 
> Old disklabels? gpart -F destroy da0 through ada3. and
> reinstall. Nope.
> 
> In frustration I did an eight-disk mirror install. Got the same
> message.
> 
> Fine, I'll install to the Intel RAID satadom. It's a raid config, but
> it'll get me a working system. Select a ZFS stripe on raid/r0.
> 
> gpart: arg0 'raid/r0': Invalid argument
> 
> Mirror on the individual satadom drives?
> 
> Same boot message.
> 
> Any suggestions on how to gather debugging info for this?
> 
> Thanks,
> ==ml
> 
> 
> -- 
> Michael W. LucasTwitter @mwlauthor 
> nonfiction: https://www.michaelwlucas.com/
> fiction: https://www.michaelwarrenlucas.com/
> blog: http://blather.michaelwlucas.com/
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

Re: Strange kernel build breakage (after r314283?)

2017-03-07 Thread Warner Losh 
On Tue, Mar 7, 2017 at 12:36 PM, Chris H  wrote:
> On Tue, 7 Mar 2017 09:13:58 -0800 Kevin Oberman  wrote
>
>> On Mon, Mar 6, 2017 at 9:18 AM, Lev Serebryakov  wrote:
>>
>> > On 06.03.2017 20:10, Lev Serebryakov wrote:
>> >
>> > >  I've got this error when tried to update my -CURRENT VM to r314772:
>> > >
>> > > /data/src/sys/cam/cam_xpt.c:84:1: error: static_assert failed
>> > > "XPT_PRINT_LEN is too large"
>> > > _Static_assert(XPT_PRINT_LEN <= XPT_PRINT_MAXLEN, "XPT_PRINT_LEN is too
>> > > large");
>> > > ^  ~
>> > >
>> > >  I didn't define any XPT_ macro by hands, but I have
>> > >
>> > > options PRINTF_BUFR_SIZE=1024
>> > >
>> > >  in my kernel config.
>> >  Yep, removing this option helps, but it is surprising and not obvious
>> > at all!
>> >
>> > --
>> > // Lev Serebryakov
>> >
>>
>> If my memory is good (and it may not be), this option was recommended to
>> prevent garbled syslog and console entries, but that was back in v8 days,
>> long, long ago. I have not had his problem for a long time and I think that
>> the option is no longer required and even they, 1024 was a LOT bigger than
>> was recommended at the time. 128 or 256 seems tike the value recommended.
>
> Relax. You're memory is still in good order. :-)
> It was in fact the reason. I had to add the then suggested amount:
> PRINTF_BUFR_SIZE=128
> to my KERNCONF even into early 9. But haven't required it since
> ~mid-9.
>
> OTOH I'm now seeing something similar on CURRENT. Only somewhat
> in reverse.
> The last message I receive on the console following halt(8) is
> the message telling me the NIC has been brought down. It then
> sits there until I hit the enter key to reboot(8).
>
> But that's another topic for another thread. :-)

Hmmm, looks like I broke this... Meaning the static config. I'll look
at it more closely.

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

Re: Strange kernel build breakage (after r314283?)

2017-03-07 Thread Chris H 
On Tue, 7 Mar 2017 09:13:58 -0800 Kevin Oberman  wrote

> On Mon, Mar 6, 2017 at 9:18 AM, Lev Serebryakov  wrote:
> 
> > On 06.03.2017 20:10, Lev Serebryakov wrote:
> >
> > >  I've got this error when tried to update my -CURRENT VM to r314772:
> > >
> > > /data/src/sys/cam/cam_xpt.c:84:1: error: static_assert failed
> > > "XPT_PRINT_LEN is too large"
> > > _Static_assert(XPT_PRINT_LEN <= XPT_PRINT_MAXLEN, "XPT_PRINT_LEN is too
> > > large");
> > > ^  ~
> > >
> > >  I didn't define any XPT_ macro by hands, but I have
> > >
> > > options PRINTF_BUFR_SIZE=1024
> > >
> > >  in my kernel config.
> >  Yep, removing this option helps, but it is surprising and not obvious
> > at all!
> >
> > --
> > // Lev Serebryakov
> >
> 
> If my memory is good (and it may not be), this option was recommended to
> prevent garbled syslog and console entries, but that was back in v8 days,
> long, long ago. I have not had his problem for a long time and I think that
> the option is no longer required and even they, 1024 was a LOT bigger than
> was recommended at the time. 128 or 256 seems tike the value recommended.

Relax. You're memory is still in good order. :-)
It was in fact the reason. I had to add the then suggested amount:
PRINTF_BUFR_SIZE=128
to my KERNCONF even into early 9. But haven't required it since
~mid-9.

OTOH I'm now seeing something similar on CURRENT. Only somewhat
in reverse.
The last message I receive on the console following halt(8) is
the message telling me the NIC has been brought down. It then
sits there until I hit the enter key to reboot(8).

But that's another topic for another thread. :-)

--Chris
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683


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

two recent snapshot installer problems

2017-03-07 Thread Michael W. Lucas 
Hi,

I want to open a bug report on this, but have no idea how to gather
useful info.

Attempting to install
FreeBSD-12.0-CURRENT-amd64-20170301-r314495-memstick.img onto an
eight-drive iX system. This machine previously ran -current, but the
OS has been sadly used by book testing and I decided to do a clean
install.

Used the Guided ZFS install, no networking, no extra users, default
security. 

I want a two-way mirror for the base install, and the BIOS didn't
provide serial numbers for each disk, so I wound up doing multiple
installs, thinking that once I installed to the disk that the BIOS
expected to be a boot disk, it'd find the pool and boot.

Each of the four installs failed to boot, giving me:

gptzfsboot: error 1 lba 32
error 1
gptzfsboot: error 1 lba 4294967288
gptzfsboot: error 1 lba 1
gptzfsboot: No ZFS pools located, can't boot

Old disklabels? gpart -F destroy da0 through ada3. and
reinstall. Nope.

In frustration I did an eight-disk mirror install. Got the same
message.

Fine, I'll install to the Intel RAID satadom. It's a raid config, but
it'll get me a working system. Select a ZFS stripe on raid/r0.

gpart: arg0 'raid/r0': Invalid argument

Mirror on the individual satadom drives?

Same boot message.

Any suggestions on how to gather debugging info for this?

Thanks,
==ml


-- 
Michael W. LucasTwitter @mwlauthor 
nonfiction: https://www.michaelwlucas.com/
fiction: https://www.michaelwarrenlucas.com/
blog: http://blather.michaelwlucas.com/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: make.conf

2017-03-07 Thread Roberto Rodriguez Jr 
Yes I understand it's true there are many options I will test what I can
for my AMD 64 machine since it's a laptop I can probably start making some
reports and also look into ZFS snapshots and tunables. Thank you very much
it was helpful
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: invalid bcd xxx

2017-03-07 Thread Eric van Gyzen 

On 03/04/2017 11:44, Oleksandr Tymoshenko wrote:

Adrian Chadd (adrian.ch...@gmail.com) wrote:

We're not; we need to cope with crappy BIOS emulations and not crash :)

What's Linux doing instead? Ignoring the RTC?


I believe I saw the same problem on either my NUC or Minnowboard.
I just hacked around it to work on something else and didn't
have time to get back to the device since then. But it's not
just emulation BIOS. I think the right way to go is to perform sanity
check on RTC data and refuse to use it if it's not valid.


cem@ posted this patch:

http://dpaste.com/1K2W05E

If someone can test it, I'll gladly commit it.  The real-time clock will 
likely be wrong, but it won't panic with INVARIANTS.


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

Re: Strange kernel build breakage (after r314283?)

2017-03-07 Thread Kevin Oberman 
On Mon, Mar 6, 2017 at 9:18 AM, Lev Serebryakov  wrote:

> On 06.03.2017 20:10, Lev Serebryakov wrote:
>
> >  I've got this error when tried to update my -CURRENT VM to r314772:
> >
> > /data/src/sys/cam/cam_xpt.c:84:1: error: static_assert failed
> > "XPT_PRINT_LEN is too large"
> > _Static_assert(XPT_PRINT_LEN <= XPT_PRINT_MAXLEN, "XPT_PRINT_LEN is too
> > large");
> > ^  ~
> >
> >  I didn't define any XPT_ macro by hands, but I have
> >
> > options PRINTF_BUFR_SIZE=1024
> >
> >  in my kernel config.
>  Yep, removing this option helps, but it is surprising and not obvious
> at all!
>
> --
> // Lev Serebryakov
>

If my memory is good (and it may not be), this option was recommended to
prevent garbled syslog and console entries, but that was back in v8 days,
long, long ago. I have not had his problem for a long time and I think that
the option is no longer required and even they, 1024 was a LOT bigger than
was recommended at the time. 128 or 256 seems tike the value recommended.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Boot failure - svn up from this morning

2017-03-07 Thread Chris H 
On Mon, 6 Mar 2017 04:01:04 + Dexuan Cui  wrote

> > From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> > curr...@freebsd.org] On Behalf Of Dexuan Cui
> > Hi Chris,
> > Thank you very much for the screenshots!!!
> > 
> > On the host there is a 1MB LoaderData memory range, which splits
> > the big Conventional Memory range into a small one (15MB) and a
> > big one: the small one is too small to hold the staging area.
> > 
> > I'm going to post a patch shortly.
> 
> Can you please try the below patch?
> https://reviews.freebsd.org/D9904
> You can find the URL of the "Download Raw Diff" in the page and
> 'wget' the patch and then apply it.
> 
> It should be able to fix the recent UEFI-boot issue introduced by me.
> 
> You may not need to re-buildworld. Please this link to replace the
> bad 'loader.efi':
> https://lists.freebsd.org/pipermail/freebsd-current/2017-March/064979.html
> 
> I'm planning to commit the patch later today in about 6 hours, because
> I'm pretty confident in the patch and it should fix the critical issue...

It may already be too late. But I just wanted to let you know that
I hadn't overlooked/discarded your message. $WORK$ is riding my a$$
pretty hard, and I'm not going to get a chance to catch my breath
till at least mid day. But I *do* plan to give this a shot, and
my earliest opportunity.

Thanks, Dexuan!

--Chris
> 
> Thanks,
> -- Dexuan


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

RE: input/output error @boot

2017-03-07 Thread Roberto Rodriguez Jr 
I will test tonight. Thank you very much for your time

On Mar 6, 2017 11:52 PM, "Dexuan Cui"  wrote:

> From: Dexuan Cui
> I committed r314770 just now to minimize the impact:
> https://svnweb.freebsd.org/base?view=revision=314770
>
> Please let me know in case this can't solve the issue.

Sorry, r314770  has a bug, so I had to commit r314828:
https://svnweb.freebsd.org/base?view=revision=314828

Please make sure you use the latest code, i.e. >= r314828.

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

Re: make.conf

2017-03-07 Thread Roberto Fernández 
Good morning Roberto,

It depends which architecture are you currently using. Ideally the tests
should be run in each CPU type for each architecture and for each
combination of options in the make.conf, src.conf and src-env.conf. That
could last for ever. Feel free to test whatever you can. For instance,
prepare your machine to run FreeBSD HEAD.

I recommend to have ZFS in your hard drive and make snapshots before you
install the new kernel and/or world. Then reinstall everything and check if
it crash, this will be the "final user experience".
If you want to run it on a external device (for instance, in a raspberry 3)
you can prepare for each iteration a live USB live key to test if it breaks
and then check it the hardware was recognized.

In addition, you can run some benchmarks to test the performance of your
machine.

Was it helpful?

With kind regards,
Roberto Fernandez Cueto

2017-03-07 5:34 GMT+01:00 Roberto Rodriguez Jr :

> Good evening gentlemen or good morning I would like to know what kind of
> settings you would like us testers to have in our configuration. For
> example I simply establish a CPU type just for basic assembly optimization
> but what other settings would you recommend to set so that when we
> recompile and build world we have the environment you would like us to
> test. Where the definition of testing could be: we install packages and
> execute X11 environment and try to connect to the internet and run all
> kinds of different applications so that end users also can have the same
> experience and understand that the system is cohesive.
> ?
> too much?
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"