Re: unknown -z value: common-page-size=4096

2018-09-28 Thread Shawn Webb 
On Fri, Sep 28, 2018 at 10:01:31PM -0400, Charlie Li wrote:
> I've switched to using devel/xtoolchain-llvm70 yesterday to build amd64
> base starting with r338990, and among other issues, ld.lld70 refuses to
> link the kernel:
> 
> Building /usr/local/obj/usr/local/src/amd64.amd64/sys/ARDMORE/kernel.full
> --- kernel.full ---
> linking kernel.full
> ld.lld: error: unknown -z value: common-page-size=4096
> ld.lld: error: unknown -z value: ifunc-noplt
> *** [kernel.full] Error code 1
> 
> make[2]: stopped in /usr/local/obj/usr/local/src/amd64.amd64/sys/ARDMORE
> 
> (ARDMORE is basically GENERIC-NODEBUG, not that it matters)
> 
> The ifunc-noplt is a known issue, it obviously didn't make it upstream
> in time for LLVM 7.0.0, and thus we carry the feature downstream.
> 
> The crux of this link error though, emaste@ quipped in PR 230604 that
> LLD prior to 7.0.0 accepted but ignored unknown options, but now at
> least 7.0.0 disallows unknown options entirely. Which brings up the -z
> common-page-size=4096: has LLD been ignoring this part the whole time,
> and is it of any meaningful use anymore (it seemed to mean something
> with bfd)?

I noticed the same issues. I reverted parts of recent work by upstream
FreeBSD in HardenedBSD's Cross-DSO CFI branch since that branch uses
clang/llvm/lld 7.0.0.

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

unknown -z value: common-page-size=4096

2018-09-28 Thread Charlie Li 
I've switched to using devel/xtoolchain-llvm70 yesterday to build amd64
base starting with r338990, and among other issues, ld.lld70 refuses to
link the kernel:

Building /usr/local/obj/usr/local/src/amd64.amd64/sys/ARDMORE/kernel.full
--- kernel.full ---
linking kernel.full
ld.lld: error: unknown -z value: common-page-size=4096
ld.lld: error: unknown -z value: ifunc-noplt
*** [kernel.full] Error code 1

make[2]: stopped in /usr/local/obj/usr/local/src/amd64.amd64/sys/ARDMORE

(ARDMORE is basically GENERIC-NODEBUG, not that it matters)

The ifunc-noplt is a known issue, it obviously didn't make it upstream
in time for LLVM 7.0.0, and thus we carry the feature downstream.

The crux of this link error though, emaste@ quipped in PR 230604 that
LLD prior to 7.0.0 accepted but ignored unknown options, but now at
least 7.0.0 disallows unknown options entirely. Which brings up the -z
common-page-size=4096: has LLD been ignoring this part the whole time,
and is it of any meaningful use anymore (it seemed to mean something
with bfd)?

-- 
Charlie Li
Can't think of a witty .sigline today…

(This email address is for mailing list use only; replace local-part
with vishwin for off-list communication)



signature.asc
Description: OpenPGP digital signature

Re: drm2 in base

2018-09-28 Thread Johannes Lundberg 
drm-legacy-kmod will be ready before 12 is released.

On Fri, Sep 28, 2018 at 13:48 Steve Kargl 
wrote:

> On Fri, Sep 28, 2018 at 01:30:59PM -0700, Matthew Macy wrote:
> >
> > Bug reports are addressed as they come in. If issues haven't come up
> > it likely reflects a scarcity of users.
> >
>
> It is likely that -current users are still using drm2 from
> base (or have sufficiently new hardware that drm-stable-kmod
> works for them).  I saw Glen's post about the updated
> release schedule, and decided to be pro-active in moving
> to drm-*-kmod to counter the possibility that someone
> might remove drm2 from head as soon as the FreeBSD-12 branch
> exists.
>
> --
> Steve
> ___
> 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: drm2 in base

2018-09-28 Thread Steve Kargl 
On Fri, Sep 28, 2018 at 01:30:59PM -0700, Matthew Macy wrote:
> 
> Bug reports are addressed as they come in. If issues haven't come up
> it likely reflects a scarcity of users.
> 

It is likely that -current users are still using drm2 from
base (or have sufficiently new hardware that drm-stable-kmod
works for them).  I saw Glen's post about the updated
release schedule, and decided to be pro-active in moving
to drm-*-kmod to counter the possibility that someone
might remove drm2 from head as soon as the FreeBSD-12 branch
exists.

-- 
Steve
___
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: drm2 in base

2018-09-28 Thread Steve Kargl 
On Fri, Sep 28, 2018 at 02:21:24PM -0600, Warner Losh wrote:
> On Fri, Sep 28, 2018 at 2:02 PM Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
> 
> > On Fri, Sep 28, 2018 at 02:47:39PM -0500, Matthew D. Fuller wrote:
> > > On Fri, Sep 28, 2018 at 11:00:02AM -0700 I heard the voice of
> > > Steve Kargl, and lo! it spake thus:
> > > >
> > > > I have a radeon HD 6450 video card (CAICOS firmware), and have been
> > > > informed that the hardware is too old for graphics/drm-stable-kmod
> > > > and that I should use graphics/drm-legacy-kmod.
> > >
> > > Well, please don't tell that to the 6450 I've got running on
> > > drm-next-kmod (which also spent some time on drm-stable)...
> > >
> >
> > See the URL I posted.
> >
> > How did you get around the "fence_wait returned with error -512"
> > messages filling /var/log/messages.
> >
> 
> Ah, that thread...  OK. I'm back with you...
> 
> > It also does not get around the problem that
> > drm-legacy-kmod has been advertised as the drop-in
> > replacement for those that use drm2 and have older
> > hardware.
> >
> 
> It should be. The fact that it's not is concerning and should be
> addressed...
> 

Yes, it is concerning, and the reason for my request to retain
drm2 in head.  I'm willing to work with Johannes and Niclas 
or whomever to get things working.  Unfortunately, kernel hacking
is a little beyond my skills. 

AFAICT, the drm-*-kmod ports all depend on the same gpu-firmware
port, which as the name indicates holds all the firmware.  It
seems that drm-legacy-kmod needs to learn how to parse the new
naming scheme (and may be a new scheme for packing the firmware
into a *.ko file).

-- 
Steve
___
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: drm2 in base

2018-09-28 Thread Matthew Macy 
On Fri, Sep 28, 2018 at 1:22 PM Warner Losh  wrote:
>
> On Fri, Sep 28, 2018 at 2:02 PM Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
>
> > On Fri, Sep 28, 2018 at 02:47:39PM -0500, Matthew D. Fuller wrote:
> > > On Fri, Sep 28, 2018 at 11:00:02AM -0700 I heard the voice of
> > > Steve Kargl, and lo! it spake thus:
> > > >
> > > > I have a radeon HD 6450 video card (CAICOS firmware), and have been
> > > > informed that the hardware is too old for graphics/drm-stable-kmod
> > > > and that I should use graphics/drm-legacy-kmod.
> > >
> > > Well, please don't tell that to the 6450 I've got running on
> > > drm-next-kmod (which also spent some time on drm-stable)...
> > >
> >
> > See the URL I posted.
> >
> > How did you get around the "fence_wait returned with error -512"
> > messages filling /var/log/messages.
> >
>
> Ah, that thread...  OK. I'm back with you...
>
>
> > It also does not get around the problem that
> > drm-legacy-kmod has been advertised as the drop-in
> > replacement for those that use drm2 and have older
> > hardware.
> >
>
> It should be. The fact that it's not is concerning and should be
> addressed...


Bug reports are addressed as they come in. If issues haven't come up
it likely reflects a scarcity of users.

-M
___
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: drm2 in base

2018-09-28 Thread Warner Losh 
On Fri, Sep 28, 2018 at 2:02 PM Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:

> On Fri, Sep 28, 2018 at 02:47:39PM -0500, Matthew D. Fuller wrote:
> > On Fri, Sep 28, 2018 at 11:00:02AM -0700 I heard the voice of
> > Steve Kargl, and lo! it spake thus:
> > >
> > > I have a radeon HD 6450 video card (CAICOS firmware), and have been
> > > informed that the hardware is too old for graphics/drm-stable-kmod
> > > and that I should use graphics/drm-legacy-kmod.
> >
> > Well, please don't tell that to the 6450 I've got running on
> > drm-next-kmod (which also spent some time on drm-stable)...
> >
>
> See the URL I posted.
>
> How did you get around the "fence_wait returned with error -512"
> messages filling /var/log/messages.
>

Ah, that thread...  OK. I'm back with you...


> It also does not get around the problem that
> drm-legacy-kmod has been advertised as the drop-in
> replacement for those that use drm2 and have older
> hardware.
>

It should be. The fact that it's not is concerning and should be
addressed...


> But, thanks for your constructive input.
>

Sure.  I'm trying to get the aspirational goals to match the code on the
ground, so knowing there's issues here or there is helpful.

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: drm2 in base

2018-09-28 Thread Steve Kargl 
On Fri, Sep 28, 2018 at 01:58:26PM -0600, Warner Losh wrote:
> On Fri, Sep 28, 2018 at 12:01 PM Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
> 
> >
> > At the risk of raising the ire of others, but with the pending
> > branching for FreeBSD 12, I respectfully request that drm2
> > remain in head after the branch.
> 
> 
> The current plans, which are still being finalized, are to turn off drm and
> drm2 by default only. Once we're sure that all the kinks have been worked
> out with the ports, we'll move to remove some or all of drm/dmr2, but
> that's some months away. Some parts will likely remain for arm, however.

That's good to know.

> >   I have a radeon HD 6450 video
> > card (CAICOS firmware), and have been informed that the hardware
> > is too old for graphics/drm-stable-kmod and that I should use
> > graphics/drm-legacy-kmod.
> >
> > https://lists.freebsd.org/pipermail/freebsd-x11/2018-September/021680.html
> 
> OK.
> 
> Well, I have spent a day or so trying to get drm-legacy to work.
> > drm-legacy in its current state is not a drop in replacement
> > for drm2 in head.  Given what I have found and reported in the
> > above URL, I'm inclined to believe that I may have been the
> > first person to actually try to use drm-legacy.
> >
> 
> What's missing?
> 
> 

A functioning module.  See the URL.

/boot/modules/radeonkms.ko may get loaded, but it
cannot find and load any firmware.  Even if one manually
loads the module with the correct firmware, the firmware
is still not installed.  Thus, Xorg shutdowns during
initialization.

> > I'll also note that the warning about abandonware is
> > misleading for older harware.
> >
> 
> The first part is totally true: it is absolutely abandonware.
> 
> > drmn0: ===
> > drmn0: This code is obsolete abandonware. Install the \
> >graphics/drm-stable-kmod pkg
> > drmn0: ===
> > drmn0: Deprecated code (to be removed in FreeBSD 13): drm2 drivers
> > drmn0: ===
> > drmn0: This code is obsolete abandonware. Install the \
> >graphics/drm-stable-kmod pkg
> > drmn0: ===
> >
> 
> I could add a 'or the drm-legecy-kmod' to the end as well. We do that by
> default for 32-bit platforms.
> 

Thanks.

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
___
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: drm2 in base

2018-09-28 Thread Matthew D. Fuller 
On Fri, Sep 28, 2018 at 01:01:02PM -0700 I heard the voice of
Steve Kargl, and lo! it spake thus:
>
> How did you get around the "fence_wait returned with error -512"
> messages filling /var/log/messages.

Well, I never got them "filling" in a flooding sense.  I did get
regular bursts of them for a while (often video-related, I think), but
they never caused any visible problem.

The last I see in old messages files now is from July.  That might
have been when I switched it from stable->next?  Looking at the
mssages file, shortly after the reboot shortly following the last
fence, I see

Jul 20 21:19:47 cepheus pkg: drm-stable-kmod-g20180619_1 deinstalled
Jul 20 21:19:48 cepheus pkg-static: drm-next-kmod-4.11.g20180619_1 installed

and I haven't seen one since.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
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: drm2 in base

2018-09-28 Thread Steve Kargl 
On Fri, Sep 28, 2018 at 02:47:39PM -0500, Matthew D. Fuller wrote:
> On Fri, Sep 28, 2018 at 11:00:02AM -0700 I heard the voice of
> Steve Kargl, and lo! it spake thus:
> > 
> > I have a radeon HD 6450 video card (CAICOS firmware), and have been
> > informed that the hardware is too old for graphics/drm-stable-kmod
> > and that I should use graphics/drm-legacy-kmod.  
> 
> Well, please don't tell that to the 6450 I've got running on
> drm-next-kmod (which also spent some time on drm-stable)...
> 

See the URL I posted.

How did you get around the "fence_wait returned with error -512"
messages filling /var/log/messages.


It also does not get around the problem that
drm-legacy-kmod has been advertised as the drop-in
replacement for those that use drm2 and have older
hardware.

But, thanks for your constructive input.

-- 
Steve
___
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: drm2 in base

2018-09-28 Thread Warner Losh 
On Fri, Sep 28, 2018 at 12:01 PM Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:

>
> At the risk of raising the ire of others, but with the pending
> branching for FreeBSD 12, I respectfully request that drm2
> remain in head after the branch.


The current plans, which are still being finalized, are to turn off drm and
drm2 by default only. Once we're sure that all the kinks have been worked
out with the ports, we'll move to remove some or all of drm/dmr2, but
that's some months away. Some parts will likely remain for arm, however.


>   I have a radeon HD 6450 video
> card (CAICOS firmware), and have been informed that the hardware
> is too old for graphics/drm-stable-kmod and that I should use
> graphics/drm-legacy-kmod.
>
> https://lists.freebsd.org/pipermail/freebsd-x11/2018-September/021680.html


OK.

Well, I have spent a day or so trying to get drm-legacy to work.
> drm-legacy in its current state is not a drop in replacement
> for drm2 in head.  Given what I have found and reported in the
> above URL, I'm inclined to believe that I may have been the
> first person to actually try to use drm-legacy.
>

What's missing?


> I'll also note that the warning about abandonware is
> misleading for older harware.
>

The first part is totally true: it is absolutely abandonware.


> drmn0: ===
> drmn0: This code is obsolete abandonware. Install the \
>graphics/drm-stable-kmod pkg
> drmn0: ===
> drmn0: Deprecated code (to be removed in FreeBSD 13): drm2 drivers
> drmn0: ===
> drmn0: This code is obsolete abandonware. Install the \
>graphics/drm-stable-kmod pkg
> drmn0: ===
>

I could add a 'or the drm-legecy-kmod' to the end as well. We do that by
default for 32-bit platforms.

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: drm2 in base

2018-09-28 Thread Matthew D. Fuller 
On Fri, Sep 28, 2018 at 11:00:02AM -0700 I heard the voice of
Steve Kargl, and lo! it spake thus:
> 
> I have a radeon HD 6450 video card (CAICOS firmware), and have been
> informed that the hardware is too old for graphics/drm-stable-kmod
> and that I should use graphics/drm-legacy-kmod.  

Well, please don't tell that to the 6450 I've got running on
drm-next-kmod (which also spent some time on drm-stable)...


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
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: resume issues on ALPHA7

2018-09-28 Thread Graham Perrin 
On 28/09/2018 05:35, Pete Wright wrote:
>  … beep on resume, and does not stop beeping until i hit power button.  does 
> that ring any bells?
Yes: 

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

drm2 in base

2018-09-28 Thread Steve Kargl 


At the risk of raising the ire of others, but with the pending
branching for FreeBSD 12, I respectfully request that drm2
remain in head after the branch.  I have a radeon HD 6450 video
card (CAICOS firmware), and have been informed that the hardware
is too old for graphics/drm-stable-kmod and that I should use
graphics/drm-legacy-kmod.  

https://lists.freebsd.org/pipermail/freebsd-x11/2018-September/021680.html

Well, I have spent a day or so trying to get drm-legacy to work.
drm-legacy in its current state is not a drop in replacement
for drm2 in head.  Given what I have found and reported in the
above URL, I'm inclined to believe that I may have been the
first person to actually try to use drm-legacy.

I'll also note that the warning about abandonware is
misleading for older harware.

drmn0: ===
drmn0: This code is obsolete abandonware. Install the \
   graphics/drm-stable-kmod pkg
drmn0: ===
drmn0: Deprecated code (to be removed in FreeBSD 13): drm2 drivers
drmn0: ===
drmn0: This code is obsolete abandonware. Install the \
   graphics/drm-stable-kmod pkg
drmn0: ===

-- 
Steve
___
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: LLVM breaks buildworld

2018-09-28 Thread Rodney W. Grimes 
> > On Thu, Sep 27, 2018 at 12:39:07PM -0700, Steve Kargl wrote:
> > > On Thu, Sep 27, 2018 at 12:34:39PM -0700, Steve Kargl wrote:
> > > > cd /usr/obj
> > > > rm -f usr
> > > > cd /usr/src
> > > > svn update
> > > > make buildworld
> > > > (wait a long time)
> > > > 
> > > > ===> lib/clang/libllvm (all)
> > > > llvm-tblgen -gen-asm-matcher  -I /usr/src/contrib/llvm/include -I 
> > > > /usr/src/contrib/llvm/lib/Target/Mips  -d MipsGenAsmMatcher.inc.d -o 
> > > > MipsGenAsmMatcher.inc  /usr/src/contrib/llvm/lib/Target/Mips/Mips.td
> > > > Included from /usr/src/contrib/llvm/lib/Target/Mips/Mips.td:57:
> > > > Included from 
> > > > /usr/src/contrib/llvm/lib/Target/Mips/MipsInstrInfo.td:3010:
> > > > /usr/src/contrib/llvm/lib/Target/Mips/MipsDSPInstrInfo.td:1142:25: 
> > > > error: Couldn't find class 'SHRD_QB_ENC'
> > > > def SHRL_QB : DspMMRel, SHRD_QB_ENC, SHRL_QB_DESC;
> > > > ^
> > > 
> > > % find /usr/src/contrib/llvm -type f | xargs grep SHRD_QB 
> > >   
> > >   
> > > /usr/src/contrib/llvm/lib/Target/Mips/MipsDSPInstrInfo.td:def SHRL_QB : 
> > > DspMMRel, SHRD_QB_ENC, SHRL_QB_DESC;
> > > 
> > > 
> > > This is only place under llvm that SHRD_QB appears?
> > > 
> > 
> > Hmmm, deleting the file MipsDSPInstrInfo.td seems to flip
> > SHRD to SHRL. Oddly, 'svn diff' did not show a diff with
> > the corrupt file. :(.
> 
> I do not like this difference about cvs and svn,
> cvs would of given you a ? on a file added to the
> tree, svn ingores extra files during a svn diff,
> to see extra files in your tree run 
> svn status
> 
> nas1:root {1002}# cd /usr/src
> nas1:root {1003}# cd bin/ls
> nas1:root {1004}# svn diff
> nas1:root {1005}# touch foo
> nas1:root {1006}# svn diff
> nas1:root {1007}# svn status
> ?   foo

Ignore me, I miss interpretted what was occuring here...

-- 
Rod Grimes rgri...@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: LLVM breaks buildworld

2018-09-28 Thread Rodney W. Grimes 
> On Thu, Sep 27, 2018 at 12:39:07PM -0700, Steve Kargl wrote:
> > On Thu, Sep 27, 2018 at 12:34:39PM -0700, Steve Kargl wrote:
> > > cd /usr/obj
> > > rm -f usr
> > > cd /usr/src
> > > svn update
> > > make buildworld
> > > (wait a long time)
> > > 
> > > ===> lib/clang/libllvm (all)
> > > llvm-tblgen -gen-asm-matcher  -I /usr/src/contrib/llvm/include -I 
> > > /usr/src/contrib/llvm/lib/Target/Mips  -d MipsGenAsmMatcher.inc.d -o 
> > > MipsGenAsmMatcher.inc  /usr/src/contrib/llvm/lib/Target/Mips/Mips.td
> > > Included from /usr/src/contrib/llvm/lib/Target/Mips/Mips.td:57:
> > > Included from /usr/src/contrib/llvm/lib/Target/Mips/MipsInstrInfo.td:3010:
> > > /usr/src/contrib/llvm/lib/Target/Mips/MipsDSPInstrInfo.td:1142:25: error: 
> > > Couldn't find class 'SHRD_QB_ENC'
> > > def SHRL_QB : DspMMRel, SHRD_QB_ENC, SHRL_QB_DESC;
> > > ^
> > 
> > % find /usr/src/contrib/llvm -type f | xargs grep SHRD_QB   
> > 
> >   
> > /usr/src/contrib/llvm/lib/Target/Mips/MipsDSPInstrInfo.td:def SHRL_QB : 
> > DspMMRel, SHRD_QB_ENC, SHRL_QB_DESC;
> > 
> > 
> > This is only place under llvm that SHRD_QB appears?
> > 
> 
> Hmmm, deleting the file MipsDSPInstrInfo.td seems to flip
> SHRD to SHRL. Oddly, 'svn diff' did not show a diff with
> the corrupt file. :(.

I do not like this difference about cvs and svn,
cvs would of given you a ? on a file added to the
tree, svn ingores extra files during a svn diff,
to see extra files in your tree run 
svn status

nas1:root {1002}# cd /usr/src
nas1:root {1003}# cd bin/ls
nas1:root {1004}# svn diff
nas1:root {1005}# touch foo
nas1:root {1006}# svn diff
nas1:root {1007}# svn status
?   foo


-- 
Rod Grimes rgri...@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: ALPHA8/r338991 gpart coredumps

2018-09-28 Thread Daniel Braniss 
made a new image/sd and the problem disappeared! freaky.
sorry for the noice

danny


> On 28 Sep 2018, at 10:07, Daniel Braniss  wrote:
> 
> Hi,
> this is happening on an arm/h3, is this only me?
> this is the output of truss:
> truss gpart show
> mmap(0x0,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,4096,0x15) = 
> 537104384 (0x20039000)
> issetugid()  = 0 (0x0)
> openat(AT_FDCWD,"/etc/libmap.conf",O_RDONLY|O_CLOEXEC,00) = 3 (0x3)
> fstat(3,{ mode=-rw-r--r-- ,inode=81462,size=47,blksize=32768 }) = 0 (0x0)
> read(3,"# $FreeBSD$\nincludedir /usr/loc"...,47) = 47 (0x2f)
> close(3) = 0 (0x0)
> open("/usr/local/etc/libmap.d",O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC,0145)
>  ERR#2 'No such file or directory'
> openat(AT_FDCWD,"/var/run/ld-elf.so.hints",O_RDONLY|O_CLOEXEC,00) = 3 (0x3)
> read(3,"Ehnt\^A\0\0\0\M^@\0\0\0\^^\0\0\0"...,128) = 128 (0x80)
> fstat(3,{ mode=-r--r--r-- ,inode=244811,size=158,blksize=32768 }) = 0 (0x0)
> pread(3,"/lib:/usr/lib:/usr/lib/compat\0",30,0x0) = 30 (0x1e)
> close(3) = 0 (0x0)
> openat(AT_FDCWD,"/lib/libgeom.so.5",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=241318,size=26436,blksize=32768 }) = 0 (0x0)
> mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
>  = 537235456 (0x20059000)
> mmap(0x0,32768,PROT_NONE,MAP_GUARD,537235540,0x2005909420059074) = 537239552 
> (0x2005a000)
> mmap(0x2005a000,8192,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 537239552 (0x2005a000)
> mmap(0x2005c000,12288,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 537247744 (0x2005c000)
> mmap(0x2005f000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 537260032 (0x2005f000)
> mmap(0x20061000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,537235540,0x2005909420059074)
>  = 537268224 (0x20061000)
> munmap(0x20059000,4096)  = 0 (0x0)
> close(3) = 0 (0x0)
> openat(AT_FDCWD,"/lib/libutil.so.9",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=241436,size=71928,blksize=32768 }) = 0 (0x0)
> mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
>  = 537235456 (0x20059000)
> mmap(0x0,81920,PROT_NONE,MAP_GUARD,537235540,0x2005909420059074) = 537272320 
> (0x20062000)
> mmap(0x20062000,16384,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 537272320 (0x20062000)
> mmap(0x20066000,49152,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 537288704 (0x20066000)
> mmap(0x20072000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 537337856 (0x20072000)
> mmap(0x20074000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,537235540,0x2005909420059074)
>  = 537346048 (0x20074000)
> munmap(0x20059000,4096)  = 0 (0x0)
> close(3) = 0 (0x0)
> openat(AT_FDCWD,"/lib/libc.so.7",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=244782,size=1683256,blksize=32768 }) = 0 
> (0x0)
> mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
>  = 537235456 (0x20059000)
> mmap(0x0,1826816,PROT_NONE,MAP_GUARD,537235540,0x2005909420059074) = 
> 537354240 (0x20076000)
> mmap(0x20076000,245760,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 537354240 (0x20076000)
> mmap(0x200b2000,1400832,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 53760 (0x200b2000)
> mmap(0x20208000,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 539000832 (0x20208000)
> mmap(0x20211000,143360,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,537235540,0x2005909420059074)
>  = 539037696 (0x20211000)
> munmap(0x20059000,4096)  = 0 (0x0)
> close(3) = 0 (0x0)
> openat(AT_FDCWD,"/lib/libbsdxml.so.4",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 
> (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=241314,size=150688,blksize=32768 }) = 0 (0x0)
> mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
>  = 537235456 (0x20059000)
> mmap(0x0,151552,PROT_NONE,MAP_GUARD,537235540,0x2005909420059074) = 539181056 
> (0x20234000)
> mmap(0x20234000,16384,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 539181056 (0x20234000)
> mmap(0x20238000,122880,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  =

ALPHA8/r338991 gpart coredumps

2018-09-28 Thread Daniel Braniss 
Hi,
this is happening on an arm/h3, is this only me?
this is the output of truss:
truss gpart show
mmap(0x0,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,4096,0x15) = 
537104384 (0x20039000)
issetugid()  = 0 (0x0)
openat(AT_FDCWD,"/etc/libmap.conf",O_RDONLY|O_CLOEXEC,00) = 3 (0x3)
fstat(3,{ mode=-rw-r--r-- ,inode=81462,size=47,blksize=32768 }) = 0 (0x0)
read(3,"# $FreeBSD$\nincludedir /usr/loc"...,47) = 47 (0x2f)
close(3) = 0 (0x0)
open("/usr/local/etc/libmap.d",O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC,0145) 
ERR#2 'No such file or directory'
openat(AT_FDCWD,"/var/run/ld-elf.so.hints",O_RDONLY|O_CLOEXEC,00) = 3 (0x3)
read(3,"Ehnt\^A\0\0\0\M^@\0\0\0\^^\0\0\0"...,128) = 128 (0x80)
fstat(3,{ mode=-r--r--r-- ,inode=244811,size=158,blksize=32768 }) = 0 (0x0)
pread(3,"/lib:/usr/lib:/usr/lib/compat\0",30,0x0) = 30 (0x1e)
close(3) = 0 (0x0)
openat(AT_FDCWD,"/lib/libgeom.so.5",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=241318,size=26436,blksize=32768 }) = 0 (0x0)
mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
 = 537235456 (0x20059000)
mmap(0x0,32768,PROT_NONE,MAP_GUARD,537235540,0x2005909420059074) = 537239552 
(0x2005a000)
mmap(0x2005a000,8192,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 537239552 (0x2005a000)
mmap(0x2005c000,12288,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 537247744 (0x2005c000)
mmap(0x2005f000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 537260032 (0x2005f000)
mmap(0x20061000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,537235540,0x2005909420059074)
 = 537268224 (0x20061000)
munmap(0x20059000,4096)  = 0 (0x0)
close(3) = 0 (0x0)
openat(AT_FDCWD,"/lib/libutil.so.9",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=241436,size=71928,blksize=32768 }) = 0 (0x0)
mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
 = 537235456 (0x20059000)
mmap(0x0,81920,PROT_NONE,MAP_GUARD,537235540,0x2005909420059074) = 537272320 
(0x20062000)
mmap(0x20062000,16384,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 537272320 (0x20062000)
mmap(0x20066000,49152,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 537288704 (0x20066000)
mmap(0x20072000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 537337856 (0x20072000)
mmap(0x20074000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,537235540,0x2005909420059074)
 = 537346048 (0x20074000)
munmap(0x20059000,4096)  = 0 (0x0)
close(3) = 0 (0x0)
openat(AT_FDCWD,"/lib/libc.so.7",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=244782,size=1683256,blksize=32768 }) = 0 (0x0)
mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
 = 537235456 (0x20059000)
mmap(0x0,1826816,PROT_NONE,MAP_GUARD,537235540,0x2005909420059074) = 537354240 
(0x20076000)
mmap(0x20076000,245760,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 537354240 (0x20076000)
mmap(0x200b2000,1400832,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 53760 (0x200b2000)
mmap(0x20208000,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 539000832 (0x20208000)
mmap(0x20211000,143360,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,537235540,0x2005909420059074)
 = 539037696 (0x20211000)
munmap(0x20059000,4096)  = 0 (0x0)
close(3) = 0 (0x0)
openat(AT_FDCWD,"/lib/libbsdxml.so.4",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=241314,size=150688,blksize=32768 }) = 0 (0x0)
mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
 = 537235456 (0x20059000)
mmap(0x0,151552,PROT_NONE,MAP_GUARD,537235540,0x2005909420059074) = 539181056 
(0x20234000)
mmap(0x20234000,16384,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 539181056 (0x20234000)
mmap(0x20238000,122880,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 539197440 (0x20238000)
mmap(0x20256000,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 539320320 (0x20256000)
munmap(0x20059000,4096)  = 0 (0x0)
close(3) = 0 (0x0)