On Tuesday 01 November 2005 18:19, [EMAIL PROTECTED] wrote:
4. I sure ain't going to wear a T-shirt with that on it.
sad story - i'm too...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To
On Wed, Nov 02, 2005 at 01:31:39AM -0600, Mike Silbersack wrote:
On Tue, 1 Nov 2005, Viktor Vasilev wrote:
With FreeBSD 5.4-RELEASE I almost constantly get ~2 microseconds
delta. That is with 100HZ kernel on PIII 500MHz or Sempron 64 2800+
Put kern.hz=1000 in /boot/loader.conf to
Hello fellow hackers,
I was thinking of porting the linux sysprof kernel and userland tools
to FreeBSD. I spent some time studying the code and wrote a skeleton
driver that uses the callout mechanism to wake up periodically. That
was only to discover, that the context in which the driver awakes
Brian Buchanan wrote:
test.c: In function `foobar':
test.c:6: error: invalid application of `sizeof' to incomplete type
`test.c'
Looks like someone goofed up some printf() args.
yah, but it's in the gcc code itself, no FreeBSD modification.
cheers
simon
--
Serve - BSD +++
In message: [EMAIL PROTECTED]
Ben Siemon [EMAIL PROTECTED] writes:
: I have a suggestion for things dev people could do to help out with
: code already done. I noticed the suggestion for compiling with -Wall
: enabled. Would it serve any purpose to compile the sources with -ansi
: and
On Wednesday 02 November 2005 04:37 am, Viktor Vasilev wrote:
Hello fellow hackers,
I was thinking of porting the linux sysprof kernel and userland tools
to FreeBSD. I spent some time studying the code and wrote a skeleton
driver that uses the callout mechanism to wake up periodically. That
On Tue, 1 Nov 2005, Max Laier wrote:
All,
inspired by:
http://marc.theaimsgroup.com/?l=openbsd-techm=112966325607754w=2
I rolled this diff and would like to commit it. TRASHIT() is defined only
under QUEUE_MACRO_DEBUG so this should be save for all and only affect people
prepared
Hello!
After another reboot, I started getting the message in subject and thus
have lost my network connection.
The card used to be identified as:
sk0: Marvell Semiconductor, Inc. Yukon on skc0
[]
I initially rebooted to add RAM to the machine, but have since tried to
take
On 10/28/05 10:52 M. Warner Losh said the following:
libc_r will block all other threads in the application while an ioctl
executes. libpthread and libthr won't. I've had several bugs at work
so if the userland thread does an ioctl, and the the driver goes to
tsleep() when the ioctl is
Dinesh Nair wrote:
On 11/02/05 06:12 Julian Elischer said the following:
depends on what they are using it for..
if it's a WAN interface, then splimp. (INTR_TYPE_NET)
if ppp or several other moduels are loaded, teh tty and net masks are
combined anyhow..
it's a quad-span E1/T1 line
From: Dinesh Nair [EMAIL PROTECTED]
Subject: Re: locking in a device driver
Date: Thu, 03 Nov 2005 02:23:32 +0800
On 10/28/05 10:52 M. Warner Losh said the following:
libc_r will block all other threads in the application while an ioctl
executes. libpthread and libthr won't. I've had
Dinesh Nair wrote:
On 10/28/05 10:52 M. Warner Losh said the following:
libc_r will block all other threads in the application while an ioctl
executes. libpthread and libthr won't. I've had several bugs at work
so if the userland thread does an ioctl, and the the driver goes to
In message: [EMAIL PROTECTED]
Julian Elischer [EMAIL PROTECTED] writes:
: Dinesh Nair wrote:
:
:
:
: On 10/28/05 10:52 M. Warner Losh said the following:
:
: libc_r will block all other threads in the application while an ioctl
: executes. libpthread and libthr won't. I've had
M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Julian Elischer [EMAIL PROTECTED] writes:
: Dinesh Nair wrote:
:
:
:
: On 10/28/05 10:52 M. Warner Losh said the following:
:
: libc_r will block all other threads in the application while an ioctl
: executes. libpthread
On 11/03/05 03:12 Warner Losh said the following:
Yes. if you tsleep with signals enabled, the periodic timer will go
off, and you'll return early. This typically isn't what you want
either.
looks like i've got a lot of work to do, poring thru all the ioctls for the
device and trying to
On 11/03/05 04:27 M. Warner Losh said the following:
that this is the case: sleep in an ioctl, and the entire process hangs
until the ioctl returns.
which is probably what's happening in my case. i've got 4 threads spun off,
and one thread reads what the other writes and vice versa. after
Dinesh Nair wrote:
On 11/03/05 03:12 Warner Losh said the following:
Yes. if you tsleep with signals enabled, the periodic timer will go
off, and you'll return early. This typically isn't what you want
either.
looks like i've got a lot of work to do, poring thru all the ioctls for
the
In message: [EMAIL PROTECTED]
Dinesh Nair [EMAIL PROTECTED] writes:
:
:
: On 11/03/05 03:12 Warner Losh said the following:
: Yes. if you tsleep with signals enabled, the periodic timer will go
: off, and you'll return early. This typically isn't what you want
: either.
:
:
On 11/03/05 05:17 M. Warner Losh said the following:
this is to create a helper program that gets the ioctl request over a
pipe or socket, does the call to the kernel and then returns the
results. Not idea, I'll grant, but it is an alternative worth
no, that wont work. the userland app is
On 11/03/05 05:15 Scott Long said the following:
before the ioctl call runs. But it does work. Look at the aac(4)
driver for my example of this.
i will, it sounds like a good solution.
The other option is to use rfork, aka 'linuxthreads' to similate threads
i could try with
In message: [EMAIL PROTECTED]
Scott Long [EMAIL PROTECTED] writes:
: Dinesh Nair wrote:
:
:
: On 11/03/05 03:12 Warner Losh said the following:
:
: Yes. if you tsleep with signals enabled, the periodic timer will go
: off, and you'll return early. This typically isn't what
I've got a proposed fix for dhclient interactions with IPv4 aliases. It
turns out that my speculation that it was driver issues was wrong and
that dhclient with reacting to the aliases themselves. I suspect there
may be issues with some drivers, but that's not the main problem.
This patch adds
dear everybody,
i am trying to compress/decompress ip packets.
for this i have implemented the adaptive lzw compression.
i put the code in the ip_output.c and do my compression/decompression
just before the if_output() function call so that i won't interfere with
the ip processing of the kernel.
On Wednesday 02 November 2005 07:12 pm, Brooks Davis wrote:
I've got a proposed fix for dhclient interactions with IPv4
aliases. It turns out that my speculation that it was driver
issues was wrong and that dhclient with reacting to the aliases
themselves. I suspect there may be issues with
On Wed, Nov 02, 2005 at 11:08:53PM -0500, Anish Mistry wrote:
On Wednesday 02 November 2005 07:12 pm, Brooks Davis wrote:
I've got a proposed fix for dhclient interactions with IPv4
aliases. It turns out that my speculation that it was driver
issues was wrong and that dhclient with
25 matches
Mail list logo
