Re: new mailing list - freebsd-wirel...@freebsd.org
On Sat, Apr 09, 2011 at 11:15:51AM +0800, Adrian Chadd wrote: >Hi all, > >I've just organised a new mailing list for wireless related development, >discussion and bug fixing. > >Please subscribe to freebsd-wirel...@freebsd.org and ask wireless related >things there. > >Although I (and others) keep an eye on the other mailing lists, you'll be >more likely to get a response if you instead email the wireless list. > Hey! good idea. -- J. Hellenthal pgphTxkQ9Ow8x.pgp Description: PGP signature
new mailing list - freebsd-wirel...@freebsd.org
Hi all, I've just organised a new mailing list for wireless related development, discussion and bug fixing. Please subscribe to freebsd-wirel...@freebsd.org and ask wireless related things there. Although I (and others) keep an eye on the other mailing lists, you'll be more likely to get a response if you instead email the wireless list. Thanks, adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vmware-tools-freebsd && "No drivers for x.org version: 7.6.5."
On Apr 8, 2011, at 5:03 AM, Matthias Apitz wrote: > El día Friday, April 08, 2011 a las 12:17:03PM +0200, Dimitry Andric escribió: > >> On 2011-04-08 10:42, Matthias Apitz wrote: >>> I have FreeBSD 9-CURRENT up and running in a VMware Workstation 7.x and >>> I tried to install the vmware-tools-freebsd of VMware to get the driver >>> for Xorg, but it seems that X.org 7.6.5. is not supported. My other VM >>> runs a 8-CURRENT with X.org 7.4_1 which works fine. >>> >>> Any idea how to solve this? A co-worker and I recently went through this. Seems the trick is to install xf86-video-vmware-10.16.9 (we are using 8.1-RELEASE), then re-run the vmware-config.pl file that you un-packed from the vmware-tools tarball, then run "X -configure" (as root), then copy /root/xorg.conf.new to /etc/X11/xorg.conf (making appropriate backups first, of course). We were able to achieve 1600x1200 resolution. -- Devin >>> Should I go back to X.org 7.4_1 in >>> 9-CURRENT? Or should I fake the vmware-tools installer to see X.org as >>> /.4 while it is 7.6.5? >> >> X.org 7.5 already has VMware drivers, so you can just install the >> x11-drivers/xf86-input-vmmouse and x11-drivers/xf86-video-vmware ports. >> >> Alternatively, run "make config" in x11-drivers/xorg-drivers, check the >> "VMMOUSE" and "VMWARE" entries, and rebuild this meta-port. > > Dimitry, > > Thanks for your kind & fast answer; does this also mean that I could > completely get rid of the VMware' vmware-tools-freebsd? I'm using on the > 8-CURRENT system the emulators/open-vom-tools and will install them in > the 9-CURRENT too. > > Thanks again > >matthias > > -- > Matthias Apitz > t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 > e - w http://www.unixarea.de/ > ___ > freebsd-questi...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fdisk formatting of disk having bs=1K fails
On Apr 8, 2011, at 12:34 PM, Hans Petter Selasky wrote: > Hi, > > It appears that src/sbin/fdisk.c can only read the MBR of disks having a > blocksize different than 512 bytes. When writing a new MBR, the below check > fails. Can someone having knowledge into fdisk, fix this issue and MFC to 8- > stable? Also I'm curious about the #ifdef __ia64__ . You can eliminate the __ia64__ conditional if you want. From the commit log: r95860 | peter | 2002-05-01 06:48:29 + (Wed, 01 May 2002) | 4 lines Add a hack so that fdisk(8) can initialize an ia64 disk. There is no /boot/mbr to read the boot code from (ia64 does not *have* bootblocks!). fdisk depended on magic in the /boot/mbr file to initialize some fields. fdisk is not compiled for ia64 anymore since the introduction of gpart. The same holds for bsdlabel. So, that means that the hack is not needed anymore. FYI, -- Marcel Moolenaar xcl...@mac.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vmware-tools-freebsd && "No drivers for x.org version: 7.6.5."
On Fri, 8 Apr 2011 14:03:36 +0200 Matthias Apitz wrote: > El día Friday, April 08, 2011 a las 12:17:03PM +0200, Dimitry Andric > escribió: > > > On 2011-04-08 10:42, Matthias Apitz wrote: > > >I have FreeBSD 9-CURRENT up and running in a VMware Workstation > > >7.x and I tried to install the vmware-tools-freebsd of VMware to > > >get the driver for Xorg, but it seems that X.org 7.6.5. is not > > >supported. My other VM runs a 8-CURRENT with X.org 7.4_1 which > > >works fine. > > > > > >Any idea how to solve this? Should I go back to X.org 7.4_1 in > > >9-CURRENT? Or should I fake the vmware-tools installer to see > > >X.org as /.4 while it is 7.6.5? > > > > X.org 7.5 already has VMware drivers, so you can just install the > > x11-drivers/xf86-input-vmmouse and x11-drivers/xf86-video-vmware > > ports. > > > > Alternatively, run "make config" in x11-drivers/xorg-drivers, check > > the "VMMOUSE" and "VMWARE" entries, and rebuild this meta-port. > > Dimitry, > > Thanks for your kind & fast answer; does this also mean that I could > completely get rid of the VMware' vmware-tools-freebsd? I'm using on > the 8-CURRENT system the emulators/open-vom-tools and will install > them in the 9-CURRENT too. > > Thanks again > > matthias > I am not Dmirty, but I will answer anyway. If you install open-vm-tools and xf86-input-vmmouse and xf86-video-vmware drivers, you won't need to bother fighting with vmware tools anymore. The open-vm-tools port installs vmware-user-suid-wrapper binary without SUID bit, you will need to fix that. Also, vmblock driver currently crashes FreeBSD-current kernel, so you will need to remove or rename /boot/modules/vmblock.ko and /usr/local/lib/vmware-tools/modules/drivers/vmblock.ko so that vmware-user-suid-wrapper does not load it for you automatically. -- Alexander Kabaev signature.asc Description: PGP signature
Fdisk formatting of disk having bs=1K fails
Hi, It appears that src/sbin/fdisk.c can only read the MBR of disks having a blocksize different than 512 bytes. When writing a new MBR, the below check fails. Can someone having knowledge into fdisk, fix this issue and MFC to 8- stable? Also I'm curious about the #ifdef __ia64__ . if ((mboot.bootinst_size = sb.st_size) % secsize != 0) secsize = 1024; sb.st_size = sizeof(/boot/mbr) = 512; --HPS My attempt to fix this issue: --- fdisk.c (revision 220305) +++ fdisk.c (local) @@ -508,22 +508,29 @@ const char *fname; int fdesc, n; struct stat sb; + off_t align_size; fname = b_flag ? b_flag : "/boot/mbr"; if ((fdesc = open(fname, O_RDONLY)) == -1 || fstat(fdesc, &sb) == -1) err(1, "%s", fname); - if ((mboot.bootinst_size = sb.st_size) % secsize != 0) - errx(1, "%s: length must be a multiple of sector size", fname); + + align_size = (sb.st_size + secsize - 1); + align_size -= align_size % secsize; + if (align_size == 0) + errx(1, "%s: length must be non-zero", fname); + mboot.bootinst_size = align_size; if (mboot.bootinst != NULL) free(mboot.bootinst); - if ((mboot.bootinst = malloc(mboot.bootinst_size = sb.st_size)) == NULL) + if ((mboot.bootinst = malloc(align_size)) == NULL) errx(1, "%s: unable to allocate read buffer", fname); - if ((n = read(fdesc, mboot.bootinst, mboot.bootinst_size)) == -1 || + if ((n = read(fdesc, mboot.bootinst, sb.st_size)) == -1 || close(fdesc)) err(1, "%s", fname); - if (n != mboot.bootinst_size) + if (n != sb.st_size) errx(1, "%s: short read", fname); + if (align_size != n) + memset(mboot.bootinst + sb.st_size, 0, align_size - sb.st_size); #else if (mboot.bootinst != NULL) free(mboot.bootinst); ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[PATCH] Add syslogd option that suppresses hostname logging
I've written a short patch for syslogd that adds a -H option. Setting
that option will prevent syslogd from logging the hostname with every
log messages. If there are no objections I'm going to commit this in
the next couple of days.
Index: syslogd.c
===
--- syslogd.c (revision 220452)
+++ syslogd.c (working copy)
@@ -301,6 +301,7 @@
/* 0=no, 1=numeric, 2=names */
static int KeepKernFac;/* Keep remotely logged kernel facility */
static int needdofsync = 0; /* Are any file(s) waiting to be fsynced? */
+static int LogHost = 1;
static struct pidfh *pfh;
volatile sig_atomic_t MarkSet, WantDie;
@@ -358,7 +359,7 @@
dprintf("madvise() failed: %s\n", strerror(errno));
bindhostname = NULL;
- while ((ch = getopt(argc, argv, "468Aa:b:cCdf:kl:m:nop:P:sS:Tuv"))
+ while ((ch = getopt(argc, argv, "468Aa:b:cCdf:Hkl:m:nop:P:sS:Tuv"))
!= -1)
switch (ch) {
case '4':
@@ -394,6 +395,9 @@
case 'f': /* configuration file */
ConfFile = optarg;
break;
+ case 'H': /* don't log the origin hostname */
+ LogHost = 0;
+ break;
case 'k': /* keep remote kern fac */
KeepKernFac = 1;
break;
@@ -1150,12 +1154,20 @@
}
v++;
- v->iov_base = f->f_prevhost;
- v->iov_len = strlen(v->iov_base);
+ if (LogHost) {
+ v->iov_base = f->f_prevhost;
+ v->iov_len = strlen(v->iov_base);
+ v++;
+ v->iov_base = space;
+ v->iov_len = 1;
+ } else {
+ v->iov_base = nul;
+ v->iov_len = 0;
+ v++;
+ v->iov_base = nul;
+ v->iov_len = 0;
+ }
v++;
- v->iov_base = space;
- v->iov_len = 1;
- v++;
if (msg) {
wmsg = strdup(msg); /* XXX iov_base needs a `const' sibling. */
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn commit: r220430 - head/sys/amd64/amd64
On 4/8/11 6:23 AM, Andriy Gapon wrote: on 08/04/2011 00:32 John Baldwin said the following: Author: jhb Date: Thu Apr 7 21:32:25 2011 New Revision: 220430 URL: http://svn.freebsd.org/changeset/base/220430 Log: If a system call does not request a full interrupt return, use a fast path via the sysretq instruction to return from the system call. This was removed in 190620 and not quite fully restored in 195486. This resolves most of the performance regression in system call microbenchmarks between 7 and 8 on amd64. Reviewed by: kib MFC after: 1 week I think that this commit (plus r220431) has broken something in my environment. After updating to the most recent head I started to get semi-random problems in various areas: - named would consistently fail to start, but with different errors (assertions) - ^Z and fg result in a process getting SIGSEGV - X sometimes fails to start complaining about failed VT switch Reverting just these two commits restores sanity. Just in case, my processor is AMD (arch is obviously amd64). I think I've found this (I got a bunch of weird core dumps overnight, too). The problem is that ast() can context switch in which case PCB_FULL_IRET might get set, but this code would still do the fast path after ast() returned. I fixed it to recheck the PCB_FULL_IRET flag after returning from ast() and that has fixed the core dumps I was seeing overnight. I also fixed a bug where PCB_FULL_IRET wasn't updated in some of the ia32 compat code, a typo in a comment, and trimmed an extra mov from the doreti path: Index: amd64/exception.S === --- amd64/exception.S (revision 221092) +++ amd64/exception.S (working copy) @@ -382,10 +382,10 @@ FAKE_MCOUNT(TF_RIP(%rsp)) movq%rsp,%rdi callsyscall - movqPCPU(CURPCB),%rax +1: movqPCPU(CURPCB),%rax testl $PCB_FULL_IRET,PCB_FLAGS(%rax) - jne 3f -1: /* Check for and handle AST's on return to userland. */ + jnz 3f + /* Check for and handle AST's on return to userland. */ cli movqPCPU(CURTHREAD),%rax testl $TDF_ASTPENDING | TDF_NEEDRESCHED,TD_FLAGS(%rax) @@ -661,7 +661,7 @@ doreti_ast: /* * Check for ASTs atomically with returning. Disabling CPU -* interrupts provides sufficient locking eve in the SMP case, +* interrupts provides sufficient locking even in the SMP case, * since we will be informed of any new ASTs by an IPI. */ cli @@ -682,8 +682,7 @@ */ doreti_exit: MEXITCOUNT - movqPCPU(CURTHREAD),%r8 - movqTD_PCB(%r8),%r8 + movqPCPU(CURPCB),%r8 /* * Do not reload segment registers for kernel. Index: ia32/ia32_exception.S === --- ia32/ia32_exception.S (revision 221079) +++ ia32/ia32_exception.S (working copy) @@ -46,7 +46,7 @@ subq$TF_ERR,%rsp/* skip over tf_trapno */ movq%rdi,TF_RDI(%rsp) movqPCPU(CURPCB),%rdi - movb$0,PCB_FULL_IRET(%rdi) + andl$~PCB_FULL_IRET,PCB_FLAGS(%rdi) movw%fs,TF_FS(%rsp) movw%gs,TF_GS(%rsp) movw%es,TF_ES(%rsp) -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn commit: r220430 - head/sys/amd64/amd64
08.04.2011 14:23, Andriy Gapon пишет: on 08/04/2011 00:32 John Baldwin said the following: Author: jhb Date: Thu Apr 7 21:32:25 2011 New Revision: 220430 URL: http://svn.freebsd.org/changeset/base/220430 Log: If a system call does not request a full interrupt return, use a fast path via the sysretq instruction to return from the system call. This was removed in 190620 and not quite fully restored in 195486. This resolves most of the performance regression in system call microbenchmarks between 7 and 8 on amd64. Reviewed by: kib MFC after: 1 week I think that this commit (plus r220431) has broken something in my environment. After updating to the most recent head I started to get semi-random problems in various areas: - named would consistently fail to start, but with different errors (assertions) - ^Z and fg result in a process getting SIGSEGV - X sometimes fails to start complaining about failed VT switch Reverting just these two commits restores sanity. Just in case, my processor is AMD (arch is obviously amd64). confirm Modified: head/sys/amd64/amd64/exception.S Modified: head/sys/amd64/amd64/exception.S == --- head/sys/amd64/amd64/exception.SThu Apr 7 21:29:34 2011 (r220429) +++ head/sys/amd64/amd64/exception.SThu Apr 7 21:32:25 2011 (r220430) @@ -339,6 +339,9 @@ IDTVEC(prot) * and the new privilige level. We are still running on the old user stack * pointer. We have to juggle a few things around to find our stack etc. * swapgs gives us access to our PCPU space only. + * + * We do not support invoking this from a custom %cs or %ss (e.g. using + * entries from an LDT). */ IDTVEC(fast_syscall) swapgs @@ -380,6 +383,36 @@ IDTVEC(fast_syscall) movq%rsp,%rdi callsyscall movqPCPU(CURPCB),%rax + testq $PCB_FULL_IRET,PCB_FLAGS(%rax) + jne 3f +1: /* Check for and handle AST's on return to userland. */ + cli + movqPCPU(CURTHREAD),%rax + testl $TDF_ASTPENDING | TDF_NEEDRESCHED,TD_FLAGS(%rax) + je 2f + sti + movq%rsp, %rdi + callast + jmp 1b +2: /* Restore preserved registers. */ + MEXITCOUNT + movqTF_RDI(%rsp),%rdi /* bonus; preserve arg 1 */ + movqTF_RSI(%rsp),%rsi /* bonus: preserve arg 2 */ + movqTF_RDX(%rsp),%rdx /* return value 2 */ + movqTF_RAX(%rsp),%rax /* return value 1 */ + movqTF_RBX(%rsp),%rbx /* C preserved */ + movqTF_RBP(%rsp),%rbp /* C preserved */ + movqTF_R12(%rsp),%r12 /* C preserved */ + movqTF_R13(%rsp),%r13 /* C preserved */ + movqTF_R14(%rsp),%r14 /* C preserved */ + movqTF_R15(%rsp),%r15 /* C preserved */ + movqTF_RFLAGS(%rsp),%r11/* original %rflags */ + movqTF_RIP(%rsp),%rcx /* original %rip */ + movqTF_RSP(%rsp),%r9/* user stack pointer */ + movq%r9,%rsp/* original %rsp */ + swapgs + sysretq +3: /* Requested full context restore, use doreti for that. */ MEXITCOUNT jmp doreti ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] adding -Wmissing-include-dirs to CWARNFLAGS
On Thu Apr 7 11, Garrett Cooper wrote: > On Thu, Apr 7, 2011 at 2:22 PM, Alexander Best wrote: > > On Thu Apr 7 11, Garrett Cooper wrote: > >> On Thu, Apr 7, 2011 at 1:53 PM, Garrett Cooper wrote: > >> > On Thu, Apr 7, 2011 at 11:55 AM, Alexander Best > >> > wrote: > >> >> hi there, > >> >> > >> >> i'd like to propose adding -Wmissing-include-dirs to CWARNFLAGS. this > >> >> will let > >> >> tinderbox fail, if any new kernel code was committed with (a) broken > >> >> include > >> >> dir(s). > >> >> > >> >> i ran a test via > >> >> > >> >> make toolchains > >> >> make MAKE_JUST_KERNELS=yes tinderbox > >> >> > >> >> and nothing seemed to go wrong with the extra warning enabled. i even > >> >> found a > >> >> missing include dir, which should be fixed by the attached patch. > >> >> > >> >> opinions? > >> >> > >> >> so far i've only tested this with gcc. i think someone on > >> >> #freebsd-clang told > >> >> me that -Wmissing-include-dirs is a noop for clang (for whatever > >> >> reasons). > >> > > >> > make -f /etc/src.conf -VMODULES_OVERRIDE and make -f /etc/src.conf > >> > -VMODULES_OVERRIDE say... (tinderbox should also really ignore these > >> > files, but it doesn't currently)? > > > > otaku% make -f /etc/src.conf -VMODULES_OVERRIDE > > netgraph/netgraph netgraph/socket netgraph/bluetooth/bluetooth > > netgraph/bluetooth/hci netgraph/bluetooth/l2cap netgraph/bluetooth/socket > > netgraph/bluetooth/ubt tmpfs sound/sound sound/driver/hda usb/uhid procfs > > pseudofs linux linprocfs linsysfs lindev usb/quirk geom opensolaris dtrace > > cyclic nfsclient krpc nfs_common nfslock > > otaku% make -f /etc/make.conf -VMODULES_OVERRIDE > > netgraph/netgraph netgraph/socket netgraph/bluetooth/bluetooth > > netgraph/bluetooth/hci netgraph/bluetooth/l2cap netgraph/bluetooth/socket > > netgraph/bluetooth/ubt tmpfs sound/sound sound/driver/hda usb/uhid procfs > > pseudofs linux linprocfs linsysfs lindev usb/quirk geom opensolaris dtrace > > cyclic nfsclient krpc nfs_common nfslock > > > > ...however i checked and tinderbox *does* ignore src.conf and make.conf. the > > _.* log files show that modules were being build which are not returned by > > the commands above. > > > > i think having this flag would be very useful, because it would force > > people to > > make sure their include dirs are correct. > > > >> > >> Sorry. Second invocation should have been make.conf, not src.conf. > > Ok then. I stand corrected for not having tested out my claim beforehand. > > Yes, I agree that adding this flag in the default set is a good idea. cool. so now we need somebody to make the commit. ;) > > Thanks, > -Garrett -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn commit: r220430 - head/sys/amd64/amd64
> > Author: jhb > > Date: Thu Apr 7 21:32:25 2011 ... > > URL: http://svn.freebsd.org/changeset/base/220430 ... > > I think that this commit (plus r220431) has broken something in my > environment. > After updating to the most recent head I started to get semi-random problems > in > various areas: > - named would consistently fail to start, but with different errors > (assertions) > - ^Z and fg result in a process getting SIGSEGV > - X sometimes fails to start complaining about failed VT switch > > Reverting just these two commits restores sanity. > > Just in case, my processor is AMD (arch is obviously amd64). I experienced similar problems (UP amd64, AMD Mobile Athlon64 processor) and reported it to kib@ and jhb@. b. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vmware-tools-freebsd && "No drivers for x.org version: 7.6.5."
El día Friday, April 08, 2011 a las 12:17:03PM +0200, Dimitry Andric escribió: > On 2011-04-08 10:42, Matthias Apitz wrote: > >I have FreeBSD 9-CURRENT up and running in a VMware Workstation 7.x and > >I tried to install the vmware-tools-freebsd of VMware to get the driver > >for Xorg, but it seems that X.org 7.6.5. is not supported. My other VM > >runs a 8-CURRENT with X.org 7.4_1 which works fine. > > > >Any idea how to solve this? Should I go back to X.org 7.4_1 in > >9-CURRENT? Or should I fake the vmware-tools installer to see X.org as > >/.4 while it is 7.6.5? > > X.org 7.5 already has VMware drivers, so you can just install the > x11-drivers/xf86-input-vmmouse and x11-drivers/xf86-video-vmware ports. > > Alternatively, run "make config" in x11-drivers/xorg-drivers, check the > "VMMOUSE" and "VMWARE" entries, and rebuild this meta-port. Dimitry, Thanks for your kind & fast answer; does this also mean that I could completely get rid of the VMware' vmware-tools-freebsd? I'm using on the 8-CURRENT system the emulators/open-vom-tools and will install them in the 9-CURRENT too. Thanks again matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn commit: r220430 - head/sys/amd64/amd64
on 08/04/2011 00:32 John Baldwin said the following: > Author: jhb > Date: Thu Apr 7 21:32:25 2011 > New Revision: 220430 > URL: http://svn.freebsd.org/changeset/base/220430 > > Log: > If a system call does not request a full interrupt return, use a fast > path via the sysretq instruction to return from the system call. This was > removed in 190620 and not quite fully restored in 195486. This resolves > most of the performance regression in system call microbenchmarks between > 7 and 8 on amd64. > > Reviewed by:kib > MFC after: 1 week I think that this commit (plus r220431) has broken something in my environment. After updating to the most recent head I started to get semi-random problems in various areas: - named would consistently fail to start, but with different errors (assertions) - ^Z and fg result in a process getting SIGSEGV - X sometimes fails to start complaining about failed VT switch Reverting just these two commits restores sanity. Just in case, my processor is AMD (arch is obviously amd64). > Modified: > head/sys/amd64/amd64/exception.S > > Modified: head/sys/amd64/amd64/exception.S > == > --- head/sys/amd64/amd64/exception.S Thu Apr 7 21:29:34 2011 > (r220429) > +++ head/sys/amd64/amd64/exception.S Thu Apr 7 21:32:25 2011 > (r220430) > @@ -339,6 +339,9 @@ IDTVEC(prot) > * and the new privilige level. We are still running on the old user stack > * pointer. We have to juggle a few things around to find our stack etc. > * swapgs gives us access to our PCPU space only. > + * > + * We do not support invoking this from a custom %cs or %ss (e.g. using > + * entries from an LDT). > */ > IDTVEC(fast_syscall) > swapgs > @@ -380,6 +383,36 @@ IDTVEC(fast_syscall) > movq%rsp,%rdi > callsyscall > movqPCPU(CURPCB),%rax > + testq $PCB_FULL_IRET,PCB_FLAGS(%rax) > + jne 3f > +1: /* Check for and handle AST's on return to userland. */ > + cli > + movqPCPU(CURTHREAD),%rax > + testl $TDF_ASTPENDING | TDF_NEEDRESCHED,TD_FLAGS(%rax) > + je 2f > + sti > + movq%rsp, %rdi > + callast > + jmp 1b > +2: /* Restore preserved registers. */ > + MEXITCOUNT > + movqTF_RDI(%rsp),%rdi /* bonus; preserve arg 1 */ > + movqTF_RSI(%rsp),%rsi /* bonus: preserve arg 2 */ > + movqTF_RDX(%rsp),%rdx /* return value 2 */ > + movqTF_RAX(%rsp),%rax /* return value 1 */ > + movqTF_RBX(%rsp),%rbx /* C preserved */ > + movqTF_RBP(%rsp),%rbp /* C preserved */ > + movqTF_R12(%rsp),%r12 /* C preserved */ > + movqTF_R13(%rsp),%r13 /* C preserved */ > + movqTF_R14(%rsp),%r14 /* C preserved */ > + movqTF_R15(%rsp),%r15 /* C preserved */ > + movqTF_RFLAGS(%rsp),%r11/* original %rflags */ > + movqTF_RIP(%rsp),%rcx /* original %rip */ > + movqTF_RSP(%rsp),%r9/* user stack pointer */ > + movq%r9,%rsp/* original %rsp */ > + swapgs > + sysretq > +3: /* Requested full context restore, use doreti for that. */ > MEXITCOUNT > jmp doreti > -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vmware-tools-freebsd && "No drivers for x.org version: 7.6.5."
On 2011-04-08 10:42, Matthias Apitz wrote: I have FreeBSD 9-CURRENT up and running in a VMware Workstation 7.x and I tried to install the vmware-tools-freebsd of VMware to get the driver for Xorg, but it seems that X.org 7.6.5. is not supported. My other VM runs a 8-CURRENT with X.org 7.4_1 which works fine. Any idea how to solve this? Should I go back to X.org 7.4_1 in 9-CURRENT? Or should I fake the vmware-tools installer to see X.org as /.4 while it is 7.6.5? X.org 7.5 already has VMware drivers, so you can just install the x11-drivers/xf86-input-vmmouse and x11-drivers/xf86-video-vmware ports. Alternatively, run "make config" in x11-drivers/xorg-drivers, check the "VMMOUSE" and "VMWARE" entries, and rebuild this meta-port. Btw, I have no idea why these drivers are not enabled by default. They would seem very useful in a default X.org installation. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
vmware-tools-freebsd && "No drivers for x.org version: 7.6.5."
Hello, I have FreeBSD 9-CURRENT up and running in a VMware Workstation 7.x and I tried to install the vmware-tools-freebsd of VMware to get the driver for Xorg, but it seems that X.org 7.6.5. is not supported. My other VM runs a 8-CURRENT with X.org 7.4_1 which works fine. Any idea how to solve this? Should I go back to X.org 7.4_1 in 9-CURRENT? Or should I fake the vmware-tools installer to see X.org as /.4 while it is 7.6.5? Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
