Re: PCIOCGETCONF/PCIOCREAD requires write permission?

Andrew Gallatin wrote: Kenneth D. Merry writes: As for PCIOCREAD, it only allows reading of PCI registers, so the question there is whether there are any potential security implications to allowing non-root users to read PCI registers. If reading configuration registers caused

Arg! Siginfo and pthreads again

Again I've forgotten that SIGINFO dumps the pthread info and created several gigabytes of /tmp files: rt% rm /tmp/uthread* /bin/rm: Argument list too long. I don't consider it bad form to use SIGINFO to see if processes are still around without first installing a SIGINFO handler. Am I the

VMware hanging -- Memory deadlock?

I have a vaio z505le with 192MB running 4.2-STABLE (cvsupped today). I've been trying to get vmware running properly on it. I first configured vmware on the vaio, created a win2k type virtual disk, set ram in the VM to 80M, and copied a happily working win2k virtual disk from another

Re: Arg! Siginfo and pthreads again

On Sun, 3 Dec 2000, Peter Dufault wrote: Again I've forgotten that SIGINFO dumps the pthread info and created several gigabytes of /tmp files: rt% rm /tmp/uthread* /bin/rm: Argument list too long. I don't consider it bad form to use SIGINFO to see if processes are still around without

More logging questions....

I have a machine running FreeBSD 4.2, and when it boots up, I can watch the console, and everything is highlighted (bright white), then I guess it moves on to starting processes from init, rc.local and such, and the console is loggin stuff on the screen in normal text (not highlighted). This

most efficient/precise monotonic clock for I686_CPU?

What is the most efficient way to get a relatively precise (say, at least millisecond) time value that is guaranteed to inrease monotonically (even if, say, xntpd adjust the system clock), either portable, or FreeBSD-specific? Is there some user library for using the Pentium performance clock

Re: vm_pageout_scan badness

I'm going to take this off of hackers and to private email. My reply will be via private email. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

no lo0 device on kernel boot

I've beat up my friends enough on this one... 4.1-RELEASE on an i586 scsi box from micron, de0 ethernet and ppp0 running out a serial port. I built a custom kernel (make depend, make, make install) and booted it. After much hair-pulling, it turns out there was no lo0 device configured. So I

Re: vm_pageout_scan badness

Matt Dillon wrote: I'm going to take this off of hackers and to private email. My reply will be via private email. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the

Re: vm_pageout_scan badness

:errr then keep me in the CC : :it's interesting : :-- : __--_|\ Julian Elischer : / \ [EMAIL PROTECTED] Sure thing. Anyone else who wants to be in the Cc, email me. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with

M_ZERO patches.

I'd like to commit a large chunk of the remaining M_ZERO patches I've collected up later this week. These patches touch various parts of the system, so I'd apreciate if people could take a look at them. http://www.maths.tcd.ie/~dwmalone/mzero.patch I've listed the files it effects

Re: Arg! Siginfo and pthreads again

On Sun, 3 Dec 2000, Peter Dufault wrote: Again I've forgotten that SIGINFO dumps the pthread info and created several gigabytes of /tmp files: rt% rm /tmp/uthread* /bin/rm: Argument list too long. I don't consider it bad form to use SIGINFO to see if processes are still

Re: PCIOCGETCONF/PCIOCREAD requires write permission?

In message [EMAIL PROTECTED] Andrew Gallatin writes: : I'd vote for leaving the access permissions as is. I'd agree with that. We don't know that all PCI hardware will not cause problems when arbitrary locations in config space are read. Warner To Unsubscribe: send mail to [EMAIL PROTECTED]

Re: vm_pageout_scan badness

I'm going to take this off of hackers and to private email. My reply will be via private email. Actually, I was enjoying the discussion, since I was learning something in the process of hearing you debug this remotely. It sure beats the KR vs. ANSI discussion. :) Nate To

Re: vm_pageout_scan badness

: I'm going to take this off of hackers and to private email. My reply : will be via private email. : :Actually, I was enjoying the discussion, since I was learning something :in the process of hearing you debug this remotely. : :It sure beats the KR vs. ANSI discussion. :) : :Nate

Re: vm_pageout_scan badness

ok, since I got about 6 requests in four hours to be Cc'd, I'm throwing this back onto the list. Sorry for the double-response that some people are going to get! I am going to include some additional thoughts in the front, then break to my originally private email response.