Re: vnode_pager_generic_getpages_done: I/O read error 5 caused by r318394 (was Re: FreeBSD 11.1-BETA1 Now Available)

2017-06-26 Thread Marcelo Araujo 
2017-06-27 4:18 GMT+08:00 Guido Falsi :

> On 06/26/17 16:36, Marcelo Araujo wrote:
>
> Hi,
>>
>> Could you guys test this patch: https://reviews.freebsd.org/D11365?
>> Would it solve the issue?
>>
>>
> Hi,
>
> I confirm the patch fixes the problem for me.
>
> Thanks!
>
> --
> Guido Falsi 
>

Thanks all for the test, very appreciated!
I just committed it: r320390 with MFC for 3 days.

Also thanks trasz@ to point me out to this thread that I was not aware of.


Best,
-- 

-- 
Marcelo Araujo(__)ara...@freebsd.org
\\\'',)http://www.FreeBSD.org    \/  \ ^
Power To Server. .\. /_)
___
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: vnode_pager_generic_getpages_done: I/O read error 5 caused by r318394 (was Re: FreeBSD 11.1-BETA1 Now Available)

2017-06-26 Thread Guido Falsi 

On 06/26/17 16:36, Marcelo Araujo wrote:


Hi,

Could you guys test this patch: https://reviews.freebsd.org/D11365?
Would it solve the issue?



Hi,

I confirm the patch fixes the problem for me.

Thanks!

--
Guido Falsi 
___
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: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work

2017-06-26 Thread Mark Millard 
Top post on one point. . .

Patrick Powell papowell at astart.com wrote on Mon Jun 26 14:10:44 UTC 2017
(He was quoting Gerald. I was also part of some earlier discussions.)

> (Luckily this only hits with most -CURRENT versions of FreeBSD and
> older packages only.)
> 
> Gerald

Unfortunately this part is false if it is about the vm_ooffset_t
and vm_pindex_t issue: stable/11/ and release/11.1.0/  also
have the vm_ooffset_t and vm_pindex_t issue vs. lang/gcc*
packages built by release/11.0.1/ .

The issue is not limited to head (12) at this point:

Installing a gcc* package built by release/11.0.1/ fails
now for stable/11/ and the drafs oft release/11.1.0/ .
Anyone progressing to one of those has to build the
lang/gcc* of interest from source under the newer system
context. (Mixing source builds and package builds is
discouraged as I understand.)

I'm not claiming which specific handling needs to be made.
But the vm_ooffset_t and vm_pindex_t changes did not even
make the UPDATING notes. Right now things look to have
the worst combination for lang/gcc* when release/11.1.0/
becomes official: lang/gcc* 's break without notification
or suggestion of a workaround.

===
Mark Millard
markmi at dsl-only.net

On 2017-Jun-24, at 5:55 PM, Mark Millard  wrote:

The following is based mostly on an extraction from a
private exchange in which a question was asked and my
answer was unsettling: incompatibilities within the
11.* family. I would not normally send to re but doing
so was explicitly mentioned. Hopefully this example is
reasonable for doing that.


Aspect #0: what is broken currently (and in the future?)
  within the 11.* family?

lang/gcc* packages built on release/11.0.1/ to not work
fully on stable/11/ or on the drafts of
release/11.1.0/ . (I leave releng/11.*/'s implicit.)

-r313194 in head and was describied with:

> Define the vm_ooffset_t and vm_pindex_t types as machine-independend.
> 
> The types are for the byte offset and page index in vm object.  They
> are similar to off_t, which is defined as 64bit MI integer.  Using MI
> definitions will allow to provide consistent MD values of vm
> object-related maximum sizes.

The known issue is the generation of header dependencies
in the lang/gcc* builds on release/11.0.1/ that when
used on stable/11/ or release/11.0.1/ generate reports
like:

/usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys/types.h:266:9:
 error: '__vm_ooffset_t' does not name a type
typedef __vm_ooffset_t vm_ooffset_t;
   ^
/usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys/types.h:268:9:
 error: '__vm_pindex_t' does not name a type
typedef __vm_pindex_t vm_pindex_t;
   ^
*** [CoinFactorization2.lo] Error code 1

Unfortunately UPDATING was not updated
for head/'s -r313194 (2017-Feb-4) --nor for
stable/11/'s -r313574 (2017-Feb-11), the MFC.
(No MFC was made to stable/10/ or to
release/10.3.0 as far as I found.)

(These changes predate the INO64 issue in head/ .
Head ends up with more issues than I'm dealing
with here.)


Aspect #1: what 11.* version builds the pre-built packages
  targeting 11.* and the apparent consequences
  (given the vm_ooffset_t and vm_pindex_t changes
   and the lang/gcc* build behavior)

This is the unsettling part for pre-built
packages:  incompatibilities within the 11.*
family for the lang/gcc* packages.

http://portsmon.freebsd.org/portoverview.py?category=%3Bamng=gcc5=

shows categories for builds for

8.4
9.3
10.1
10.3
11.0
head

(Nothing for stable/*/ .)

But the 10.3 rows show no package
builds. I would guess that they
start once 10.1 stops
(approximately).

So it may be that 11.1 will not
get package builds until 11.0
stops (approximately).

If so unless lang/gcc* are changed
to bootstrap differently they will
configure to match release/11.0.1/
and will not be compatible with the
vm_ooffset_t and vm_pindex_t changes
in stable/11/ and release/11.1.0/ .

But as I understand updating how the
lang/gcc* builds work to remove such
dependencies is under investigation.
I do not know any timing relative to
release/11.1.0/ if my understanding
is right.

Until then (if I was right):

Unless there are separate packages made for
targeting release/11.0.1/ vs. release/11.1.0/
it is not obvious when lang/gcc* packages
will be generally compatible with various
folks choices about what to install as the
system version within the release/11.*/
and stable/11/ family. This would likely
be true even if they were built on
release/11.1.0/ : then release/11.0.1/
likely would have compatibility problems.

The ABI versioning does not cover the specific
issues involved based on how vm_ooffset_t and
vm_pindex_t were changed and what the
lang/gcc* builds do relative to such changes.
Yet there is incompatibility for some
fairly-significant-usage ports.


Aspect #2: stable/10/ and release/10.4.0/

Just covered for completeness:

I do not see a MFC of -r313194 to stable/10/ :
its

Re: vnode_pager_generic_getpages_done: I/O read error 5 caused by r318394 (was Re: FreeBSD 11.1-BETA1 Now Available)

2017-06-26 Thread Peter Blok 
Marcelo,

This fix solved the problem for RPI-1B. I’ll do some more testing on other RPI 
and nanobsd variants.

Peter

> On 26 Jun 2017, at 16:36, Marcelo Araujo  wrote:
> 
> 
> 
> 2017-06-23 4:02 GMT+08:00 Guido Falsi  >:
> On 06/22/17 19:06, Guido Falsi wrote:
> On 06/22/17 18:38, Warner Losh wrote:
> 
> I'll followup as soon as I have easier use case to reproduce it. I first need 
> to revert to an image affected by the problem.
> 
> I have made a few more tests.
> 
> I am able to trigger this bug easily by running gpart.
> 
> I'm testing on a PCEngines APU2 board with SD memory card.
> 
> # gpart set -a active -i 1 mmcsd0
> active set on mmcsd0s1
> # fsck_ffs -n /dev/mmcsd0s1a
> ** /dev/mmcsd0s1a (NO WRITE)
> ** Last Mounted on /mnt
> ** Phase 1 - Check Blocks and Sizes
> ** Phase 2 - Check Pathnames
> Segmentation fault
> # shutdown -r now
> /sbin/shutdown: Device not configured
> 
> also, if I open another shell I can't perform many other operations which are 
> not failing in the previous root shell:
> 
> > tail /var/log/messages
> /usr/bin/tail: Device not configured.
> 
> 
> BTW while testing this multiple times I also had the root shell segfault 
> while browsing history, so it should be quite easy to reproduce on your side 
> too. running the gpart set command triggers it every time, with slightly 
> different bu always disruptive symptoms.
> 
> There is a chance it only shows with these embedded systems storage 
> controllers though.
> 
> -- 
> Guido Falsi 
> ___
> freebsd...@freebsd.org  mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs 
> 
> To unsubscribe, send any mail to "freebsd-fs-unsubscr...@freebsd.org 
> "
> 
> 
> Hi,
> 
> Could you guys test this patch: https://reviews.freebsd.org/D11365 
> ?
> Would it solve the issue?
> 
> Best,
> -- 
> 
> -- 
> Marcelo Araujo(__)
> ara...@freebsd.org  \\\'',)
> http://www.FreeBSD.org    \/  \ ^
> Power To Server. .\. /_)

___
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"

Dell r630 UEFI Boot Issues on 11.1-BETA1

2017-06-26 Thread Mark Saad 
All
 I ran in to this issue on stable/11 today . I feel like I saw this in
the past but I can't track it down.
This is a new install on a brand new Dell r630 fitted with 2x
e5-2699v4 cpus . Fresh install of 11.0-RELEASE amd64 install . The
install is a ZFS pool on a ssd. I checked out svn stable/11 and built
and installed world.  The subsequent reboot died with what appears to
be an issue with the ZFS EFI loader. I uploaded a screen shot to imgur
. http://imgur.com/t9clwXL

The Text is a follows

Start @ 0x80302000 ...
EFI framebuffer information:
addr, size   0x9000, 0x30
dimensions 1024 x 768
stride 1024
masks0x00ff, 0xff00, 0x00ff, 0xff00
bi_load_efi_data: GetMemoryMap error 5
_

Any one have any ideas here ?



-- 
mark saad | nones...@longcount.org
___
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: vnode_pager_generic_getpages_done: I/O read error 5 caused by r318394 (was Re: FreeBSD 11.1-BETA1 Now Available)

2017-06-26 Thread Marcelo Araujo 
2017-06-23 4:02 GMT+08:00 Guido Falsi :

> On 06/22/17 19:06, Guido Falsi wrote:
>
>> On 06/22/17 18:38, Warner Losh wrote:
>>
>
> I'll followup as soon as I have easier use case to reproduce it. I first
>> need to revert to an image affected by the problem.
>>
>
> I have made a few more tests.
>
> I am able to trigger this bug easily by running gpart.
>
> I'm testing on a PCEngines APU2 board with SD memory card.
>
> # gpart set -a active -i 1 mmcsd0
> active set on mmcsd0s1
> # fsck_ffs -n /dev/mmcsd0s1a
> ** /dev/mmcsd0s1a (NO WRITE)
> ** Last Mounted on /mnt
> ** Phase 1 - Check Blocks and Sizes
> ** Phase 2 - Check Pathnames
> Segmentation fault
> # shutdown -r now
> /sbin/shutdown: Device not configured
>
> also, if I open another shell I can't perform many other operations which
> are not failing in the previous root shell:
>
> > tail /var/log/messages
> /usr/bin/tail: Device not configured.
>
>
> BTW while testing this multiple times I also had the root shell segfault
> while browsing history, so it should be quite easy to reproduce on your
> side too. running the gpart set command triggers it every time, with
> slightly different bu always disruptive symptoms.
>
> There is a chance it only shows with these embedded systems storage
> controllers though.
>
> --
> Guido Falsi 
> ___
> freebsd...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscr...@freebsd.org"
>


Hi,

Could you guys test this patch: https://reviews.freebsd.org/D11365?
Would it solve the issue?

Best,
-- 

-- 
Marcelo Araujo(__)ara...@freebsd.org
\\\'',)http://www.FreeBSD.org    \/  \ ^
Power To Server. .\. /_)
___
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: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work

2017-06-26 Thread Patrick Powell 

I have reported this problem - see email to freebsd-stable
Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition

Here is part of the discussion:

On Sat, 29 Apr 2017, Dimitry Andric wrote:


This is because gcc's fixincludes process makes copies of certain system
headers (in this case, /usr/include/sys/types.h) with slight
modifications.  Then, it places the directory containing the modified
headers at the front of the include search path.  So far so good.

Now, whenever sys/types.h is updated, as happened with the vm_ooffset_t
change, the header in gcc's own preferred directory might not match the
definitions which are expected, leading to compilation errors.

If the port/package is builts from scratch, does this trigger the
problem?

Yes, basically you need to rebuild all gcc ports from scratch, whenever
you update any system header that matches gcc's list of files it wants
to modify.


That, or run the fixinc.sh script in
./libexec/gcc/$TARGETTRIPLET/$VERSION/install-tools/fixinc.sh.

The proposed patch would help with that, but still require a
manual run, hence my original question.

On Sun, 30 Apr 2017, Konstantin Belousov wrote:


Am I right that Jung-uk fix replaces vm_ooffset_t and vm_pindex_t with
explicit int64_t and uint64_t use, as the course of action for gcc
fixincludes step ?  If yes, I completely disagree.

The change blocks any future changes to the type that might occur in the
base system, for the code compiled by gcc.  End result might be as bad
as mismatched ABI, in the worst case.


Okay, thanks for your feedback.


With all of the above, IMO most sane way to fix problems is to
rename fixincludes directory to some name which is ignored by gcc,
e.g. include-fixed -> include-fixed.saved. This can be done as
post-installation step in the ports.


This is what I figured, too, and plan on giving a try.  It probably
warrants an -exp run to be on the safe side.

On Sun, 30 Apr 2017, Dimitry Andric wrote:


I agree, it would be best to avoid storing any copies of system headers
completely.

Maybe the port can have an option FIX_INCLUDES, which defaults to off?
I am not sure if there is anybody that really wants these 'fixed'
headers, though.


There are two infrastructure improvements for the (current) GCC ports
(orthogonal to a few simpler things I've been simplifying today in
older ports) that I'd like to conclude first, otherwise there'll be
too many balls in the air.

(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218475  is the
last hold-off on the first of them, in case anyone can give this
a try.

It is on my list to pursue directly afterwards, then.

(Luckily this only hits with most -CURRENT versions of FreeBSD and
older packages only.)

Gerald



On 06/24/17 17:55, Mark Millard wrote:

The following is based mostly on an extraction from a
private exchange in which a question was asked and my
answer was unsettling: incompatibilities within the
11.* family. I would not normally send to re but doing
so was explicitly mentioned. Hopefully this example is
reasonable for doing that.


Aspect #0: what is broken currently (and in the future?)
within the 11.* family?

lang/gcc* packages built on release/11.0.1/ to not work
fully on stable/11/ or on the drafts of
release/11.1.0/ . (I leave releng/11.*/'s implicit.)

-r313194 in head and was describied with:


Define the vm_ooffset_t and vm_pindex_t types as machine-independend.

The types are for the byte offset and page index in vm object.  They
are similar to off_t, which is defined as 64bit MI integer.  Using MI
definitions will allow to provide consistent MD values of vm
object-related maximum sizes.

The known issue is the generation of header dependencies
in the lang/gcc* builds on release/11.0.1/ that when
used on stable/11/ or release/11.0.1/ generate reports
like:

/usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys/types.h:266:9:
 error: '__vm_ooffset_t' does not name a type
typedef __vm_ooffset_t vm_ooffset_t;
 ^
/usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys/types.h:268:9:
 error: '__vm_pindex_t' does not name a type
typedef __vm_pindex_t vm_pindex_t;
 ^
*** [CoinFactorization2.lo] Error code 1

Unfortunately UPDATING was not updated
for head/'s -r313194 (2017-Feb-4) --nor for
stable/11/'s -r313574 (2017-Feb-11), the MFC.
(No MFC was made to stable/10/ or to
release/10.3.0 as far as I found.)

(These changes predate the INO64 issue in head/ .
Head ends up with more issues than I'm dealing
with here.)


Aspect #1: what 11.* version builds the pre-built packages
targeting 11.* and the apparent consequences
(given the vm_ooffset_t and vm_pindex_t changes
 and the lang/gcc* build behavior)

This is the unsettling part for pre-built
packages:  incompatibilities within the 11.*
family for the lang/gcc* packages.

http://portsmon.freebsd.org/portoverview.py?category=%3Bamng=gcc5=

shows

In FreeBSD 11.1-BETA2/BETA3 VirtualBox bridged network doesn't work

2017-06-26 Thread Maurizio Vairani 
Upgrading from 11.0-RELEASE-p9 to FreeBSD 11.1-BETA2 and now to 
11.2-BETA3, the VirtualBox bridged network doesn't work.


--
Regards
Maurizio

___
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"