> > My question is:
> > Is it not possible, that vkbd_dev_intr() could be
> > interrupted at any position before the VKBD_LOCK()
> > and then vkbd_dev_write() called?
>
> in theory it is possible.
>
> > If yes, how should vkbd_dev_write() know, that it should
> > call task_enqueue(), as TASK is s
On Mon, 6 Jun 2005, Jeremie Le Hen wrote:
I made the small attached patch which creates the
kern.geom.allow_foot_shooting
This was proposed in ftp://ftp.jurai.net/users/winter/geom.foot.patch
before debug flag 16 existed.
The longer name doesn't really do anything to inform the user about
Hi list,
> I don't want to start the bikeshed again, but would this be ok to create
> a kern.geom.allow_foot_shooting sysctl wrapper for this and reference
> it in geom(4) manual page (and anywhere else it is relevant), at least
> temporaly until a decision is made ?
>
> I can't find where this i
On Sunday 05 June 2005 13:17, Thomas Sparrevohn wrote:
Ok - After a hand held trace - here are what happens
In the call to uma_zcreate for the "PROC" object the slab_zalloc ends up being
called twice - it in turn calls vm_map_lock and establishes the first time a
exclusive sleep mutex on the r
On Sun, Jun 05, 2005 at 10:45:02AM -0300, Cesar Mello wrote:
> I'd like to do some research on framebuffer GUIs (without Xorg) in
> FreeBSD. My background is C/C++ programming, Win32 and a bit of xlib. I've
> read the developer handbook but it didn't seem to have enough information
> for me. Can y
Hello,
I'd like to do some research on framebuffer GUIs (without Xorg) in
FreeBSD. My background is C/C++ programming, Win32 and a bit of xlib. I've
read the developer handbook but it didn't seem to have enough information
for me. Can you please point me to more information about framebuffer
dev
On Sun, Jun 05, 2005 at 01:35:21AM -0400, Pablo Mora wrote:
> #include
> #include
>
> int main(void) {
>
> FILE *p_to_f;
> char buf[1024];
> int i, j = 0;
>
> p_to_f = fopen("test","r");
>
> if(p_to_f == NULL) {
> perror("fopen");
> exit(EXIT_FAILURE);
> }
>
> for(i = 0; i < 4 &&
On Sunday 05 June 2005 12:31, Thomas Sparrevohn wrote:
Ups - two useless files included - please ignore the plugins.txt and the dmesg
- it should have been
> Hi
>
> One of the changes introduced after the 27/05 causes a panic in the initial
> boot phases in the
>
> The panic occurs on my Dell L
On Sun, 5 Jun 2005, Andre Guibert de Bruet wrote:
> > Yes, oh lordie yes. I guess we aren't going to have a new logo in time for
> > FreeBSD6-RELEASE in August, are we?
>
> Coordinating the release with the new logo would be really nifty!
Mabe im living under a rock... but what new logo?
~NVX
On Sat, 4 Jun 2005, John Jawed wrote:
On 6/3/05, Scott Long <[EMAIL PROTECTED]> wrote:
The long anticipated and much feared 6.0 code freeze is about to begin!
I'll cut to the chase:
June 10 - Feature freeze + code slush
^^^
July 10 - RELENG_6 branch
August 1 - RELENG_6_0 branch
August 15
Yes, oh lordie yes. I guess we aren't going to have a new logo in time for
FreeBSD6-RELEASE in August, are we?
On 6/3/05, Scott Long <[EMAIL PROTECTED]> wrote:
>
> All,
>
> The long anticipated and much feared 6.0 code freeze is about to begin!
> I'll cut to the chase:
>
> June 10 - Feature fr
Hi
One of the changes introduced after the 27/05 causes a panic in the initial
boot phases in the
The panic occurs on my Dell Lattitude C640 when using both my own kernel and
the GENERIC kernel.
The panic is
_mtx_lock_sleep: Recursed on non-recursive mutex in system map
I have traced the t
12 matches
Mail list logo
