It seems Torbjorn Kristoffersen wrote:
On Sun, 29 Apr 2001, Mike Silbersack wrote:
On Sun, 29 Apr 2001, Torbjorn Kristoffersen wrote:
I'm having trouble with my HighPoint 366 controller. Both the chip and
cable works fine in Linux or Windows, but I get an error message from
FreeBSD
On Mon, 30 Apr 2001, Søren Schmidt wrote:
It seems Torbjorn Kristoffersen wrote:
On Sun, 29 Apr 2001, Mike Silbersack wrote:
On Sun, 29 Apr 2001, Torbjorn Kristoffersen wrote:
I'm having trouble with my HighPoint 366 controller. Both the chip and
cable works fine in Linux or
On Mon, Apr 30, 2001 at 12:08:47AM +0200, Torbjorn Kristoffersen wrote:
Yes, I'm using the 80-conductor cable I got with the motherboard
(ABIT BE6 with HPT366 onboard).
Is the cable connected properly? The blue connector must be on the
motherboard end.. Are you sure Leenuchs is using ATA66
It seems Alex Zepeda wrote:
On Mon, Apr 30, 2001 at 12:08:47AM +0200, Torbjorn Kristoffersen wrote:
Yes, I'm using the 80-conductor cable I got with the motherboard
(ABIT BE6 with HPT366 onboard).
Is the cable connected properly? The blue connector must be on the
motherboard end..
Hi Mike,
The software I am using in Linux (cajun - cajun.sourceforge.net)
requires
a serial display to work. What the linux driver does is emulate the
serial
display, and provides a /dev/lcd.
As I am not a perl coder, I cannot modify Cajun to use the app you
wrote,
And as I am not a C coder, I
On Sunday 29 April 2001 11:51, Shaun Dwyer wrote:
Hi Mike,
The software I am using in Linux (cajun - cajun.sourceforge.net)
requires
a serial display to work. What the linux driver does is emulate the
serial
display, and provides a /dev/lcd.
As I am not a perl coder, I cannot modify
The software I am using in Linux (cajun - cajun.sourceforge.net)
requires a serial display to work. What the linux driver does is emulate
the serial display, and provides a /dev/lcd.
As I am not a perl coder, I cannot modify Cajun to use the app you
wrote, And as I am not a C coder, I
Hello,
Been following this thread, and thought I would poke my nose
in.
We are in the process of writing a driver (heavily based on
LCDProc - http://lcdproc.omnipotent.net) and the source
for this seems to be pretty easy to work with.
The panel and driver board we are using hooks into a
Dear all:
Because write() use buffer cache, I want to know whether aio_write() is
better than write() in FreeBSD 4.1 . Is aio_write()
outperform write() ? Or any related performance comparison between the two
system call
Thanks in advance
Richard_Lin
To Unsubscribe: send
* ªL^¶W [EMAIL PROTECTED] [010430 06:17] wrote:
Dear all:
Because write() use buffer cache, I want to know whether aio_write() is
better than write() in FreeBSD 4.1 . Is aio_write()
outperform write() ? Or any related performance comparison between the two
system call
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Alfred Perlstein
Sent: Monday, April 30, 2001 9:31 PM
To: ªL^¶W
Cc: Freebsd-Hackers
Subject: Re: write() vs aio_write()
* ªL^¶W [EMAIL PROTECTED] [010430 06:17] wrote:
Dear all:
Because write()
* ªL^¶W [EMAIL PROTECTED] [010430 06:47] wrote:
* ªL^¶W [EMAIL PROTECTED] [010430 06:17] wrote:
Dear all:
Because write() use buffer cache, I want to know whether aio_write()
is
better than write() in FreeBSD 4.1 . Is aio_write()
outperform write() ? Or any related
I'm trying to set up a FreeBSD firewall for ~100 PCs and ~10 servers, and
I'm
having some trouble with routing/netmasks.
I have 30 IP addresses assigned to me by my ISP, for the sake of this
example
let's say I've got 90.91.92.0/27. The FreeBSD box has 2 interface cards,
fxp0 and fxp1, fxp0
On Mon, 30 Apr 2001, John Wilson wrote:
This probably belongs on freebsd-net or freebsd-questions.
I have 30 IP addresses assigned to me by my ISP, for the sake of this
example let's say I've got 90.91.92.0/27. The FreeBSD box has 2
interface cards, fxp0 and fxp1, fxp0 connected to the
Unfortunately, when I choose a netmask such as 255.255.255.227 (11100011),
I'm
left with only 6 IPs for the DMZ:
Netmasks must be contiguous, which means that 255.255.255.227 is an
invalid netmask. (This is a CIDR requirement.)
Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
To
On Sun, 29 Apr 2001, Alex Zepeda wrote:
On Mon, Apr 30, 2001 at 12:08:47AM +0200, Torbjorn Kristoffersen wrote:
Yes, I'm using the 80-conductor cable I got with the motherboard
(ABIT BE6 with HPT366 onboard).
Is the cable connected properly? The blue connector must be on the
On Mon, Apr 16, 2001 at 03:42:34PM +0200, Alex wrote:
Hi,
i've got a little question about device drivers for FreeBSD.
I'm testing my device driver by compiling it as a module and
kldloading it. But as I don't want to use it as a module in the
future I declared DRIVER_MODULE(..) as
Dear Nick,
Thanks for your prompt reply.
On Mon, 30 Apr 2001, John Wilson wrote:
I have 30 IP addresses assigned to me by my ISP, for the sake of this
example let's say I've got 90.91.92.0/27. The FreeBSD box has 2
interface cards, fxp0 and fxp1, fxp0 connected to the router,
Regarding aio_*, Alfred Perlstein writes:
It's a good idea to use it for disk IO, probably not a good
idea for network IO.
Could you elaborate?
-Charles
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
On Mon, 30 Apr 2001, John Wilson wrote:
Moved to -net.
Nick Rogness [EMAIL PROTECTED]
- Keep on Routing in a Free World...
FreeBSD: The Power to Serve!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
On Mon, 30 Apr 2001, Charles Randall wrote:
Regarding aio_*, Alfred Perlstein writes:
It's a good idea to use it for disk IO, probably not a good
idea for network IO.
Could you elaborate?
-Charles
Sockets already support non-blocking IO, and have for a long while.
Hence, the socket code
I am trying to make a custom boot CD for FreeBSD. I got it to the point
to where the CD will boot, load the kernel, but that's as far as it
get's. It does when it get's to the part where it wants to mount the root
devicd. It tried to access the floppy drive.
So, do I need to vnconfig the
I've got a little patch to try to make accesses to the LDT and TSS of processes
on the x86 thread safe. It relies partially on the fact that a TSS or LDT is
only modified by the process it is attached to (with the exception of the LDT
reference count for LDT's shared among processes). The patch
Mike Silbersack [EMAIL PROTECTED] wrote:
[ On using aio on disks vs. sockets ]
Sockets already support non-blocking IO, and have for a long while.
Hence, the socket code is probably more optimized for non-blocking
operation than AIO operation. As a plus, using non-blocking socket
operations will
* Charles Randall [EMAIL PROTECTED] [010430 10:26] wrote:
Regarding aio_*, Alfred Perlstein writes:
It's a good idea to use it for disk IO, probably not a good
idea for network IO.
Could you elaborate?
Sure.
Network IO can be done without blocking (unless you take a fault
on the source
-BEGIN PGP SIGNED MESSAGE-
Maybe this isn't right mailing list to send this problem but here it is:
I have D-Link DFE-530TX+ and in LINT I read that I should use device rl
for this Network card but kernel don't want to find it only output off
kernel is :
pci0: unknown card
Vojislav,
I had the same problem with FreeBSD 4.3 and a D-Link DFE-530TX+ on a
Dell PowerEdge 1400sc. I spent a couple of days on and off fighting
with it and couldn't make it work. After going as far as explicitly
loading the rl driver in loader.conf (I don't know how I ended up in
there,
-BEGIN PGP SIGNED MESSAGE-
Maybe this isn't right mailing list to send this problem but here it is:
I have D-Link DFE-530TX+ and in LINT I read that I should use device rl
for this Network card but kernel don't want to find it only output off
kernel is :
pci0: unknown card
On Tue, 1 May 2001, Jan Mikkelsen wrote:
Mike Silbersack [EMAIL PROTECTED] wrote:
[ On using aio on disks vs. sockets ]
Sockets already support non-blocking IO, and have for a long while.
Hence, the socket code is probably more optimized for non-blocking
operation than AIO operation. As a
29 matches
Mail list logo