Re:dtrace filename lookups from fd (Serg Slobodyanyuk)
> > > Date: Fri, 1 Jun 2012 17:00:20 +0100 > From: "Steven Hartland" > > As a first foray into dtrace I wanted to create a little > script which shows the amount of disk read / write activity. > > Now the DtraceToolkit includes rwsnoop but this uses Solaris > specific requests and on looking around it seems like > using rwsnoop vn_fullpath may be the way to go. > > Has anyone done anything similar to this before or has any > tips on going about this? > >Regards >Steve > HI, Some times ago I decided to do the same - port rwsnoop to FreeBSD(8.2 R). FreeBSD vfs code quiet different from solaris code so I asked for help Kostik and he directed me to vn_fullpath() routine after that I wrote working port of rwsnoop. But script generate alot of errors like "invalid address (0x) in action" even on data that should be there(from my point of view). After several tries to debug it I left it as is. You can run it with "| grep -v invalid" or direct STDERR to /dev/null. Maybe Hackers could look at it and say what's wrong :-) Changed part of code: this->fp = &(curthread->td_proc->p_fd->fd_ofiles[self->fd]); this->vp = (struct vnode *)((*(this->fp))->f_vnode); this->cache_dst = &((this->vp)->v_cache_dst); this->ncp = (&((this->vp)->v_cache_dst)) != NULL ? (&((this->vp)->v_cache_dst))->tqh_first : 0; self->ncname = this->ncp ? (this->ncp->nc_name != 0 ? stringof(this->ncp->nc_name) : "") : "" Link to script: https://docs.google.com/open?id=0B7olr28SbDyNZktLMG51UHVxNW8 //Br. Serg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: nvidia-driver-295.49 is highly unstable
On 06/04/12 03:12, Chris wrote: On Sun, 27 May 2012 20:50:59 -0300 Mario Lobo wrote: On Sunday 27 May 2012 14:05:16 Yuri wrote: On 05/27/2012 10:01, David Wolfskill wrote: So, at least in my case, I respectfully disagree with the assessment in the Subject. i386 is one difference (I use amd64) FX 770M is another difference (I use 9400GT) I also have everything updated with the similar portmaster command. Yuri I use 8-STABLE amd64 with 295.40/9800GT and been using it since I can remember. Except for some quircks with early VirtualBox versions, I have NEVER had a problem with ANY version of the driver I've used. FWIW uname -a FreeBSD udns 8.3-STABLE FreeBSD 8.3-STABLE #2: Sun May 20 22:25:10 PDT 2012 root@udns:/usr/obj/usr/src/sys/AMD64 amd64 Xorg.0.log NVIDIA GPU GeForce 7800 GT (G70) PCI:*(0:1:0:0) 10de:0092:3842:c518 NVIDIA Corporation G70 [GeForce 7800 GT] rev 161 NVIDIA dlloader X Driver 295.40 Thu Apr 5 21:27:46 PDT 2012 Has always worked w/o any issues -- ever. Hi Everyone, You know what it could be? I just had to rebuild my user-land because of KDE updates and I use variables in my make.conf to switch between base GCC and CLANG. I forgot to switch back to base gcc before compiling the nvidia driver. I installed the driver and rebooted, xorg came up but as soon as I logged in, kwin crashed, then the machine kernel panicked and rebooted. I rebooted and crashed a few more times before realizing what I had done. I recompiled the driver with GCC and the machine has been rock-stable with the nvidia driver. Maybe the OP has done the same thing and not realized it? Ta Peg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: [Hash function Ipv4]
Hi, I did some tests with some subnets Ip /24 and I will share the results. I got very good results with this configuration: Hash table's size: Let x be the number of ip. Y = x*2, then size_table = 'The power of 2 closest to Y, and greater than or equal to Y'. Hash Function: return Ip_in_network_byte_order % size_table; Collision's case: In this case i have used research quadratic: ((unsigned int)( hash_function + 0.5*k + 0.5*k*k )) % size_table ; -- on the other hand When I have used Random Ip, that does not belong to the same subnet ip: unsigned int HASH = 2039; uint32_t h; h = key % HASH; key /= HASH; h ^= key % HASH; h ^= key / HASH; Suggested to me by Poul-Henning Kamp (thanks) works much better. That's all. Bye Enrico ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC] last(1) with security.bsd.see_other_uids support
On Sun, Jun 03, 2012 at 08:42:04PM -0500, Bryan Drewery wrote:
> Hi,
>
> I've written up a patch to add some privacy to last(1) while still
> giving non-privileged users access to their own login history.
>
> This is still a work in progress. I am reaching out to make sure my
> approach is proper and to get some input on code sharing. My goal is to
> add this support to w(1) and who(1) as well. FWIW I have been running a
> similar patch on my own shared-hosting systems (pre-utmpx) for a few years.
>
> Changes:
>
> * Added utmp group
> * All utmpx files are 660 root:utmp
> * last(1) runs setgid(utmp) and drops this as soon as the utmpx files
> are opened.
> * Users in the wheel or utmp group can see all entries
> * IFF security.bsd.see_other_uids=0: users only see their own entries,
> as well as shutdown/boot/init times.
> * If security.bsd.see_other_uids=1, all entries are always shown, as it
> does now.
>
> Justifications:
>
> Why the changes? This makes sense for shared hosting environments where
> jails are not practical. A user should be able to see their own login
> history, to see if someone has been accessing their account, but not to
> see the IPs of other users. The intention is *not* to disallow them to
> see that other users of the system. Obviously they can just cat
> /etc/passwd. This is just about IP privacy.
>
> Why the setgid? Allow reading the entries, but disallow directly opening
> the utx files. I've seen some shared hosts incorrectly chmod 0
> /usr/bin/last, but still leave the utmp files wide open for reading!
>
> Why the utmp group? It's consistent with other systems (OpenBSD, Linux),
> and allows giving a user access to see all entries, without granting
> them wheel or allowing a non-privileged user to run as setgid(wheel). It
> also helps mitigates security concerns by using a specific group only
> having extra privilege to utmpx files.
>
> I originally had not planned for security.bsd.see_other_uids, but
> considering POLA and consistency, it makes sense.
I think the proposed change does make sense.
> Questions:
>
> To add this support to w(1) and who(1), I want to share the
> is_user_restricted() function among all 3 binaries. I don't think this
> really belongs in libc/libutil, but maybe it does. I could just add a
> shared file into usr.bin/last/ and link it in with all 3, but I don't
> really like this approach as then usr.bin/{w,who} would depend on
> usr.bin/last.
A library is definiately a better place, although then I wouldn't pass
see_other_uids as an argument, but obtain it within the function itself.
Some comments to the code below.
> -/var/log/utx.log 644 3 *@01T05 B
> +/var/log/utx.log root:utmp 660 3 *@01T05 B
Why does the utmp group has to have write access to this file.
If I understand correctly it just reads from it, no?
> --- a/lib/libc/gen/pututxline.c
> +++ b/lib/libc/gen/pututxline.c
> @@ -179,10 +179,13 @@
> int fd;
>
> /* Initialize utx.active with a single BOOT_TIME record. */
> - fd = _open(_PATH_UTX_ACTIVE, O_CREAT|O_RDWR|O_TRUNC, 0644);
> + fd = _open(_PATH_UTX_ACTIVE, O_CREAT|O_RDWR|O_TRUNC, 0660);
> if (fd < 0)
> return;
> - _write(fd, fu, sizeof(*fu));
> + if (fchown(fd, 0, _UTMP_GID) < 0)
> + warnx("Unable to set root:utmp on " _PATH_UTX_ACTIVE);
> + else
> + _write(fd, fu, sizeof(*fu));
> _close(fd);
> }
fchown() doesn't hurt here, I guess, but I would use UID_ROOT instead of 0.
Doing explicit fchmod(2) might make sense too, as umask might cut some
of the requested permissions.
> @@ -269,13 +272,18 @@
> vec[1].iov_len = l;
> l = htobe16(l);
>
> - fd = _open(_PATH_UTX_LOG, O_CREAT|O_WRONLY|O_APPEND, 0644);
> + fd = _open(_PATH_UTX_LOG, O_CREAT|O_WRONLY|O_APPEND, 0660);
> if (fd < 0)
> return (-1);
> - if (_writev(fd, vec, 2) == -1)
> + if (fchown(fd, 0, _UTMP_GID) < 0) {
> + warnx("Unable to set root:utmp on " _PATH_UTX_LOG);
> error = errno;
> - else
> - error = 0;
> + } else {
> + if (_writev(fd, vec, 2) == -1)
> + error = errno;
> + else
> + error = 0;
> + }
> _close(fd);
> errno = error;
> return (error == 0 ? 0 : 1);
This looks very familiar to the above. Maybe we can get rid of this code
duplication?
> /*
> + * Return whether or not the given user can see all entries or not
> + */
> +static int
> +is_user_restricted(struct passwd *pw, int see_other_uids)
> +{
> + int restricted = 1; /* Default to restricted access */
> + gid_t *groups;
> + int ngroups, gid, cnt;
> + long ngroups_max;
> + struct group *group;
> +
> + if (geteuid() == 0 || see_other_uids)
> + restricted = 0;
> + else {
> + /* Check if the user is in a privileged group */
> + ngroups_max =
Re: [RFC] last(1) with security.bsd.see_other_uids support
On 6/4/2012 4:42 AM, Pawel Jakub Dawidek wrote:
> On Sun, Jun 03, 2012 at 08:42:04PM -0500, Bryan Drewery wrote:
>> Questions:
>>
>> To add this support to w(1) and who(1), I want to share the
>> is_user_restricted() function among all 3 binaries. I don't think this
>> really belongs in libc/libutil, but maybe it does. I could just add a
>> shared file into usr.bin/last/ and link it in with all 3, but I don't
>> really like this approach as then usr.bin/{w,who} would depend on
>> usr.bin/last.
>
> A library is definiately a better place, although then I wouldn't pass
> see_other_uids as an argument, but obtain it within the function itself.
Pawel,
Thank you for the input.
I will cleanup your findings and experiment with moving it into the library.
More comments below.
>
> Some comments to the code below.
>
>> -/var/log/utx.log644 3 *@01T05 B
>> +/var/log/utx.logroot:utmp 660 3 *@01T05 B
>
> Why does the utmp group has to have write access to this file.
> If I understand correctly it just reads from it, no?
I suppose I did this from experience and other custom changes. It does
make sense to limit it to root writing, but then apps like screen can
not write to it if not setuid root.
That's outside the scope of this change though and potentially wrong, so
I will make this 640 for now.
>
>> --- a/lib/libc/gen/pututxline.c
>> +++ b/lib/libc/gen/pututxline.c
>> @@ -179,10 +179,13 @@
>> int fd;
>>
>> /* Initialize utx.active with a single BOOT_TIME record. */
>> -fd = _open(_PATH_UTX_ACTIVE, O_CREAT|O_RDWR|O_TRUNC, 0644);
>> +fd = _open(_PATH_UTX_ACTIVE, O_CREAT|O_RDWR|O_TRUNC, 0660);
>> if (fd < 0)
>> return;
>> -_write(fd, fu, sizeof(*fu));
>> +if (fchown(fd, 0, _UTMP_GID) < 0)
>> +warnx("Unable to set root:utmp on " _PATH_UTX_ACTIVE);
>> +else
>> +_write(fd, fu, sizeof(*fu));
>> _close(fd);
>> }
>
> fchown() doesn't hurt here, I guess, but I would use UID_ROOT instead of 0.
> Doing explicit fchmod(2) might make sense too, as umask might cut some
> of the requested permissions.
>
>> @@ -269,13 +272,18 @@
>> vec[1].iov_len = l;
>> l = htobe16(l);
>>
>> -fd = _open(_PATH_UTX_LOG, O_CREAT|O_WRONLY|O_APPEND, 0644);
>> +fd = _open(_PATH_UTX_LOG, O_CREAT|O_WRONLY|O_APPEND, 0660);
>> if (fd < 0)
>> return (-1);
>> -if (_writev(fd, vec, 2) == -1)
>> +if (fchown(fd, 0, _UTMP_GID) < 0) {
>> +warnx("Unable to set root:utmp on " _PATH_UTX_LOG);
>> error = errno;
>> -else
>> -error = 0;
>> +} else {
>> +if (_writev(fd, vec, 2) == -1)
>> +error = errno;
>> +else
>> +error = 0;
>> +}
>> _close(fd);
>> errno = error;
>> return (error == 0 ? 0 : 1);
>
> This looks very familiar to the above. Maybe we can get rid of this code
> duplication?
>
>> /*
>> + * Return whether or not the given user can see all entries or not
>> + */
>> +static int
>> +is_user_restricted(struct passwd *pw, int see_other_uids)
>> +{
>> +int restricted = 1; /* Default to restricted access */
>> +gid_t *groups;
>> +int ngroups, gid, cnt;
>> +long ngroups_max;
>> +struct group *group;
>> +
>> +if (geteuid() == 0 || see_other_uids)
>> +restricted = 0;
>> +else {
>> +/* Check if the user is in a privileged group */
>> +ngroups_max = sysconf(_SC_NGROUPS_MAX) + 1;
>
> sysconf(3) can fail, at least in theory, so maybe:
>
> ngroups_max = sysconf(_SC_NGROUPS_MAX);
> if (ngroups_max == -1)
> ngroups_max = NGROUPS_MAX;
> ngroups_max++;
>
>> +if ((groups = malloc(sizeof(gid_t) * (ngroups_max))) == NULL)
>> +err(1, "malloc");
>
> When this goes into library you has to return an error here.
>
>> +ngroups = ngroups_max;
>> +(void) getgrouplist(pw->pw_name, pw->pw_gid, groups, &ngroups);
>
> You know that getgrouplist(3) returns groups from the system files and
> not actuall process groups? Was that intended? IMHO you should use
> getgroups(2) here. And again you ignore return value.
Most of this section was copied from usr.bin/id/id.c
I will review both and take your findings into consideration.
>
>> +for (cnt = 0; cnt < ngroups; ++cnt) {
>> +gid = groups[cnt];
>> +group = getgrgid(gid);
>> +/* User is in utmp or wheel group, they can see all */
>> +if (strncmp("utmp", group->gr_name, 4) == 0 ||
>> strncmp("wheel",
>> group->gr_name, 5) == 0) {
>
> strncmp(3) is bad idea here. If the user is a member of utmpfoo group or
> wheelx group you turn off restrictions.
Woops!
>
> I'd really use getgroups(2) and look for GID_WHEEL or _UTMP_GID.
>
>> @@ -212,7 +255,30 @@ struct idtab {
>> /* Load the last
Re: [RFC] last(1) with security.bsd.see_other_uids support
On 6/4/2012 4:42 AM, Pawel Jakub Dawidek wrote: > A library is definiately a better place, although then I wouldn't pass > see_other_uids as an argument, but obtain it within the function itself. Does libc make sense for this? I'm thinking yes since it's where the utx functions live. In particular this change seems to make sense in getutxent(3). Though I do not want to violate POSIX... The endutxent(), getutxent(), getutxid(), getutxline() and setutxent() functions are expected to conform to IEEE Std 1003.1-2008 (``POSIX.1''). Bryan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: nvidia-driver-295.49 is highly unstable
On 4-6-2012 9:54, Pegasus Mc Cleaft wrote: > I forgot to switch back to base gcc before > compiling the nvidia driver. I installed the driver and rebooted, xorg > came up but as soon as I logged in, kwin crashed, then the machine > kernel panicked and rebooted. I rebooted and crashed a few more times > before realizing what I had done. I recompiled the driver with GCC and > the machine has been rock-stable with the nvidia driver. > > Maybe the OP has done the same thing and not realized it? That would account for what I'm seeing too and I know I've compiled nvidia-driver with clang. Except in my case it's Xfce4 and no panics, but completely unusable (fonts were too large, offsets calculated wrongly, terminal emulation was like opening something in vi with TERM=dumb, mouse movement shocked, machine under constant load). -- Mel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: nvidia-driver-295.49 is highly unstable
On Mon, Jun 04, 2012 at 03:53:26PM +0200, Mel Flynn wrote: > On 4-6-2012 9:54, Pegasus Mc Cleaft wrote: > > > I forgot to switch back to base gcc before > > compiling the nvidia driver. I installed the driver and rebooted, xorg > > came up but as soon as I logged in, kwin crashed, then the machine > > kernel panicked and rebooted. I rebooted and crashed a few more times > > before realizing what I had done. I recompiled the driver with GCC and > > the machine has been rock-stable with the nvidia driver. > > > > Maybe the OP has done the same thing and not realized it? > > That would account for what I'm seeing too and I know I've compiled > nvidia-driver with clang. Except in my case it's Xfce4 and no panics, > but completely unusable (fonts were too large, offsets calculated > wrongly, terminal emulation was like opening something in vi with > TERM=dumb, mouse movement shocked, machine under constant load). FWIW, a couple of weeks ago, I started (also) tracking stable/9 daily with the following in /etc/src.conf: PORTS_MODULES=x11/nvidia-driver CC=clang CXX=clang++ CPP=clang-cpp Given that, as well as the following excerpt from this morning's typescript from the build: ... ===> nvidia-driver-295.49 depends on file: /usr/local/libdata/pkgconfig/xorg-server.pc - found ===> nvidia-driver-295.49 depends on shared library: GL.1 - found ===> Configuring for nvidia-driver-295.49 ===> Building for nvidia-driver-295.49 ===> src (all) @ -> /usr/src/sys machine -> /usr/src/sys/i386/include x86 -> /usr/src/sys/x86/include awk -f @/tools/makeobjops.awk @/kern/device_if.m -h ... awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h clang -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"295.49\" -D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O -UDEBUG -U_DEBUG -DNDEBUG -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I. -I@ -I@/contrib/altq -fno-common -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c nvidia_ctl.c clang -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"295.49\" -D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O -UDEBUG -U_DEBUG -DNDEBUG -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I. -I@ -I@/contrib/altq -fno-common -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c nvidia_dev.c I believe I am actually building with clang (on that slice -- I build it with gcc on the other slices). I did find that whether I use gcc or clang, I needed to modify xorg.conf to say: Section "Device" ... Screen 0 Option "UseEdidDpi" "False" # [] EndSection ... Section "Monitor" ... DisplaySize 508317 EndSection to get the font size I had when I was using the nv driver (and to which I had become accustomed). As shown above, though, I'm running FreeBSD/i386. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpMK2TBuZW79.pgp Description: PGP signature
Re: [RFC] last(1) with security.bsd.see_other_uids support
Justifications: Why the changes? This makes sense for shared hosting environments where jails are not practical. jails are NEVER practical, it is only a necessity! Necessity to be able to run stupid software that cannot conform to basic unix standards and require to be run as root or from root or once per server. thank you very much for that patch. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: reverse USB driver - is it possible?
On Monday 04 June 2012 07:00:01 Wojciech Puchar wrote: > > Have a look at: > > > > sys/dev/usb/storage/ustorage_fs.c > > > > Currently just implements a RAM disk. Patches are welcome. > > many answers - contradicting itself. others says hardware is unable to do > so, you say it is done. then - how to use it? any docs? :) When USB was designed, they didn't think about what is called cross-over in the ethernet world. Therefore hardware is typically limited to host or device. Hardware that can do both is called OTG USB hardware. --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: reverse USB driver - is it possible?
When USB was designed, they didn't think about what is called cross-over in the ethernet world. Therefore hardware is typically limited to host or device. Hardware that can do both is called OTG USB hardware. OK fine, i now understand exactly what "OTG" means in eg. microchip microcontrollers. So this few $ things can do this, and expensive PC cannot. So the only way to do this is to make a microcontroller based bridge or there are such solutions already available? actually the only thing i want is CD/DVD USB simulator using file on my laptop or even separate flash memory (pendrive). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC] last(1) with security.bsd.see_other_uids support
On 6/4/2012 8:17 AM, Bryan Drewery wrote: > > > On 6/4/2012 4:42 AM, Pawel Jakub Dawidek wrote: >> A library is definiately a better place, although then I wouldn't pass >> see_other_uids as an argument, but obtain it within the function itself. > > Does libc make sense for this? I'm thinking yes since it's where the utx > functions live. > > In particular this change seems to make sense in getutxent(3). > > Though I do not want to violate POSIX... > > The endutxent(), getutxent(), getutxid(), getutxline() and setutxent() > functions are expected to conform to IEEE Std 1003.1-2008 > (``POSIX.1''). > Found this [1]: An implementation that provides extended security controls may impose implementation-defined restrictions on accessing the user accounting database. In particular, the system may deny the existence of some or all of the user accounting database entries associated with users other than the caller. So POSIX allows this. I will proceed and submit another patch for review soon. Regards, Bryan Drewery bdrewery@freenode, bryan@EFNet [1] http://pubs.opengroup.org/onlinepubs/009695399/functions/getutxid.html signature.asc Description: OpenPGP digital signature
Re: reverse USB driver - is it possible?
On 05/06/2012, at 2:45, Wojciech Puchar wrote: > So the only way to do this is to make a microcontroller based bridge or there > are such solutions already available? > > actually the only thing i want is CD/DVD USB simulator using file on my > laptop or even separate flash memory (pendrive). ISTR someone on the lists was talking about a device by http://i-odd.com which does what you want. I found http://renosite.com/ which is a home brew version of the same basic idea. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: nvidia-driver-295.49 is highly unstable
On 06/04/2012 00:54, Pegasus Mc Cleaft wrote: You know what it could be? I just had to rebuild my user-land because of KDE updates and I use variables in my make.conf to switch between base GCC and CLANG. I forgot to switch back to base gcc before compiling the nvidia driver. I installed the driver and rebooted, xorg came up but as soon as I logged in, kwin crashed, then the machine kernel panicked and rebooted. I rebooted and crashed a few more times before realizing what I had done. I recompiled the driver with GCC and the machine has been rock-stable with the nvidia driver. Maybe the OP has done the same thing and not realized it? Unfortunately, that's not the case. I wish it was. Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
