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