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 unsub
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.con
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 is
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
: a
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. Th
On Tue, 1 Nov 2005, Max Laier wrote:
> All,
>
> inspired by:
> http://marc.theaimsgroup.com/?l=openbsd-tech&m=112966325607754&w=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
> p
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: on skc0
[]
I initially rebooted to add RAM to the machine, but have since tried to
take the extra memory back out to no av
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 rec
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 card
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'
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
tsleep(
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
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. li
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 us
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 wri
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 d
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 ast
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 linuxthreads
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 i
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 a
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 wi
Speaking of dhclient and aliases. Has anyone sucessfully used the
alias { ... } syntax of dhclient.conf after switching dhclients? I
used to use the following in my dhclient.conf, but had to comment it
out when the OpenBSD dhclient was imported.
|alias {
| interface "sis1";
| fixed-address 192
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 r
26 matches
Mail list logo
