- Original Message -
From: "Duane H. Hesser"
To: hack...@freebsd.org
Date: Fri, 28 Jan 2011 12:43:12 -0800
Subject: NVIDIA (port) driver fails to create /dev/nvidactl; 8.2Prerelease
> I am attempting ... BLA, BLA, ...
> NVIDIA: could not open the device file /dev/nvidiactl (No such file
On 28 January 2011 23:37, Gleb Kurtsou wrote:
>> * The dtrace output I've send is from around thirty seconds of
>> operation, so around 2000 PHP runs. (PHP in this case is FastCGI, so
>> the processes are persistent instead of constantly respawning). In
>> these 2000 runs there have been around 2
On (28/01/2011 22:59), Ivan Voras wrote:
> On 28 January 2011 22:18, Gleb Kurtsou wrote:
>
> > You could try replacing rwlock with plain mutex to check if there are
> > priority propagation issues among readers/writers.
>
> How would that manifest? (i.e. how would it be detectable)
Benchmark. If
On 28 January 2011 22:18, Gleb Kurtsou wrote:
> You could try replacing rwlock with plain mutex to check if there are
> priority propagation issues among readers/writers.
How would that manifest? (i.e. how would it be detectable)
> SX locks should also
> work but would likely to be a considerab
does "kldstat | grep nvidia" show anything? if not
kldload nvidia
or
echo nvidia_load=\"YES\" >> /boot/loader.conf
reboot
does this change anything? you seem to be missing /dev/nvidiactl
which probably means that the nvidia module is not loaded
On Fri, Jan 28, 2011 at 12:43:12PM -0800, Duane H
I am attempting to replace the 'nv' X11 driver with the "official"
nvidia driver from ithe x11/nvidia-driver port, in order to handle
the AVCHD video files from my Canon HF S20.
I have been trying for several days now, having read the nvidia
README file in /usr/local/share and everything Google ha
On (28/01/2011 18:20), Ivan Voras wrote:
> On 28 January 2011 16:25, Dan Nelson wrote:
>
> > My guess would be:
> >
> > kern/vfs_cache.c:151 static struct rwlock cache_lock;
> > kern/vfs_cache.c:152 RW_SYSINIT(vfscache, &cache_lock, "Name Cache");
> >
> > The CACHE_*LOCK() macros.c in vfs_cache u
No - this is entirely a user-space project. Those are both things I'd
like to add to jails after I get through the mess on the ofhter side of
the kernel divide.
- Jamie
On 01/27/11 13:30, Kostik Belousov wrote:
On Thu, Jan 27, 2011 at 10:37:22AM -0700, Jamie Gritton wrote:
It's in the the subv
On Fri, Jan 28, 2011 at 11:23 AM, John Baldwin wrote:
> On Friday, January 28, 2011 2:14:45 pm Matthew Fleming wrote:
>> On Fri, Jan 28, 2011 at 11:00 AM, John Baldwin wrote:
>> > On Friday, January 28, 2011 12:41:08 pm Matthew Fleming wrote:
>> >> I spent a few days chasing down a bug and I'm wo
On Friday, January 28, 2011 2:14:45 pm Matthew Fleming wrote:
> On Fri, Jan 28, 2011 at 11:00 AM, John Baldwin wrote:
> > On Friday, January 28, 2011 12:41:08 pm Matthew Fleming wrote:
> >> I spent a few days chasing down a bug and I'm wondering if a loader
> >> change would be appropriate.
> >>
>
On Fri, Jan 28, 2011 at 11:00 AM, John Baldwin wrote:
> On Friday, January 28, 2011 12:41:08 pm Matthew Fleming wrote:
>> I spent a few days chasing down a bug and I'm wondering if a loader
>> change would be appropriate.
>>
>> So we have these new front-panel LCDs, and like everything these days
On Friday, January 28, 2011 12:41:08 pm Matthew Fleming wrote:
> I spent a few days chasing down a bug and I'm wondering if a loader
> change would be appropriate.
>
> So we have these new front-panel LCDs, and like everything these days
> it's a SoC. Normally it presents to FreeBSD as a USB comm
I spent a few days chasing down a bug and I'm wondering if a loader
change would be appropriate.
So we have these new front-panel LCDs, and like everything these days
it's a SoC. Normally it presents to FreeBSD as a USB communications
device (ucom), but when the SoC is sitting in its own boot loa
On 28 January 2011 16:25, Dan Nelson wrote:
> My guess would be:
>
> kern/vfs_cache.c:151 static struct rwlock cache_lock;
> kern/vfs_cache.c:152 RW_SYSINIT(vfscache, &cache_lock, "Name Cache");
>
> The CACHE_*LOCK() macros.c in vfs_cache use cache_lock, so you've got lots
> of possible contentio
On 28 January 2011 16:15, John Baldwin wrote:
> On Friday, January 28, 2011 8:46:07 am Ivan Voras wrote:
>> I have this situation on a PHP server:
>>
>> 36623 www 1 76 0 237M 30600K *Name 6 0:14 47.27% php-cgi
>> 36638 www 1 76 0 237M 30600K *Name 3 0:14 46.97%
In the last episode (Jan 28), Ivan Voras said:
> I have this situation on a PHP server:
>
> 36623 www 1 760 237M 30600K *Name 6 0:14 47.27% php-cgi
> 36638 www 1 760 237M 30600K *Name 3 0:14 46.97% php-cgi
> 36628 www 1 1050 237M 30600K *Name 2
On Friday, January 28, 2011 8:46:07 am Ivan Voras wrote:
> I have this situation on a PHP server:
>
> 36623 www 1 760 237M 30600K *Name 6 0:14 47.27% php-cgi
> 36638 www 1 760 237M 30600K *Name 3 0:14 46.97% php-cgi
> 36628 www 1 1050 237M 30600K
I have this situation on a PHP server:
36623 www 1 760 237M 30600K *Name 6 0:14 47.27% php-cgi
36638 www 1 760 237M 30600K *Name 3 0:14 46.97% php-cgi
36628 www 1 1050 237M 30600K *Name 2 0:14 46.88% php-cgi
36627 www 1 1050 23
18 matches
Mail list logo
