I have just freed up my last 'committed' project, and I've got some spare
cycles to burn.
I've been thinking about how much goes untested in a release, and have been
thinking about how to put together a test harness to check as many things as
possible.
Thats got me thinking (again) about a test
e that requires a specific enviornment to demonstrate
it, I'll send you my code-in-progress.
-Brian
> In article <[EMAIL PROTECTED]>,
> Brian McGovern <[EMAIL PROTECTED]> wrote:
> > I'm playing with an application that uses dlopen() to load some librarie
I'm playing with an application that uses dlopen() to load some libraries. I
use the _init function to set the libraries up. I've also set up the _fini
functions to shut things down.
I see, in the man page, that dlclose() will unload the libraries and call
_fini.
My question is whether or not ex
TLD_NOW | RTLD_GLOBAL);
would find foo.so in the current directory.
-Brian
> Brian McGovern <[EMAIL PROTECTED]> types:
> > Therefore, is there a way to change the linker behavior once the applicati
on
> > has started?... Namely, the equivelent of setting LD_LIBRARY_
r tired.
*feeling like a dumb QA guy*
-Brian
> It seems Brian McGovern wrote:
> > This may be intentional, but I've noticed that if you have a non-UDMA66 device
> > on the primary IDE bus, FreeBSD 4.x does not allow you to have UDMA66 on
> > the seconda
This may be intentional, but I've noticed that if you have a non-UDMA66 device
on the primary IDE bus, FreeBSD 4.x does not allow you to have UDMA66 on
the secondary bus.
To wit, if you had a configuration similar to:
Primary bus
Older (UDMA33 or earlier) IDE boot disk
CD ROM
Secondary bus
15G
> In article <[EMAIL PROTECTED]> you wrote:
> > Just in case someone has more time than I do to look at this, I've been pl
aying
> > with sysinstall, most notably installation through an HTTP proxy.
> [...]
> > The first is when you try to set one of the pre-fab choices, such as
> > instal
Just in case someone has more time than I do to look at this, I've been playing
with sysinstall, most notably installation through an HTTP proxy.
I've found what I believe to be two distinct bugs.
The first is when you try to set one of the pre-fab choices, such as
installing from ftp.freebsd.o
> 0. I'm tired of seeing people putting "Created: mm/dd/yy" in their docuemnts.
Ok, so stop them.
> 1. NTFS does it. It's a part of SMB. I suspect that Samba just uses the
> last modified time.
Just because NTFS does it, doesn't mean its right, or even valid. See below.
> 2. The average
I'm running in to a PCI interface question. I have a board that I can select
whether it will run in Interrupt or "Polled mode" (ie - no interrupt assigned).
It appears that when I have it in interrupt mode, the IRQ (cfg->intline) is
set to a relatively valid (0-15) setting. When it is in polled
I've been digging around in the sio driver, trying to find out how it handles
receive interrupts when the clists are full.
What I think I found (which is why I'm asking) is that if an RX interrupt
occurs, and the clists are full and the driver can't offload all of the
data from the UART, it disab
>> Mmmm... No. _I_ (read: Not Cisco as a whole) am looking for tests that will
>> help locate bugs pre-release copies of the OS so that there is still time for
>> others to debug the code before Jordan cuts the release. Its more of a
>> "lets help the project by coordinating testing" thing
>
>
>> Therefore, I'm asking people to put their minds to work, and talk
>> about valid tests that we could run to catch things that might slip
>> through the cracks. I'm hoping that some of the long-timers can point
>> out areas that have been missed before, and others to point out areas
>> where they
>I have a filesystem stress tests that are worth incorporating. I also have
>a raw disk pattern checker, but that's less of a test than analysis tool.
>
>- -matt
Great. Bundle something up and send it along, and I'll take a look.
-Brian
To Unsubscribe: send mail to majord...@freebsd.org
>I have at least one filesystem killer test.
And it is?... Like I mentioned, we're trying to collect tests/code that will
demonstrate bugs.
>I'll try and figure out a good place to hang it in the source tree, but I
>believe that it's usage is a mandatory "must use" for validating FFS
>and VM c
>> Mmmm... No. _I_ (read: Not Cisco as a whole) am looking for tests that will
>> help locate bugs pre-release copies of the OS so that there is still time for
>> others to debug the code before Jordan cuts the release. Its more of a
>> "lets help the project by coordinating testing" thing
>
>> Therefore, I'm asking people to put their minds to work, and talk
>> about valid tests that we could run to catch things that might slip
>> through the cracks. I'm hoping that some of the long-timers can point
>> out areas that have been missed before, and others to point out areas
>> where the
>I have a filesystem stress tests that are worth incorporating. I also have
>a raw disk pattern checker, but that's less of a test than analysis tool.
>
>- -matt
Great. Bundle something up and send it along, and I'll take a look.
-Brian
To Unsubscribe: send mail to [EMAIL PROTECTED]
wit
>I have at least one filesystem killer test.
And it is?... Like I mentioned, we're trying to collect tests/code that will
demonstrate bugs.
>I'll try and figure out a good place to hang it in the source tree, but I
>believe that it's usage is a mandatory "must use" for validating FFS
>and VM
Hi everyone...
Back in June, at Usenix, Jordan and I talked about doing some more formalized
QA on FreeBSD releases. Unfortunately, this has yet to go really far, as I was
trying to complete some commitments, and have some infrastructure in place
before I started making this endeavor overly public
Hi everyone...
Back in June, at Usenix, Jordan and I talked about doing some more formalized
QA on FreeBSD releases. Unfortunately, this has yet to go really far, as I was
trying to complete some commitments, and have some infrastructure in place
before I started making this endeavor overly publi
>Brian McGovern wrote:
>>However, when I start running data, I get silo overflows.
>
>At which end? What else is the box getting SILO overflows doing? PIO
>access to disks or network cards is good for disrupting interrupt
>latencies. PLIP is virtually guaranteed to disrupt
>Brian McGovern <[EMAIL PROTECTED]> wrote:
>>However, when I start running data, I get silo overflows.
>
>At which end? What else is the box getting SILO overflows doing? PIO
>access to disks or network cards is good for disrupting interrupt
>latencies. PLIP is virt
Thanks, Mike. I don't think they'll let me rip apart my laptop to test this. I
guess I'll try it on a normal PC, and try to track it if it continues. Thanks.
-Brian
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Thanks, Mike. I don't think they'll let me rip apart my laptop to test this. I
guess I'll try it on a normal PC, and try to track it if it continues. Thanks.
-Brian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
I thought I'd give people a chance to jump on this before I opened a PR on it.
I'm currently using a Cyclades board at 115200 to talk to my PII laptop with
a 16550A UART on board via a null modem cable. I'm trying to run PPP over the
link with crtscts set, although I see the same problems using p
I thought I'd give people a chance to jump on this before I opened a PR on it.
I'm currently using a Cyclades board at 115200 to talk to my PII laptop with
a 16550A UART on board via a null modem cable. I'm trying to run PPP over the
link with crtscts set, although I see the same problems using
>> gethostbyaddr... actually, most of the gethostby* functions... are not
>> thread safe. They all use a static buffer in the library.
>>
>> Therefore, with threads, if you don't take precautions, I'd expect your
>> results to be odd.
>> -Brian
>>
>Couldn't this be easily fixed? I haven't loo
>> gethostbyaddr... actually, most of the gethostby* functions... are not
>> thread safe. They all use a static buffer in the library.
>>
>> Therefore, with threads, if you don't take precautions, I'd expect your
>> results to be odd.
>> -Brian
>>
>Couldn't this be easily fixed? I haven't lo
[snip]
gethostbyaddr... actually, most of the gethostby* functions... are not
thread safe. They all use a static buffer in the library.
Therefore, with threads, if you don't take precautions, I'd expect your
results to be odd.
-Brian
To Unsubscribe: send mail to majord...@freebsd.org
wi
[snip]
gethostbyaddr... actually, most of the gethostby* functions... are not
thread safe. They all use a static buffer in the library.
Therefore, with threads, if you don't take precautions, I'd expect your
results to be odd.
-Brian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
I'l looking at defining about a dozen ioctl calls for a local device driver.
When looking at the _IO, _IO, _IOW, _IOR, and _IOWR macros, I'm interested if
there are any "reserved" or "local" values for the first parameter?
In short, I'd hate to use a seemly unused value, just to suddenly be in
c
I'l looking at defining about a dozen ioctl calls for a local device driver.
When looking at the _IO, _IO, _IOW, _IOR, and _IOWR macros, I'm interested if
there are any "reserved" or "local" values for the first parameter?
In short, I'd hate to use a seemly unused value, just to suddenly be in
33 matches
Mail list logo
