I have finally got back to this and did the style and vm_map_remove()
return value handling fixes, updated the patches in-place:
http://people.freebsd.org/~nox/dvb/linux-dvb.patch
(for head)
http://people.freebsd.org/~nox/dvb/linux-dvb-8.patch
(for 8.)
On Sun, Jan 30, 2011 at 1
On Friday 18 February 2011 15:10:47 Svatopluk Kraus wrote:
> Hi,
>
> I try to figure out locking strategy in FreeBSD and found 'ichsmb'
> device. There is a mutex which protects smb bus (ichsmb device). For
> example in ichsmb_readw() in sys/dev/ichsmb/ichsmb.c, the mutex is
> locked and a comma
Hi,
I deal with devices (i2c bus, flash memory), which are quite slow,
i.e. some or mostly all operations on it are quite slow. One must wait
for it for rather long time. Use of DELAY() is too expensive and an
inactive (so called unbound) wait isn't permited with mutexes. So, no
priority propagati
Hi,
I try to figure out locking strategy in FreeBSD and found 'ichsmb'
device. There is a mutex which protects smb bus (ichsmb device). For
example in ichsmb_readw() in sys/dev/ichsmb/ichsmb.c, the mutex is
locked and a command is written to bus, then unbounded (but with
timeout) sleep is done (
Sergey,
thanks for your comment - however it was my own mistake
in rt.c ...
static void setSchedPolicy( int policy )
{
struct sched_param schedParam = { 0 };
TRY(sched_getparam(0, &schedParam),-1);
switch ( policy )
{
case SCHED_RR:
case SCHED_FIFO:
schedParam.sched_priori
On Fri, Feb 18, 2011 at 03:58:05AM -0800, Dr. Baud wrote:
>
>
> > First, do you have a console output during the run ? Is it possible
> > that machine paniced ? If not, were there any kernel messages before>
> > reboot ?
> >
> > Second, what is the process you are dumping ? Can you show at least
> First, do you have a console output during the run ? Is it possible
> that machine paniced ? If not, were there any kernel messages before>
> reboot ?
>
> Second, what is the process you are dumping ? Can you show at least
> the procstat -v output for the process ?
Sorry for this late res
On 18 February 2011 14:13, venom wrote:
> On 02/11/2011 11:31 PM, John Baldwin wrote:
>>
>> On Friday, February 11, 2011 7:48:39 am venom wrote:
>>>
>>> Hello.
>>>
>>> i am trying build mcelog
>>>
>>>
>>> FreeBSD 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 #0: Fri Jan 14
>>> 04:15:56
>>> UTC 2011 r
On 17 February 2011 12:50, Mats Lindberg wrote:
> All,
> I have been using a small program /rt) that utilize the sched_setscheduler()
> syscall to set the scheduling policy of a process to SCHED_RR. Been running
> it FBSD 5.x and 6.x. Now when migrating to FBSD 8.1 I get EPERM back at me.
> used t
On 02/11/2011 11:31 PM, John Baldwin wrote:
On Friday, February 11, 2011 7:48:39 am venom wrote:
Hello.
i am trying build mcelog
FreeBSD 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 #0: Fri Jan 14 04:15:56
UTC 2011 root@freebsd:/usr/obj/usr/src/sys/GENERIC amd64
# fetch
http://ftp2.pl.freebsd
On Thu, Feb 17, 2011 at 10:50:06AM +0100, Mats Lindberg wrote:
> All,
> I have been using a small program /rt) that utilize the sched_setscheduler()
> syscall to set the scheduling policy of a process to SCHED_RR. Been running
> it FBSD 5.x and 6.x. Now when migrating to FBSD 8.1 I get EPERM back a
On 04/02/2011, at 13:26, Daniel O'Connor wrote:
> I only have about 10 milliseconds of buffering (96kbyte FIFO, 8Mbyte/sec) in
> the hardware, however I have about 128Mb of USB requests queued up to libusb.
> hps@ informed me that libusb will only queue 16kbyte (2msec) in the kernel at
> one ti
12 matches
Mail list logo
