Sir :
thank u for ur remind . I see the difference between GPL and
freebsd way .at present I am trying to find a way to Freebsd PCI
hotplug , and borrow some idea from linux ;after i have make sure
what to do and what's on ,i will eliminate the linux shadow and build
pure native FreeBSD ,
In message: <[EMAIL PROTECTED]>
"william wallace" <[EMAIL PROTECTED]> writes:
: BTW :my current code is mainly translate the pcie natve hotplug from
: linux , not from the spec ,and encapsulate the BSD pci config function
: with the linux-alike interface , i wonder if i am walking the r
thank sir ,below is my opinion
On 5/30/06, Scott Long <[EMAIL PROTECTED]> wrote:
On Tue, 30 May 2006, william wallace wrote:
> On 5/30/06, Scott Long <[EMAIL PROTECTED]> wrote:
>> william wallace wrote:
>
>> >>
>> > I have to clarify my intentions that i am not TRYing to do a userland
>> > PCI e
On Tue, May 30, 2006 at 04:42:12PM -0400, Mike Meyer wrote:
> Well, it makes the throughput closer to symmetric when I'm pushing
> traffic both ways - but at around 7MB/sec. If I only run traffic in
> one direction, I get the previous behavior.
I might like to suggest that the problem is your Real
Hi Guys!
It is my pleasure and honor to announce the availability of
the unionfs patchset-13.
Patchset-13:
For 7-current
http://people.freebsd.org/~daichi/unionfs/unionfs-p13.diff
For 6.x
http://people.freebsd.org/~daichi/unionfs/unionfs6-p13.diff
Changes in unionfs-p13.diff
In <[EMAIL PROTECTED]>, Lucas Holt <[EMAIL PROTECTED]> typed:
> Does disabling net.inet.tcp.inflight.enable make any difference? I've
> noticed strange transfer speed differences between a samba server on
> freebsd 6.1 and OS 10.4.6 clients and Windows.
>
> With these set in /etc/sysctl.conf, I c
Does disabling net.inet.tcp.inflight.enable make any difference? I've
noticed strange transfer speed differences between a samba server on
freebsd 6.1 and OS 10.4.6 clients and Windows.
With these set in /etc/sysctl.conf, I can get reasonable speeds on both
the macs and windows box.
net.inet.tcp.
I was doing some network testing, and noticed something odd: The
network throughput was asymmetric. I was sending between 2 and 5 times
as much data as I was receiving. Swapping the ends of the test didn't
change that. Changing the non-FBSD box for a FBSD box made the
throughput symmetric.
Details
On Tue, May 30, 2006 at 11:04:35AM -0400, David Gilbert wrote:
> I've large array that winds up providing 1TB of disk (according to df
> -h :) to a bunch of nfs users. On the array machine, I'm using
> gmirror and gconcat to build the array and right now I'm running dump
> on the array.
>
> I've
Fabian Keil wrote:
Eric Anderson <[EMAIL PROTECTED]> wrote:
Is it expected that truncate(8) must be used by a superuser? If so,
then the man page should probably mention it. If not, then it's
broken :)
What exactly is truncate(8)?
On FreeBSD 6.1-STABLE I only have truncate(1)
and it doesn
Eric Anderson <[EMAIL PROTECTED]> wrote:
> Is it expected that truncate(8) must be used by a superuser? If so,
> then the man page should probably mention it. If not, then it's
> broken :)
What exactly is truncate(8)?
On FreeBSD 6.1-STABLE I only have truncate(1)
and it doesn't show any probl
David S. Madole wrote:
Eric Anderson wrote:
Is it expected that truncate(8) must be used by a superuser? If so,
then the man page should probably mention it. If not, then it's
broken :)
That's a pretty weak attempt at a bug report, and a wrong one, too:
$ uname -m -r -s
FreeBSD 5.4-RELEASE
On Fri, 26 May 2006, [EMAIL PROTECTED] wrote:
0. how many hours did you run memtest86 for?
One of my co-workers ran the test so I'm not entirely sure, but I'm pretty
certain it was at least over night (so probably 15-16 hours). We also
ended up swapping that RAM out with another box and the
On Tue, May 30, 2006 at 10:59:11AM -0500, Eric Anderson wrote:
> Is it expected that truncate(8) must be used by a superuser? If so,
> then the man page should probably mention it. If not, then it's broken :)
>
>
> Eric
I can use truncate on files I own without a problem. Who owns the
files?
On Tue, May 30, 2006 at 10:59:11AM -0500, Eric Anderson wrote:
> Is it expected that truncate(8) must be used by a superuser? If so,
> then the man page should probably mention it. If not, then it's broken :)
>
If you speak about truncate(1), it works here under non-root:
$ uname -sr
FreeBSD 7
On Tue, May 30, 2006 at 12:11:53PM -0400, David S. Madole wrote:
> Eric Anderson wrote:
> >Is it expected that truncate(8) must be used by a superuser? If so,
> >then the man page should probably mention it. If not, then it's
> >broken :)
>
> That's a pretty weak attempt at a bug report, and a
On Tue, 30 May 2006, 10:59-0500, Eric Anderson wrote:
> Is it expected that truncate(8) must be used by a superuser? If so,
> then the man page should probably mention it. If not, then it's
> broken :)
Works for me:
$ truncate -s 100g 100g
$ ls -l 100g
-rw-r--r-- 1 maxim maxim 107374182400
Eric Anderson wrote:
Is it expected that truncate(8) must be used by a superuser? If so,
then the man page should probably mention it. If not, then it's
broken :)
That's a pretty weak attempt at a bug report, and a wrong one, too:
$ uname -m -r -s
FreeBSD 5.4-RELEASE i386
$ id
uid=2028(mado
Is it expected that truncate(8) must be used by a superuser? If so,
then the man page should probably mention it. If not, then it's broken :)
Eric
--
Eric AndersonSr. Systems AdministratorCentaur Techn
I've large array that winds up providing 1TB of disk (according to df
-h :) to a bunch of nfs users. On the array machine, I'm using
gmirror and gconcat to build the array and right now I'm running dump
on the array.
I've got a gstat running and one curious thing is that gstat keeps
reporting 2^3
william wallace wrote:
On 5/30/06, Scott Long <[EMAIL PROTECTED]> wrote:
M. Warner Losh wrote:
> : THIRD
> : Because the PCIE configure space is 4k long ,shall we change the
> : #define PCI_REGMAX 255
> : to facilitate the PCI express config R/W?
>
> Maybe. Lemme investigate because PCIe cha
On 5/30/06, Scott Long <[EMAIL PROTECTED]> wrote:
M. Warner Losh wrote:
> : THIRD
> : Because the PCIE configure space is 4k long ,shall we change the
> : #define PCI_REGMAX 255
> : to facilitate the PCI express config R/W?
>
> Maybe. Lemme investigate because PCIe changes this from a well know
On 5/30/06, M. Warner Losh <[EMAIL PROTECTED]> wrote:
In message: <[EMAIL PROTECTED]>
"william wallace" <[EMAIL PROTECTED]> writes:
: Sir：
: I have got the way to map linux pci access way to the BSD way :)
: now ,several more question ,wondering :(
: FIRST
: struct pci_devinfo * pci_r
M. Warner Losh wrote:
> : THIRD
> : Because the PCIE configure space is 4k long ,shall we change the
> : #define PCI_REGMAX 255
> : to facilitate the PCI express config R/W?
>
> Maybe. Lemme investigate because PCIe changes this from a well known
> constant for all pci busses, to a variable one.
In message: <[EMAIL PROTECTED]>
"william wallace" <[EMAIL PROTECTED]> writes:
: Sir：
: I have got the way to map linux pci access way to the BSD way :)
: now ,several more question ,wondering :(
: FIRST
: struct pci_devinfo * pci_read_device(device_t pcib, int b, int s, int
: f, size_t
Sir：
I have got the way to map linux pci access way to the BSD way :)
now ,several more question ,wondering :(
FIRST
struct pci_devinfo * pci_read_device(device_t pcib, int b, int s, int
f, size_t size)
struct cardbus_devinfo {
struct pci_devinfo pci;
uint8_tmprefetchable;
Hello,
Just quick busdma question...
I'm currently upgrading a custom device driver to use
bus_dmamap_load_uio rather than uiomove. Everything works fine, but
calls to "write" fail unless I set uio->uio_resid to 0 by hand (as I'm
not using uiomove anymore).
Am I supposed to set uio_resid b
On Mon, May 29, 2006 at 05:01:39PM +0200, Volker wrote:
> Hi hackers,
>
> I'm trying to correctly implement a driver for an USB device which
> has multiple (serial) interfaces (at least 3). Each interface should
> be seen by the kernel as a tty device entry /dev(/cuaU* or /dev/ttyU*).
You either
28 matches
Mail list logo
