Re: ELF binary type "3" not known.

2017-03-20 Thread Chris H 
On Mon, 20 Mar 2017 22:32:53 -0700 (PDT) Don Lewis  wrote

> On 20 Mar, Chris H wrote:
> > I'm not sure which of the two lists I'm directing
> > this to is the best/correct one. So I picked both.
> > 
> > To the point; I received this message during a big
> > build session. I was only able to catch the one from
> > x11/nvidia-driver in such a way as to actually get
> > the entire message:
> > 
> > Installing nvidia-driver-375.26_1...
> > ELF binary type "3" not known.
> > /bin/sh: /compat/linux/sbin/ldconfig: Exec format error
> > 
> > I built && installed emulators/linux_base-c7 *prior*
> > to installing this. This is on a:
> > 
> > FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700:
> > Sun Mar 5 09:01:30 PST 2017 amd64
> > 
> > Should I anticipate any problems? All and all, it seems
> > to work. But are there going to be some subtle repercussions?
> > 
> > Is this a 32bit-v-64bit problem with linux_base || the nvidia
> > blob?
> 
> You should have these kernel modules loaded:
> 
> %kldstat | grep linux
>  51 0x82643000 ac488linux.ko
>  64 0x826f e5d0 linux_common.ko
>  71 0x826ff000 99bb8linux64.ko
> 
> They will get loaded on boot if you have this in /boot/loader.conf:
> 
> linux_load="YES"
> linux64_load="YES"
Thanks for the reply, Don.

this is what I have:
# kldstat
Id Refs AddressSize Name
 1   20 0x8020 13c1810  kernel
 23 0x815c3000 ac568linux.ko
 33 0x8167 e000 linux_common.ko
 41 0x8167e000 115128   nvidia-modeset.ko
 52 0x81794000 ff44b8   nvidia.ko
 61 0x82d11000 a954 linprocfs.ko

Which seems to be missing linux64.ko

Looks like I'll need to add it to loader.conf(5)
and seems to me to explain the error message.

Should I rebuild/install the nvidia-driver?

Thanks again, Don!

--Chris


___
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: why are the GEOM secondary GPT tables always corrupt?

2017-03-20 Thread Chris H 
On Tue, 21 Mar 2017 06:16:03 +0100 "O. Hartmann" 
wrote

> On Mon, 20 Mar 2017 19:08:41 -0700
> "Chris H"  wrote:
> 
> > I've seen this discussed before, but there were so many
> > "solutions", I was left feeling this *must* be some sort
> > of bug in GEOM/gpart. So. I just blew away the tables on
> > a USB3 flash drive:
> > 
> > # gpart destroy -F da0
> > 
> > # gpart create -s gpt da0
> > 
> > # gpart add -t freebsd-ufs -l jails da0
> > 
> > # newfs -U /dev/gpt/jails
> > 
> > Added an entry to fstab(5)
> > OK this should be good to go. Mount, and umount
> > all return as expected, as does fsck(8).
> > 
> > Upon reboot, I receive the following:
> > 
> > /dev/gpt/jails: clean, 29961779 free (27 frags, 3745219 blocks, 0.0%
> > fragmentation)
> > GEOM: diskid/DISK-E600665E1DC77749: the secondary GPT table is corrupt or
> > invalid.
> > GEOM: diskid/DISK-E600665E1DC77749: using the primary only -- recovery
> > suggested.
> > 
> > But why?
> > 
> > This is on:
> > FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700: amd64
> > 
> > Thanks for any information.
> > 
> > --Chris
> I see this when I put a disk image, which is smaller than the entire device
> (for instance, 8GB USB flash drive with a UEFI booting (GPT) NanoBSD image of
> 1 GB in size. I do not know what exactly causes the problem, but it can be
> fixed by issuing "gpart recover DEV". I think the secondary GTP table is
> supposed to reside on the physically last blocks of the device (physically).
> 
> oh

Thanks for the reply.
Yes, I've caught that too. But that /almost/ seems reasonable, for
that circumstance. What concerns me here; is that this is a fresh
partition && newfs. Given the partition spans the entire flash
drive. I wouldn't expect there to be any inconsistencies between
the 2 records. I'd hate to use the recover option, and have it
use wrong results. Why isn't the second table "synced" with the
first/primary table?
I'd blame it on the flash drive, but it's not limited to just
this drive, nor just this box. I have a version 11 box that's some
6mos out, that also does this.

Thanks again, for taking the time to reply!

--Chris


___
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: ELF binary type "3" not known.

2017-03-20 Thread Don Lewis 
On 20 Mar, Chris H wrote:
> I'm not sure which of the two lists I'm directing
> this to is the best/correct one. So I picked both.
> 
> To the point; I received this message during a big
> build session. I was only able to catch the one from
> x11/nvidia-driver in such a way as to actually get
> the entire message:
> 
> Installing nvidia-driver-375.26_1...
> ELF binary type "3" not known.
> /bin/sh: /compat/linux/sbin/ldconfig: Exec format error
> 
> I built && installed emulators/linux_base-c7 *prior*
> to installing this. This is on a:
> 
> FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700:
> Sun Mar 5 09:01:30 PST 2017 amd64
> 
> Should I anticipate any problems? All and all, it seems
> to work. But are there going to be some subtle repercussions?
> 
> Is this a 32bit-v-64bit problem with linux_base || the nvidia
> blob?

You should have these kernel modules loaded:

%kldstat | grep linux
 51 0x82643000 ac488linux.ko
 64 0x826f e5d0 linux_common.ko
 71 0x826ff000 99bb8linux64.ko

They will get loaded on boot if you have this in /boot/loader.conf:

linux_load="YES"
linux64_load="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"

Re: process killed: text file modification

2017-03-20 Thread Gergely Czuczy 

On 2017. 03. 21. 3:40, Rick Macklem wrote:

Gergely Czuczy wrote:
[stuff snipped]

Actually I want to test it, but you guys are so vehemently discussing
it, I thought it would be better to do so, once you guys settled your
analysis on the code. Also, me not having the problem occurring, I don't
think would mean it's solved, since that would only mean, the codepath
for my specific usecase works. There might be other things there as
well, what I don't hit.

I hope by vehemently, you didn't find my comments as nasty. If they did
come out that way, it was not what I intended and I apologize.
Oh, totally not. I barely meant that you guys are right in the middle of 
the technical discussion, and it doesn't seemed settled.



Let me know which patch should I test, and I will see to it in the next
couple of days, when I get the time to do it.

I've attached it here again and, yes, I would agree that the results you get
from testing are just another data point and not definitive.
(I'd say this statement is true of all testing of nontrivial code.)

Thanks in advance for any testing you can do, rick

Updated the tree and the patch has applied:
# patch < /home/phoemix/textmod.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|--- fs/nfsclient/nfs_clvnops.c.text2017-03-16 21:55:16.263393000 -0400
|+++ fs/nfsclient/nfs_clvnops.c 2017-03-17 09:31:23.632814000 -0400
--
Patching file fs/nfsclient/nfs_clvnops.c using Plan A...
Hunk #1 succeeded at 140.
Hunk #2 succeeded at 177.
Hunk #3 succeeded at 3375.
done

When I'm back home from work, I will check the build out, and see how it 
goes.


And thank you very much guys for working on fixing this one.

-czg


___
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: ELF binary type "3" not known.

2017-03-20 Thread Chris H 
On Tue, 21 Mar 2017 13:14:56 +0800 Kevin Lo  wrote

> On Mon, Mar 20, 2017 at 09:11:44PM -0700, Chris H wrote:
> > 
> > On Mon, 20 Mar 2017 20:56:05 -0700 "Chris H"  wrote
> > 
> > > I'm not sure which of the two lists I'm directing
> > > this to is the best/correct one. So I picked both.
> > > 
> > > To the point; I received this message during a big
> > > build session. I was only able to catch the one from
> > > x11/nvidia-driver in such a way as to actually get
> > > the entire message:
> > > 
> > > Installing nvidia-driver-375.26_1...
> > > ELF binary type "3" not known.
> > > /bin/sh: /compat/linux/sbin/ldconfig: Exec format error
> > > 
> > > I built && installed emulators/linux_base-c7 *prior*
> > > to installing this. This is on a:
> > > 
> > > FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700:
> > > Sun Mar 5 09:01:30 PST 2017 amd64
> > Sorry. Forgot to add the ports revision.
> > 
> > revision 435383
> 
> Did you do kldload linux64 ?
Thanks for the reply, Kevin.
Yes. Both before building/installing nvidia-driver,
and via loader.conf(5):

linux_load="YES"
nvidia-modeset_load="YES"

Thanks again!

--Chris
> 
> > > 
> > > Should I anticipate any problems? All and all, it seems
> > > to work. But are there going to be some subtle repercussions?
> > > 
> > > Is this a 32bit-v-64bit problem with linux_base || the nvidia
> > > blob?
> > > 
> > > Thanks.
> > > 
> > > --Chris
> 
> Kevin
> ___
> freebsd-po...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-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: ELF binary type "3" not known.

2017-03-20 Thread Kevin Lo 
On Mon, Mar 20, 2017 at 09:11:44PM -0700, Chris H wrote:
> 
> On Mon, 20 Mar 2017 20:56:05 -0700 "Chris H"  wrote
> 
> > I'm not sure which of the two lists I'm directing
> > this to is the best/correct one. So I picked both.
> > 
> > To the point; I received this message during a big
> > build session. I was only able to catch the one from
> > x11/nvidia-driver in such a way as to actually get
> > the entire message:
> > 
> > Installing nvidia-driver-375.26_1...
> > ELF binary type "3" not known.
> > /bin/sh: /compat/linux/sbin/ldconfig: Exec format error
> > 
> > I built && installed emulators/linux_base-c7 *prior*
> > to installing this. This is on a:
> > 
> > FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700:
> > Sun Mar 5 09:01:30 PST 2017 amd64
> Sorry. Forgot to add the ports revision.
> 
> revision 435383

Did you do kldload linux64 ?

> > 
> > Should I anticipate any problems? All and all, it seems
> > to work. But are there going to be some subtle repercussions?
> > 
> > Is this a 32bit-v-64bit problem with linux_base || the nvidia
> > blob?
> > 
> > Thanks.
> > 
> > --Chris

Kevin
___
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: ELF binary type "3" not known.

2017-03-20 Thread O. Hartmann 
On Mon, 20 Mar 2017 21:11:44 -0700
"Chris H"  wrote:

> On Mon, 20 Mar 2017 20:56:05 -0700 "Chris H"  wrote
> 
> > I'm not sure which of the two lists I'm directing
> > this to is the best/correct one. So I picked both.
> > 
> > To the point; I received this message during a big
> > build session. I was only able to catch the one from
> > x11/nvidia-driver in such a way as to actually get
> > the entire message:
> > 
> > Installing nvidia-driver-375.26_1...
> > ELF binary type "3" not known.
> > /bin/sh: /compat/linux/sbin/ldconfig: Exec format error
> > 
> > I built && installed emulators/linux_base-c7 *prior*
> > to installing this. This is on a:
> > 
> > FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700:
> > Sun Mar 5 09:01:30 PST 2017 amd64  
> Sorry. Forgot to add the ports revision.
> 
> revision 435383
> 
> > 
> > Should I anticipate any problems? All and all, it seems
> > to work. But are there going to be some subtle repercussions?
> > 
> > Is this a 32bit-v-64bit problem with linux_base || the nvidia
> > blob?
> > 
> > Thanks.
> > 
> > --Chris
[...]

I see this in poudriere builds, too. I haven't seen with which builds this
occurs, but it occurs quite often.

oh
___
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: ELF binary type "3" not known.

2017-03-20 Thread Chris H 
On Mon, 20 Mar 2017 20:56:05 -0700 "Chris H"  wrote

> I'm not sure which of the two lists I'm directing
> this to is the best/correct one. So I picked both.
> 
> To the point; I received this message during a big
> build session. I was only able to catch the one from
> x11/nvidia-driver in such a way as to actually get
> the entire message:
> 
> Installing nvidia-driver-375.26_1...
> ELF binary type "3" not known.
> /bin/sh: /compat/linux/sbin/ldconfig: Exec format error
> 
> I built && installed emulators/linux_base-c7 *prior*
> to installing this. This is on a:
> 
> FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700:
> Sun Mar 5 09:01:30 PST 2017 amd64
Sorry. Forgot to add the ports revision.

revision 435383

> 
> Should I anticipate any problems? All and all, it seems
> to work. But are there going to be some subtle repercussions?
> 
> Is this a 32bit-v-64bit problem with linux_base || the nvidia
> blob?
> 
> Thanks.
> 
> --Chris
> 
> 
> ___
> freebsd-po...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-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"

ELF binary type "3" not known.

2017-03-20 Thread Chris H 
I'm not sure which of the two lists I'm directing
this to is the best/correct one. So I picked both.

To the point; I received this message during a big
build session. I was only able to catch the one from
x11/nvidia-driver in such a way as to actually get
the entire message:

Installing nvidia-driver-375.26_1...
ELF binary type "3" not known.
/bin/sh: /compat/linux/sbin/ldconfig: Exec format error

I built && installed emulators/linux_base-c7 *prior*
to installing this. This is on a:

FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700:
Sun Mar 5 09:01:30 PST 2017 amd64

Should I anticipate any problems? All and all, it seems
to work. But are there going to be some subtle repercussions?

Is this a 32bit-v-64bit problem with linux_base || the nvidia
blob?

Thanks.

--Chris


___
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: cross compiling freebsd-head is sigh, now broken - thanks libllvm

2017-03-20 Thread Adrian Chadd 
WITHOUT_CLANG fixed it for me. Thanks.




-adrian


On 20 March 2017 at 11:23, Ed Maste  wrote:
> On 19 March 2017 at 03:00, Adrian Chadd  wrote:
>> gcc version 5.3.0 (FreeBSD Ports Collection for mips)
>>
>> ... so uhm, why are we building libllvm?
>
> As of the Clang 4.0.0 import we build Clang by default, on all
> architectures other than those unsupported by Clang, if the
> cross-compiler supports C++11.
>
> I'm not sure if the issue you encountered here is in libllvm or GCC.
> For now though you can set WITHOUT_CLANG and WITHOUT_CLANG_FULL in
> /etc/src.conf.
___
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: process killed: text file modification

2017-03-20 Thread Rick Macklem 
Gergely Czuczy wrote:
[stuff snipped]
> Actually I want to test it, but you guys are so vehemently discussing
> it, I thought it would be better to do so, once you guys settled your
> analysis on the code. Also, me not having the problem occurring, I don't
> think would mean it's solved, since that would only mean, the codepath
> for my specific usecase works. There might be other things there as
> well, what I don't hit.
I hope by vehemently, you didn't find my comments as nasty. If they did
come out that way, it was not what I intended and I apologize.

> Let me know which patch should I test, and I will see to it in the next
> couple of days, when I get the time to do it.
I've attached it here again and, yes, I would agree that the results you get
from testing are just another data point and not definitive. 
(I'd say this statement is true of all testing of nontrivial code.)

Thanks in advance for any testing you can do, rick



textmod.patch
Description: textmod.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: process killed: text file modification

2017-03-20 Thread Rick Macklem 
Konstantin Belousov wrote:
[stuff snipped]
> Yes, I have to somewhat retract my claims, but then I have another set
> of surprises.
Righto.

> I realized (remembered) that nfs has its own VOP_PUTPAGES() method.
> Implementation seems to directly initiate write RPC request using the
> pages as the source buffer. I do not see anything in the code which
> would mark the buffers, which possibly contain the pages, as clean,
> or mark the buffer range as undirty.
The only place I know of that the code does this is in the "struct buf's"
hanging off of v_bufobj.bo_dirty.
I imagine there would be a race between the write-back to the NFS server
and further changes to the page by the process. For the most part, the
VOP_PUTPAGES() is likely to happen after the process is done modifying
the pages (often exited). For cases where it happens sooner, I would expect
the page(s) to be written multiple times, but the last write should bring
the file "up to date" on the server.

> At very least, this might cause unnecessary double-write of the same
> data. I am not sure if it could cause coherency issues between data
> written using mappings and write(2). Also, both vm_object_page_clean()
> and vfs_busy_pages() only ensure the shared-busy state on the pages,
> so write(2) can occur while pageout sends data to server, causing
> 'impossible' content transmitted over the wire.
I'm not sure what you mean by impossible content, but for NFS the only
time the file on the NFS server should be "up to date" will be after a file
doing write(2) writing has closed the fd (and only then if options like
"nocto" has not been used) or after an fsync(2) done by the process
doing the writing.
For mmap'd writing, I think msync(2) is about the only
thing the process can do to ensure the data is written back to the server.
(There was a patch to the NFS VOP_CLOSE() that does a vm_object_page_clean()
 but without the OBJPC_SYNC flag which tries to make sure the pages get written
 shortly after the file is closed. Of course, an mmap'd file can still be 
modified by the
 process after close(2), so it is "just an attempt to make the common case 
work".
 I don't recall, but I don't think I was the author of this patch.)

I also wouldn't be surprised that multiple writes of the same page(s) occurs
under certain situations. (NFS has no rules w.r.t. write ordering. Each RPC is
separate and simply writes N bytes at file offset S.) It definitely happens when
there are multiple write(2)s of partial buffers, depending on when a sync() 
happens.

> Could you, please, explain the reasons for such implementation of
> ncl_putpage() ?
Well, I wasn't the author (it was just cribbed from the old NFS client and I 
don't
know who wrote it), so I'm afraid I don't know. (It's code I avoid changing 
because I don't
really understand it.)

I suspect that the author assumed that processes would either mmap the file
or use write(2) and wouldn't ever try and mix them to-gether.

Hope this helps, rick
___
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"

why are the GEOM secondary GPT tables always corrupt?

2017-03-20 Thread Chris H 
I've seen this discussed before, but there were so many
"solutions", I was left feeling this *must* be some sort
of bug in GEOM/gpart. So. I just blew away the tables on
a USB3 flash drive:

# gpart destroy -F da0

# gpart create -s gpt da0

# gpart add -t freebsd-ufs -l jails da0

# newfs -U /dev/gpt/jails

Added an entry to fstab(5)
OK this should be good to go. Mount, and umount
all return as expected, as does fsck(8).

Upon reboot, I receive the following:

/dev/gpt/jails: clean, 29961779 free (27 frags, 3745219 blocks, 0.0%
fragmentation)
GEOM: diskid/DISK-E600665E1DC77749: the secondary GPT table is corrupt or
invalid.
GEOM: diskid/DISK-E600665E1DC77749: using the primary only -- recovery
suggested.

But why?

This is on:
FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700: amd64

Thanks for any information.

--Chris


___
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: Are textmode consoles/terminals still supported?

2017-03-20 Thread Chris H 
On Tue, 21 Mar 2017 00:09:06 +0200 Toomas Soome  wrote

> > On 20. märts 2017, at 23:58, Chris H  wrote:
> > 
> > I'm attempting to get a video card that DTRT on FreeBSD.
> > I started with the graphics provided by an AMD A6-7470K,
> > only to discover it's not yet supported. So I forked out
> > for a recent nvidia card, and build/installed a new
> > world/kernel.
> > Everything seemed to be as one would expect, except there
> > was an issue with loader.efi. So I had to move mine aside,
> > and use the one off the install media (tho I understand
> > the (u)efi has since been fixed). Now, I'm attempting to
> > obtain textmode. The text stripped from a tty, and pasted
> > to a new file in a textmode editor -- ee(1) for example;
> > pads the line with spaces to EOL, and prefaces each line
> > following the first line with rubbish (about 1 to 2
> > characters worth).
> > So "graphics mode" or vt(4) isn't going to get it, for me.
> > Textmode, and syscons(4) has always worked as expected, and
> > I thought I'd try to re-enable it, or get textmode via vt(4).
> > But all attempts fail.
> > excerpt from my KERNCONF
> > 
> > devicevga
> > options VESA
> > 
> > devicesc
> > options SC_PIXEL_MODE
> > 
> > devicevt
> > devicevt_vga
> > devicevt_efifb
> > 
> > However, following the advice on the freebsd wiki, querying
> > the value in sysctl(8) returns:
> > # sysctl hw.vga.textmode
> > sysctl: unknown oid 'hw.vga.textmode'
> > 
> > OK how bout vidcontrol(1)
> > # vidcontrol -i adapter
> > vidcontrol: obtaining adapter information: Inappropriate ioctl for device
> > 
> > So, it appears from my standpoint that textmode is no longer
> > supported?
> > 
> > FWIW:
> > FreeBSD trump.whitehouse.gov.test 12.0-CURRENT FreeBSD 12.0-CURRENT #0
> > r314700: Sun Mar 5 09:01:30 PST 2017
> > r...@trump.whitehouse.gov.test:/usr/obj/usr/src/sys/TESTKERN amd6
> > 
> > Thank you for anything that might help me obtain textmode again.
> > 
> > -
> 
> The problem with UEFI is that the fact if you can only get “text” aka VGA
> text mode if your card happens to have the proper firmware and you can set up
> the card… UEFI as such does only provide framebuffer based console, and
> that framebuffer is either linear memory mapped or pure software - in last
> case only KMS console framebuffer will do any good. 
Thanks for the reply, Toomas.
I'm running the nvidia blob from the ports tree, version 375.26_1.
Am I to understand it doesn't support textmode through (u)efi?
All my other boxes also use the nvidia blob, and provide textmode,
along with sc/syscons(4) support. But I'm not booting (u)efi on them
either. So I guess (u)efi / vt(4) are to blame? My card is pretty
recent. I'd think that it would support all the bells, and whistles.
But then again... ;-)
Oh well, I guess I don't have to use (u)efi.

Thanks again, Toomas!

--Chris
>
> rgds,
> toomas
> 
> ___
> 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: Are textmode consoles/terminals still supported?

2017-03-20 Thread Chris H 
On Mon, 20 Mar 2017 22:02:06 + Steven Hartland 
wrote

> Add the following to /boot/loader.conf
> 
> Its a tunable but not a sysctl so you can't query it, you just need to 
> set it by adding it to /boot/loader.conf:
> hw.vga.textmode="1"
> 
WOW. Thanks for the fast reply!

I gave your suggestion a try. But it was ignored. :-(
All my other boxes run the nvidia blob, and provide textmode,
and support sc/syscons(4). But I'm not using (u)efi on them.
Maybe that's the trouble?

Thanks again, Steven!

--Chris

> On 20/03/2017 21:58, Chris H wrote:
> > I'm attempting to get a video card that DTRT on FreeBSD.
> > I started with the graphics provided by an AMD A6-7470K,
> > only to discover it's not yet supported. So I forked out
> > for a recent nvidia card, and build/installed a new
> > world/kernel.
> > Everything seemed to be as one would expect, except there
> > was an issue with loader.efi. So I had to move mine aside,
> > and use the one off the install media (tho I understand
> > the (u)efi has since been fixed). Now, I'm attempting to
> > obtain textmode. The text stripped from a tty, and pasted
> > to a new file in a textmode editor -- ee(1) for example;
> > pads the line with spaces to EOL, and prefaces each line
> > following the first line with rubbish (about 1 to 2
> > characters worth).
> > So "graphics mode" or vt(4) isn't going to get it, for me.
> > Textmode, and syscons(4) has always worked as expected, and
> > I thought I'd try to re-enable it, or get textmode via vt(4).
> > But all attempts fail.
> > excerpt from my KERNCONF
> >
> > devicevga
> > options VESA
> >
> > devicesc
> > options SC_PIXEL_MODE
> >
> > devicevt
> > devicevt_vga
> > devicevt_efifb
> >
> > However, following the advice on the freebsd wiki, querying
> > the value in sysctl(8) returns:
> > # sysctl hw.vga.textmode
> > sysctl: unknown oid 'hw.vga.textmode'
> >
> > OK how bout vidcontrol(1)
> > # vidcontrol -i adapter
> > vidcontrol: obtaining adapter information: Inappropriate ioctl for device
> >
> > So, it appears from my standpoint that textmode is no longer
> > supported?
> >
> > FWIW:
> > FreeBSD trump.whitehouse.gov.test 12.0-CURRENT FreeBSD 12.0-CURRENT #0
> > r314700: Sun Mar 5 09:01:30 PST 2017
> > r...@trump.whitehouse.gov.test:/usr/obj/usr/src/sys/TESTKERN amd6
> >
> > Thank you for anything that might help me obtain textmode again.
> >
> > --Chris
> >
> >
> > ___
> > 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"


___
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: process killed: text file modification

2017-03-20 Thread Konstantin Belousov 
On Sun, Mar 19, 2017 at 08:52:50PM +, Rick Macklem wrote:
> Kostik wrote:
> [stuff snipped]
> >> >> Dirty pages are flushed by writes, so if we have a set of dirty pages 
> >> >> and
> >> >> async vm_object_page_clean() is called on the vnode' vm_object, we get
> >> >> a bunch of delayed-write AKA dirty buffers.  This is possible even after
> >> >> VOP_CLOSE() was done, e.g. by syncer performing regular run involving
> >> >> vfs_msync().
> >> When I was talking about ncl_flush() above, I was referring to buffer cache
> >> buffers written by a write(2) syscall, not the case of mmap'd pages.
> > But dirty buffers can appear on the vnode queue due to dirty pages msyncing
> > by syncer, for instance.
> Ok, just to clarify this, in case I don't understand it...
> - You aren't saying that anything will be added to v_bufobj.bo_dirty.bv_hd by
>   vfs_msync() or similar, after VOP_CLOSE(), right?
Yes, I have to somewhat retract my claims, but then I have another set
of surprises.

I realized (remembered) that nfs has its own VOP_PUTPAGES() method.
Implementation seems to directly initiate write RPC request using the
pages as the source buffer. I do not see anything in the code which
would mark the buffers, which possibly contain the pages, as clean,
or mark the buffer range as undirty.

At very least, this might cause unnecessary double-write of the same
data. I am not sure if it could cause coherency issues between data
written using mappings and write(2). Also, both vm_object_page_clean()
and vfs_busy_pages() only ensure the shared-busy state on the pages,
so write(2) can occur while pageout sends data to server, causing
'impossible' content transmitted over the wire.

Could you, please, explain the reasons for such implementation of
ncl_putpage() ?

> --> ncl_flush() { was called nfs_flush() in the old NFS client } only deals 
> with
>  "struct buf's" hanging off v_bufobj.bo_dirty.bv_hd, so I don't see a use 
> for
>  it in the patch.
> 
> As for pages added to v_bufobj.bo_object...the patch assumes that the
> process that was writing the executable file mmap'd is done { normally
> exited } before the exec() syscall occurs. If it is still dirtying
> pages when the exec() occurs, then failing with "Text file modified"
> seems correct to me. As you mentioned, another client can do this to
> the file anyhow.
>
> My understanding is that vm_object_page_clean() will get all the dirty
> pages written back to the server at that point and if that is done in
> VOP_SET_TEXT() as this patch does, what more can the NFS client do?

> 
> [more stuff snipped]
> > Syncer does not open the vnode inside the vfs_msync() operations.
> Ok, but this doesn't put "struct buf's" on v_bufobj.bo_dirty.bv_hd. Am I 
> right?
> (When I said "buffers". I meant "struct buf's" under bo_dirty, not stuff under
>  v_bufobj.bo_object.)
> 
> > We do track writeability to the file, and do not allow execution if there is
> > an active writer, be it a file descriptor opened for write, or a writeable
> > mapping.  And in reverse, if the file is executed (VV_TEXT is set), then
> > we disallow opening the file for write.
> Yes, and that was why I figured doing this in VOP_SET_TEXT(), just before
> setting VV_TEXT, was the right place to do it.
> [more stuff snipped]
> >
> > Thanks for testing the patch. Now, if others can test it...rick
> >
> Again, hopefully others (especially the original reporter) will be able to
> test the patch, rick
___
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: Are textmode consoles/terminals still supported?

2017-03-20 Thread Toomas Soome 

> On 20. märts 2017, at 23:58, Chris H  wrote:
> 
> I'm attempting to get a video card that DTRT on FreeBSD.
> I started with the graphics provided by an AMD A6-7470K,
> only to discover it's not yet supported. So I forked out
> for a recent nvidia card, and build/installed a new
> world/kernel.
> Everything seemed to be as one would expect, except there
> was an issue with loader.efi. So I had to move mine aside,
> and use the one off the install media (tho I understand
> the (u)efi has since been fixed). Now, I'm attempting to
> obtain textmode. The text stripped from a tty, and pasted
> to a new file in a textmode editor -- ee(1) for example;
> pads the line with spaces to EOL, and prefaces each line
> following the first line with rubbish (about 1 to 2
> characters worth).
> So "graphics mode" or vt(4) isn't going to get it, for me.
> Textmode, and syscons(4) has always worked as expected, and
> I thought I'd try to re-enable it, or get textmode via vt(4).
> But all attempts fail.
> excerpt from my KERNCONF
> 
> devicevga
> options   VESA
> 
> devicesc
> options   SC_PIXEL_MODE
> 
> devicevt
> devicevt_vga
> devicevt_efifb
> 
> However, following the advice on the freebsd wiki, querying
> the value in sysctl(8) returns:
> # sysctl hw.vga.textmode
> sysctl: unknown oid 'hw.vga.textmode'
> 
> OK how bout vidcontrol(1)
> # vidcontrol -i adapter
> vidcontrol: obtaining adapter information: Inappropriate ioctl for device
> 
> So, it appears from my standpoint that textmode is no longer
> supported?
> 
> FWIW:
> FreeBSD trump.whitehouse.gov.test 12.0-CURRENT FreeBSD 12.0-CURRENT #0 
> r314700:
> Sun Mar 5 09:01:30 PST 2017
> r...@trump.whitehouse.gov.test:/usr/obj/usr/src/sys/TESTKERN amd6
> 
> Thank you for anything that might help me obtain textmode again.
> 
> -

The problem with UEFI is that the fact if you can only get “text” aka VGA text 
mode if your card happens to have the proper firmware and you can set up the 
card… UEFI as such does only provide framebuffer based console, and that 
framebuffer is either linear memory mapped or pure software - in last case only 
KMS console framebuffer will do any good.

rgds,
toomas

___
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: Are textmode consoles/terminals still supported?

2017-03-20 Thread Steven Hartland 

Add the following to /boot/loader.conf

Its a tunable but not a sysctl so you can't query it, you just need to 
set it by adding it to /boot/loader.conf:

hw.vga.textmode="1"

On 20/03/2017 21:58, Chris H wrote:

I'm attempting to get a video card that DTRT on FreeBSD.
I started with the graphics provided by an AMD A6-7470K,
only to discover it's not yet supported. So I forked out
for a recent nvidia card, and build/installed a new
world/kernel.
Everything seemed to be as one would expect, except there
was an issue with loader.efi. So I had to move mine aside,
and use the one off the install media (tho I understand
the (u)efi has since been fixed). Now, I'm attempting to
obtain textmode. The text stripped from a tty, and pasted
to a new file in a textmode editor -- ee(1) for example;
pads the line with spaces to EOL, and prefaces each line
following the first line with rubbish (about 1 to 2
characters worth).
So "graphics mode" or vt(4) isn't going to get it, for me.
Textmode, and syscons(4) has always worked as expected, and
I thought I'd try to re-enable it, or get textmode via vt(4).
But all attempts fail.
excerpt from my KERNCONF

device  vga
options VESA

device  sc
options SC_PIXEL_MODE

device  vt
device  vt_vga
device  vt_efifb

However, following the advice on the freebsd wiki, querying
the value in sysctl(8) returns:
# sysctl hw.vga.textmode
sysctl: unknown oid 'hw.vga.textmode'

OK how bout vidcontrol(1)
# vidcontrol -i adapter
vidcontrol: obtaining adapter information: Inappropriate ioctl for device

So, it appears from my standpoint that textmode is no longer
supported?

FWIW:
FreeBSD trump.whitehouse.gov.test 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700:
Sun Mar 5 09:01:30 PST 2017
r...@trump.whitehouse.gov.test:/usr/obj/usr/src/sys/TESTKERN amd6

Thank you for anything that might help me obtain textmode again.

--Chris


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

Are textmode consoles/terminals still supported?

2017-03-20 Thread Chris H 
I'm attempting to get a video card that DTRT on FreeBSD.
I started with the graphics provided by an AMD A6-7470K,
only to discover it's not yet supported. So I forked out
for a recent nvidia card, and build/installed a new
world/kernel.
Everything seemed to be as one would expect, except there
was an issue with loader.efi. So I had to move mine aside,
and use the one off the install media (tho I understand
the (u)efi has since been fixed). Now, I'm attempting to
obtain textmode. The text stripped from a tty, and pasted
to a new file in a textmode editor -- ee(1) for example;
pads the line with spaces to EOL, and prefaces each line
following the first line with rubbish (about 1 to 2
characters worth).
So "graphics mode" or vt(4) isn't going to get it, for me.
Textmode, and syscons(4) has always worked as expected, and
I thought I'd try to re-enable it, or get textmode via vt(4).
But all attempts fail.
excerpt from my KERNCONF

device  vga
options VESA

device  sc
options SC_PIXEL_MODE

device  vt
device  vt_vga
device  vt_efifb

However, following the advice on the freebsd wiki, querying
the value in sysctl(8) returns:
# sysctl hw.vga.textmode
sysctl: unknown oid 'hw.vga.textmode'

OK how bout vidcontrol(1)
# vidcontrol -i adapter
vidcontrol: obtaining adapter information: Inappropriate ioctl for device

So, it appears from my standpoint that textmode is no longer
supported?

FWIW:
FreeBSD trump.whitehouse.gov.test 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700:
Sun Mar 5 09:01:30 PST 2017
r...@trump.whitehouse.gov.test:/usr/obj/usr/src/sys/TESTKERN amd6

Thank you for anything that might help me obtain textmode again.

--Chris


___
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: NFSv2 boot & OLD_NFSV2

2017-03-20 Thread Toomas Soome 

> On 20. märts 2017, at 23:53, Rick Macklem  wrote:
> 
> Baptiste Daroussin wrote:
>> On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote:
>>> Hi!
>>> 
>>> The current boot code is building NFSv3, with preprocessor conditional 
>>> OLD_NFSV2. Should NFSv2 code still be kept around or can we burn it?
>>> 
>>> rgds,
>>> toomas
>> 
>> I vote burn
>> 
>> Bapt
> I would be happy to see NFSv2 go away. However, depending on how people 
> configure
> their diskless root fs, they do end up using NFSv2 for their root fs.
> 
> Does booting over NFSv3 affect this?
> 
> I think the answer is no for a FreeBSD server (since the NFSv2 File Handle is 
> the same as
> the NFSv3 one, except padded with 0 bytes to 32bytes long).
> However, there might be non-FreeBSD NFS servers where the NFSv2 file handle 
> is different
> than the NFSv3 one and for that case, the user would need NFSv2 boot code (or
> reconfigure their root fs to use NFSv3).
> 
> To be honest, I suspect few realize that they are using NFSv2 for their root 
> fs.
> (They'd see it in a packet trace or via "nfsstat -m", but otherwise they 
> probably
>  think they are using NFSv3 for their root fs.)
> 
> rick

if they do not suspect, they most likely use v3 - due to simple fact that you 
have to rebuild loader to use NFSv2 - it is compile time option.

rgds,
toomas
___
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: NFSv2 boot & OLD_NFSV2

2017-03-20 Thread Rick Macklem 
Baptiste Daroussin wrote:
> On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote:
> > Hi!
> >
> > The current boot code is building NFSv3, with preprocessor conditional 
> > OLD_NFSV2. Should NFSv2 code still be kept around or can we burn it?
> >
> > rgds,
> > toomas
>
> I vote burn
>
> Bapt
I would be happy to see NFSv2 go away. However, depending on how people 
configure
their diskless root fs, they do end up using NFSv2 for their root fs.

Does booting over NFSv3 affect this?

I think the answer is no for a FreeBSD server (since the NFSv2 File Handle is 
the same as
the NFSv3 one, except padded with 0 bytes to 32bytes long).
However, there might be non-FreeBSD NFS servers where the NFSv2 file handle is 
different
than the NFSv3 one and for that case, the user would need NFSv2 boot code (or
reconfigure their root fs to use NFSv3).

To be honest, I suspect few realize that they are using NFSv2 for their root fs.
(They'd see it in a packet trace or via "nfsstat -m", but otherwise they 
probably
  think they are using NFSv3 for their root fs.)

rick
___
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: NFSv2 boot & OLD_NFSV2

2017-03-20 Thread Baptiste Daroussin 
On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote:
> Hi!
> 
> The current boot code is building NFSv3, with preprocessor conditional 
> OLD_NFSV2. Should NFSv2 code still be kept around or can we burn it?
> 
> rgds,
> toomas

I vote burn

Bapt


signature.asc
Description: PGP signature

Re: cross compiling freebsd-head is sigh, now broken - thanks libllvm

2017-03-20 Thread Ed Maste 
On 19 March 2017 at 03:00, Adrian Chadd  wrote:
> gcc version 5.3.0 (FreeBSD Ports Collection for mips)
>
> ... so uhm, why are we building libllvm?

As of the Clang 4.0.0 import we build Clang by default, on all
architectures other than those unsupported by Clang, if the
cross-compiler supports C++11.

I'm not sure if the issue you encountered here is in libllvm or GCC.
For now though you can set WITHOUT_CLANG and WITHOUT_CLANG_FULL in
/etc/src.conf.
___
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"

NFSv2 boot & OLD_NFSV2

2017-03-20 Thread Toomas Soome 
Hi!

The current boot code is building NFSv3, with preprocessor conditional 
OLD_NFSV2. Should NFSv2 code still be kept around or can we burn it?

rgds,
toomas
___
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: debugging webcamd in CURRENT

2017-03-20 Thread Hans Petter Selasky 

On 03/20/17 14:14, Matthias Apitz wrote:


Hello,

I have a very recent 12-CURRENT on amd64 (r314251) with all ports from beginning
of March.

While testing multimedia/webcamd in debug mode it says:

# /usr/local/sbin/webcamd -i 0 -d ugen0.2 -U webcamd -G webcamd -H
: USB HID core driver
Linux video capture interface: v2.00
IR NEC protocol handler initialized
IR RC5(x/sz) protocol handler initialized
IR RC6 protocol handler initialized
IR JVC protocol handler initialized
IR Sony protocol handler initialized
IR SANYO protocol handler initialized
IR LIRC bridge handler initialized
IR XMP protocol handler initialized
b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded 
successfully
uvcvideo: Unable to create debugfs directory

USB Video Class driver (1.1.1)
cpia2: V4L-Driver for Vision CPiA2 based cameras v3.0.1
pvrusb2: V4L in-tree version:Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner
pvrusb2: Debug mask is 31 (0x1f)
USBVision USB Video Device Driver for Linux : 0.9.11
em28xx: Registered (Em28xx v4l2 Extension) extension
em28xx: Registered (Em28xx dvb Extension) extension
Attached to ugen0.2[0]
uvcvideo: Found UVC 1.00 device HD WebCam (1bcf:2c67)
Waiting for HAL USB device.
Creating /dev/video0
uvcvideo: Failed to submit URB 0 (-32).


Questions about this:

1. Why it is unable to create the debugfs directory?
2. The UVC driver in
multimedia/webcamd/work/webcamd-4.8.0.4/media_tree/drivers/media/usb/uvc
is from between 2013-2016, is there any more recent version?
3. Why is it sometimes failing with 'Failed to submit URB 0 (-32)'?



Hi,

The latest version is in ports. You can compile webcamd with debugging. 
Then there are some options listed by "webcamd -s" which you can turn on 
using "webcamd -m xxx=yyy" to get more verbose debugging. You can also 
try starting "usbdump -i usbusX -f Y -s 65536" where X and Y are numbers 
after ugen, before plugging the device, to see which USB errors are 
happening.


--HPS

--HPS

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

debugging webcamd in CURRENT

2017-03-20 Thread Matthias Apitz 

Hello,

I have a very recent 12-CURRENT on amd64 (r314251) with all ports from beginning
of March.

While testing multimedia/webcamd in debug mode it says:

# /usr/local/sbin/webcamd -i 0 -d ugen0.2 -U webcamd -G webcamd -H
: USB HID core driver
Linux video capture interface: v2.00
IR NEC protocol handler initialized
IR RC5(x/sz) protocol handler initialized
IR RC6 protocol handler initialized
IR JVC protocol handler initialized
IR Sony protocol handler initialized
IR SANYO protocol handler initialized
IR LIRC bridge handler initialized
IR XMP protocol handler initialized
b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded 
successfully
uvcvideo: Unable to create debugfs directory

USB Video Class driver (1.1.1)
cpia2: V4L-Driver for Vision CPiA2 based cameras v3.0.1
pvrusb2: V4L in-tree version:Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner
pvrusb2: Debug mask is 31 (0x1f)
USBVision USB Video Device Driver for Linux : 0.9.11
em28xx: Registered (Em28xx v4l2 Extension) extension
em28xx: Registered (Em28xx dvb Extension) extension
Attached to ugen0.2[0]
uvcvideo: Found UVC 1.00 device HD WebCam (1bcf:2c67)
Waiting for HAL USB device.
Creating /dev/video0
uvcvideo: Failed to submit URB 0 (-32).


Questions about this:

1. Why it is unable to create the debugfs directory?
2. The UVC driver in
multimedia/webcamd/work/webcamd-4.8.0.4/media_tree/drivers/media/usb/uvc
is from between 2013-2016, is there any more recent version?
3. Why is it sometimes failing with 'Failed to submit URB 0 (-32)'?

Thanks

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/  ☎ 
+49-176-38902045
___
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"