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
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
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
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
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"
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
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
___
> 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
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:
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:
> 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
>
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
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...
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 ---
>
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.
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:
> > >
> > >
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:
>> >
>> > >
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
> 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
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?
20 matches
Mail list logo