>
> That's no help at all to a bunch of machines that started life on
> 4.1 back in 2000 and will continue to run another 10-15 years…
So you basically want a group of people to help
you maintain FreeBSD 4-STABLE for an indefinite
period of time?
There seem to be quite a few people still running
Again, no-one is going to really complain if vendors/users decide to step
up and run longer supported branches.
I personally encourage that. I _encourage_ that people who are interested
in keeping 6.x and earlier alive (and 7.x soon, and 8.x less soon) to jump
in and submit patches to backport fix
On Mar 29, 2013, at 1:06 PM, Michael Wayne wrote:
> On Thu, Mar 28, 2013 at 07:31:50PM -0700, Freddie Cash wrote:
>>
>> Every other minor release of FreeBSD is supported for 2 full years, with no
>> new features added, just security fixes (aka Extended Releases).
>>
>> And every major release
On Thu, Mar 28, 2013 at 07:31:50PM -0700, Freddie Cash wrote:
>
> Every other minor release of FreeBSD is supported for 2 full years, with no
> new features added, just security fixes (aka Extended Releases).
>
> And every major release of FreeBSD is supported for at least 4, somtimes 5,
> years.
I'm confused.
Every other minor release of FreeBSD is supported for 2 full years, with no
new features added, just security fixes (aka Extended Releases).
And every major release of FreeBSD is supported for at least 4, somtimes 5,
years.
Canonical just shortened their support for LTS to 3 years,
d maintainence release version of the O/S. The high
> resource commitment required to keep up with the current incessant
> FreeBSD release process is beyond quite a number of people. I'm at
> the point of admitting that FreeBSD is simply too much work for us
> to continue to us
On 28 March 2013 14:29, Michael Wayne wrote:
> I'm NOT trying to start a flame war here. I'm trying to find a
> viable solution to a very frustrating, real problem.
>
> It's clear that FreeBSD has absolutely no interest in maintaining
> an extended maintainence r
I'm NOT trying to start a flame war here. I'm trying to find a
viable solution to a very frustrating, real problem.
It's clear that FreeBSD has absolutely no interest in maintaining
an extended maintainence release version of the O/S. The high
resource commitment required to k
s() does
> > > not return the MNT_UNION flag for a -t nullfs -o union mount. As a
> > > result, opendir()/readdir() return files that exist in both top and
> > > bottom directories twice (at least . and ..). Other -o union mounts and
> > > -t unionfs mounts work cor
On Thu, Feb 28, 2013 at 12:21:44AM +0200, Konstantin Belousov wrote:
> On Wed, Feb 27, 2013 at 10:31:42PM +0100, Jilles Tjoelker wrote:
> > While testing recent changes to opendir(), I noticed that fstatfs() does
> > not return the MNT_UNION flag for a -t nullfs -o union mount.
On Wed, Feb 27, 2013 at 10:31:42PM +0100, Jilles Tjoelker wrote:
> While testing recent changes to opendir(), I noticed that fstatfs() does
> not return the MNT_UNION flag for a -t nullfs -o union mount. As a
> result, opendir()/readdir() return files that exist in both top and
While testing recent changes to opendir(), I noticed that fstatfs() does
not return the MNT_UNION flag for a -t nullfs -o union mount. As a
result, opendir()/readdir() return files that exist in both top and
bottom directories twice (at least . and ..). Other -o union mounts and
-t unionfs mounts
when doing lots of writes (large file) after few tens of gigabytes i've
got as below.
smartctl -t long (full surface test) reports no errors
my disk is
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: ATA-7 SATA 2.x device
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada0: Co
On Tue, 17 Apr 2012 12:30:15 -0700
Adrian Chadd wrote:
> On 17 April 2012 12:15, Gary Jennejohn wrote:
> > I still have the old problem kernel around, but it's probably not
> > instrumented for any meaningful diagnoses.
>
> Well do you know which version of which tree you used to build that?
>
or a certain task varied when I changed the hardware
configuration of the machine in question).
While it turned out that disk I/O was (surprisingly) not very
significant, I did find that extending the mechanism I had been using to
graph (aggregate) CPU utilization to graph the utilization of each core
On 17 April 2012 12:15, Gary Jennejohn wrote:
> Yes, I agree completely. My first thought was that disk I/O
> scheduling had somehow been pessimized. But then I thought -
> wait a minute, I have disk caches enabled and command queuing is
> enabled for all of them, so that shouldn&#
viour is causing you so much trouble? It almost sounds like
> something in the IO path is blocking for far too long, not allowing
> the rest of the system to move forward. That's very worrying for an
> interrupt handler. :)
>
Yes, I agree completely. My first thought was that di
On 11 April 2012 10:21, Gary Jennejohn wrote:
> Just for the archive my bad disk performance seems to have been fixed in
> HEAD by svn commit r234074. Seems that all interrupts were being handled
> by a single CPU/core (I have 6), which resulted in abysmal interrupt
> handling when mutltiple dis
On Tue, 3 Apr 2012 14:27:43 -0700
Jerry Toung wrote:
> On 4/3/12, Gary Jennejohn wrote:
>
> > It would be interesting to see your patch. I always run HEAD but maybe
> > I could use it as a base for my own mods/tests.
> >
>
> Here is the patch
>
[patch removed]
Just for the archive my bad d
On Wed, Apr 4, 2012 at 8:22 PM, Alexander Leidinger wrote:
>
> This looks fair if all your disks are working at the same time (e.g.
> RAID only setup), but if you have a setup where you have multiple
> disks and only one is doing something, you limit the amount of tags
> which can be used. No ide
On Thu, 5 Apr 2012 05:22:46 +0200
Alexander Leidinger wrote:
> On Tue, 3 Apr 2012 14:27:43 -0700 Jerry Toung
> wrote:
>
> > On 4/3/12, Gary Jennejohn wrote:
> >
> > > It would be interesting to see your patch. I always run HEAD but
> > > maybe I could use it as a base for my own mods/tests.
On Tue, 3 Apr 2012 14:27:43 -0700 Jerry Toung
wrote:
> On 4/3/12, Gary Jennejohn wrote:
>
> > It would be interesting to see your patch. I always run HEAD but
> > maybe I could use it as a base for my own mods/tests.
> >
>
> Here is the patch
This looks fair if all your disks are working at
On 4/3/12, Gary Jennejohn wrote:
> It would be interesting to see your patch. I always run HEAD but maybe
> I could use it as a base for my own mods/tests.
>
Here is the patch
diff -rup cam/cam_sim.c cam/cam_sim.c
--- cam/cam_sim.c 2010-06-13 19:09:06.0 -0700
+++ cam/cam_sim.c
On Mon, 2 Apr 2012 10:55:31 -0700
Jerry Toung wrote:
> I am convinced that there is a bug in the CAM code that leads to I/O
> starvation.
> I have already discussed this privately with some. I am now bringing this up
> to
> the general audience to get more feedback.
>
I
Hello list,
I am convinced that there is a bug in the CAM code that leads to I/O starvation.
I have already discussed this privately with some. I am now bringing this up to
the general audience to get more feedback.
My setup is that I have 1 RAID controller with 2 arrays connected to
it, da0 and
On 2/26/12 1:14 PM, Matthias Apitz wrote:
El día Sunday, February 26, 2012 a las 01:05:11PM -0800, Julian Elischer
escribió:
On 2/26/12 5:34 AM, Bob Bishop wrote:
Hi,
I'd like to hear from somebody who understands this stuff on the relative
merits of blackhole routes vs firewall drop rules
El día Sunday, February 26, 2012 a las 01:05:11PM -0800, Julian Elischer
escribió:
> On 2/26/12 5:34 AM, Bob Bishop wrote:
> > Hi,
> >
> > I'd like to hear from somebody who understands this stuff on the relative
> > merits of blackhole routes vs firewall drop rules for dealing with packets
> >
On 2/26/12 5:34 AM, Bob Bishop wrote:
Hi,
I'd like to hear from somebody who understands this stuff on the relative
merits of blackhole routes vs firewall drop rules for dealing with packets from
unwanted sources. I'm particularly interested in efficiency and scalability.
Thanks
the key is
endor/vehosting/slowdown.c
>
> Just tried this: Unfortunately, my app is not slowed down sufficiently. I'm
> afraid I need something that actually re-prioritizes actual disk I/O.
What app is this ?
Considering the above code is a wrapper for stat() fstat() lstat() syscalls and
I'm
afraid I need something that actually re-prioritizes actual disk I/O.
Stefan
--
Stefan BethkeFon +49 151 14070811
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any m
40 schrieb Adam Vande More:
> >
> >> On Mon, Nov 21, 2011 at 1:58 PM, Stefan Bethke wrote:
> >>
> >> Interesting, but it doesn't seem to offer limiting the I/O bandwidth
> >> induced by a process or jail, or assigning different priorities, which
>
On Mon, Nov 21, 2011 at 3:25 PM, Stefan Bethke wrote:
>
> Unfortunately, the process I want to limit is not sufficiently CPU bound
> to be limited that way vs. all the other processes. I guess I'll put in a
> second disk.
>
>
Well, a couple other suggestions.
Have you tried with gsched? It's p
Am 21.11.2011 um 21:42 schrieb Stefan Bethke:
> Am 21.11.2011 um 21:40 schrieb Adam Vande More:
>
>> On Mon, Nov 21, 2011 at 1:58 PM, Stefan Bethke wrote:
>>
>> Interesting, but it doesn't seem to offer limiting the I/O bandwidth induced
>> by a proc
Am 21.11.2011 um 21:40 schrieb Adam Vande More:
> On Mon, Nov 21, 2011 at 1:58 PM, Stefan Bethke wrote:
>
> Interesting, but it doesn't seem to offer limiting the I/O bandwidth induced
> by a process or jail, or assigning different priorities, which would need to
> be im
On Mon, Nov 21, 2011 at 1:58 PM, Stefan Bethke wrote:
>
> Interesting, but it doesn't seem to offer limiting the I/O bandwidth
> induced by a process or jail, or assigning different priorities, which
> would need to be implemented in the ZFS or GEOM schedulers, I suppose.
&g
would be that much
> more flexible.
>
>
> http://wiki.freebsd.org/Hierarchical_Resource_Limits
Interesting, but it doesn't seem to offer limiting the I/O bandwidth induced by
a process or jail, or assigning different priorities, which would need to be
implemented in the ZFS or GEO
On Mon, Nov 21, 2011 at 11:47 AM, Stefan Bethke wrote:
> I have a process that tends to eat up all available disk bandwidth. I
> have other processes that I would like to have preference over this one
> process. Is there a facility that would allow me to assign priorities
> based on jail ID or
I have a process that tends to eat up all available disk bandwidth. I have
other processes that I would like to have preference over this one process. Is
there a facility that would allow me to assign priorities based on jail ID or
uid?
This is on 8-stable (but will upgrade to 9 soon) on ZFS.
On Sunday, September 18, 2011 5:45:26 pm Richard Yao wrote:
> Dear Jilles,
>
> I am using sigwaitinfo() with all interrupts masked to avoid the
> possibility of race conditions in signal handlers, but I have not used
> any realtime signals. Linux 2.6.35 found a way to invoke the SIGIO
> handler de
Why not just port to using libevent 2.x with the thread support, and
thus be portable to all platforms?
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "free
kqueue enable me to specify which
threads handle events on specific file descriptors?
Yours truly,
Richard Yao
On Sun, Sep 18, 2011 at 3:44 PM, Jilles Tjoelker wrote:
> On Sun, Sep 18, 2011 at 11:32:08AM -0400, Richard Yao wrote:
>> I wrote a program for Linux that uses Asynchronous Ne
On Sun, Sep 18, 2011 at 11:32:08AM -0400, Richard Yao wrote:
> I wrote a program for Linux that uses Asynchronous Network I/O and
> POSIX Threads. It uses a mix of gettid(), fcntl() and F_SETOWN to
> specify which thread handles each connection's SIGIO interrupts.
> gettid() is L
On 2011-09-18 17:32, Richard Yao wrote:
Dear FreeBSD Community:
I wrote a program for Linux that uses Asynchronous Network I/O and
POSIX Threads. It uses a mix of gettid(), fcntl() and F_SETOWN to
specify which thread handles each connection's SIGIO interrupts.
gettid() is Linux-specifi
Dear FreeBSD Community:
I wrote a program for Linux that uses Asynchronous Network I/O and
POSIX Threads. It uses a mix of gettid(), fcntl() and F_SETOWN to
specify which thread handles each connection's SIGIO interrupts.
gettid() is Linux-specific and I would prefer to do this in a way that
On Wednesday, June 22, 2011 3:59:06 am Sushanth Rai wrote:
> Hi,
>
> I would like to understand little bit about the FreeBSD interrupt handling
on x86.
>
> When a cpu is processing an IPI, let's say cpu is running IPI_STOP handler,
are I/O interrupts like the time
Hi,
I would like to understand little bit about the FreeBSD interrupt handling on
x86.
When a cpu is processing an IPI, let's say cpu is running IPI_STOP handler, are
I/O interrupts like the timer interrupt disabled ? Conversely if the cpu is
holding a spinlock, which means it has dis
t attach to single-port serial cards. */
>if (cfg->ports == PUC_PORT_1S || cfg->ports == PUC_PORT_1P)
>return (EDOOFUS);
>
> Why is the check there? Is there something about single I/O port cards
> that interacts badly with the rest of the system?
Single-port devices
ears that the section that's preventing it from
being recognised is in puc.c:puc_bfe_probe(). In particular:
/* We don't attach to single-port serial cards. */
if (cfg->ports == PUC_PORT_1S || cfg->ports == PUC_PORT_1P)
return (EDOOFUS);
Why is the check there? Is there so
Peter Jeremy wrote:
Regarding vfs.lorunningspace and vfs.hirunningspace...
On 2010-Jul-15 13:52:43 -0500, Alan Cox wrote:
Keep in mind that we still run on some fairly small systems with limited I/O
capabilities, e.g., a typical arm platform. More generally, with the range
of systems
Regarding vfs.lorunningspace and vfs.hirunningspace...
On 2010-Jul-15 13:52:43 -0500, Alan Cox wrote:
>Keep in mind that we still run on some fairly small systems with limited I/O
>capabilities, e.g., a typical arm platform. More generally, with the range
>of systems that FreeBSD runs
>
>> >>
>> > thank you all, that did it. The settings that Matt recommended are giving
>> > the same numbers
>>
>> Any objections to raising the defaults to 8 MB / 1 MB in HEAD?
>>
>>
>>
> Keep in mind that we still run on some fairly
ecommended are giving
> > the same numbers
>
> Any objections to raising the defaults to 8 MB / 1 MB in HEAD?
>
>
>
Keep in mind that we still run on some fairly small systems with limited I/O
capabilities, e.g., a typical arm platform. More generally, with the range
of system
On 07/14/10 18:27, Jerry Toung wrote:
> On Wed, Jul 14, 2010 at 12:04 AM, Gary Jennejohn
> wrote:
>
>>
>>
>> Rather than commenting out the code try setting the sysctl
>> vfs.hirunningspace to various powers-of-two. Default seems to be
>> 1MB. I just changed it on the command line as a test to 2
On Wed, Jul 14, 2010 at 12:04 AM, Gary Jennejohn
wrote:
>
>
> Rather than commenting out the code try setting the sysctl
> vfs.hirunningspace to various powers-of-two. Default seems to be
> 1MB. I just changed it on the command line as a test to 2MB.
>
> You can do this in /etc/sysctl.conf.
>
>
On Tue, 13 Jul 2010 15:34:12 -0700
Jerry Toung wrote:
> Hello List,
> I am on 8.0 RELEASE amd64. My system has 2 RAID arrays connected to 2
> separate
> controllers.
> My I/O throughput tests jumped by ~100MB/sec on both channels, when I
> commented out the
> following pi
lock devices. Because the related buffers are locked during the I/O,
any attempt to access the data via the buffer cache will unnecessarily
stall the thread trying to access it. Without a limit several seconds
worth of BIOs can accumulate (sometimes tens of seconds worth if the
I/O
Hello List,
I am on 8.0 RELEASE amd64. My system has 2 RAID arrays connected to 2
separate
controllers.
My I/O throughput tests jumped by ~100MB/sec on both channels, when I
commented out the
following piece of code from kern/vfs_bio.c
void
waitrunningbufspace(void)
{
/*
mtx_lock
There was no excitement over the proposed patch on rc@, perhaps more luck here
:-)
Original Message
Subject: rc.d/root: handle filesystems with r/o support only
Date: Sat, 17 Apr 2010 22:16:30 +0300
From: Andriy Gapon
To: freebsd...@freebsd.org
Could you please review the
me interface to userland or GPIO? Something similar to
led(4), but more generic (and supporting 'I' as well 'O').
There's been some discussion amongst embedded folks but nothing yet. I
noticed openbsd commit something recently but don't know if
serland or GPIO? Something similar to
led(4), but more generic (and supporting 'I' as well 'O').
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send an
Nate Eldredge wrote:
> sh prog1 > tmpfile &
tail -f -c +0 tmpfile | sh prog2
BTW, I don't think this would solve my problem as tail -f would block
waiting for more data, as would prog2, so after prog1 finishes writing
data they would block indefinitely on input. I forgot to mention this
was
ons?
I've found that for dump|restore or dump|gzip, I can get quite significant
speedups by adding a buffer that is several hundred MB in the middle.
Well, if OS buffers aren't good enough, then throwing some memory at
disk I/O surely helps ;)
__
Nate Eldredge wrote:
On Wed, 5 Nov 2008, rihad wrote:
Imagine this shell pipeline:
sh prog1 | sh prog2
As given above, prog1 blocks if prog2 hasn't yet read previously written
data (actually, newline separated commands) or is busy. What I want is
for prog1 to never block:
sh prog1 | buffer
On 2008-Nov-05 17:40:11 +0400, rihad <[EMAIL PROTECTED]> wrote:
>Imagine this shell pipeline:
>
>sh prog1 | sh prog2
>
>
>As given above, prog1 blocks if prog2 hasn't yet read previously written
>data (actually, newline separated commands) or is busy. What I want is
>for prog1 to never block:
>
>sh
On Wed, 5 Nov 2008, rihad wrote:
Imagine this shell pipeline:
sh prog1 | sh prog2
As given above, prog1 blocks if prog2 hasn't yet read previously written
data (actually, newline separated commands) or is busy. What I want is
for prog1 to never block:
sh prog1 | buffer | sh prog2
[and misc
Imagine this shell pipeline:
sh prog1 | sh prog2
As given above, prog1 blocks if prog2 hasn't yet read previously written
data (actually, newline separated commands) or is busy. What I want is
for prog1 to never block:
sh prog1 | buffer | sh prog2
I first thought that the aptly named misc/buf
ole), or if you're taking input from a tty/pty. You won't get a
> true scancode from a tty/pty, but you will get a character (0x00 to
> 0xFF).
Hi Jeremy,
after all, i don't need the scancode, i can work with characters,
this avoid the nls translation, which is already done!
r a piano pc keyboard.
> >
> > my questions are as follows:
> >
> > 1. is it a general C function which may scan a terminal without waiting?
> Regarding I/O without waiting: there is not a general libc function for
> this. Garrett mentioned getc(), which blocks (waits).
get
n which may scan a terminal without waiting?
>
> 2. how to get the scancodes?
It depends on if you're wanting the actual hard-wired keyboard (on the
console), or if you're taking input from a tty/pty. You won't get a
true scancode from a tty/pty, but you will get a character (0x00 t
On Wed, May 07, 2008 at 05:39:00PM +0200, [EMAIL PROTECTED] wrote:
> i need to test (NOWAIT), the presence of keypressed/depressed on a terminal
> and then read the scan code, like for a piano pc keyboard.
>
> my questions are as follows:
>
> 1. is it a general C function which may scan a termina
On May 7, 2008, at 8:39 AM, [EMAIL PROTECTED] wrote:
Hi all,
Sorry if its a FAQ but i don't find any answer for this topic.
i need to test (NOWAIT), the presence of keypressed/depressed on a
terminal
and then read the scan code, like for a piano pc keyboard.
my questions are as follows:
Hi all,
Sorry if its a FAQ but i don't find any answer for this topic.
i need to test (NOWAIT), the presence of keypressed/depressed on a terminal
and then read the scan code, like for a piano pc keyboard.
my questions are as follows:
1. is it a general C function which may scan a terminal wit
On Thu, 15 Nov 2007, 12:01-, Dima Dorfman wrote:
> The ping(8) utility has an -o switch that tells it to exit after
> receiving the first reply. This is useful, but ping6(8) doesn't have
> it.
>
> Simple patch attached.
>
> Comments/reviews/whatnots?
>
> I'
The ping(8) utility has an -o switch that tells it to exit after
receiving the first reply. This is useful, but ping6(8) doesn't have
it.
Simple patch attached.
Comments/reviews/whatnots?
I'll commit to HEAD in a few days if I don't hear any objections.
--
Dima Dorfman
In <[EMAIL PROTECTED]>, [EMAIL PROTECTED] typed:
> On Wed, 30 May 2007 12:39:10 -0400, Mike Meyer <[EMAIL PROTECTED]> wrote,
>
> > Actually, protected mode is just the beginnings of it. I've never done
> > much x86 assembly, but going from the '020 to the '030 (or maybe it
> > was the '010 to the
"/dev/io". I believe that leaving this
>> file open for anything more than a handful of instructions would be a
>> bad thing, but I'm not going to verify it.
> I feel that the i386_set_ioperm directly manipulates the task's I/O
> bitmap referenced by the task state
On Wed, 30 May 2007 12:39:10 -0400, Mike Meyer <[EMAIL PROTECTED]> wrote,
> Actually, protected mode is just the beginnings of it. I've never done
> much x86 assembly, but going from the '020 to the '030 (or maybe it
> was the '010 to the '020). I had to start invalidating the hardware
> caches a
andful of instructions would be a
> bad thing, but I'm not going to verify it.
I feel that the i386_set_ioperm directly manipulates the task's I/O
bitmap referenced by the task state segment (TSS), so you don't
need to mangle with /dev/io. /dev/io itself is the higher-le
Open "/dev/io" and you should be able to do what you want.
How you do this in assembler, I'll leave to others.
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to
In <[EMAIL PROTECTED]>, [EMAIL PROTECTED] typed:
> >And I have to ask. The hardware has changed a lot since the days of
> >DoS, and things that worked then may cause strange results on modern
> >hardware. Do you know modern hardware, or are you still using dos-era
> >hardware?
> >
> yes i am aware
>> i am trying to port my old assembler soft for Dos to FreeBSD.
>
>You have my sympathy.
>
Thanks, i need it, because its a big deal for me!
>> i need to write and read directly to the midi and scsi device.
>> when i try something like this i receive a sigbus error
>>
>> SORRY, i am NOT nor a C
enlight me please?
I think you need to open /dev/io before your program can execute I/O
instructions.
--HPS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
In <[EMAIL PROTECTED]>, [EMAIL PROTECTED] typed:
> Sorry for cross posting, but perhaps hackers is a better list than multimedia
> for this topic.
Probably.
> i am trying to port my old assembler soft for Dos to FreeBSD.
You have my sympathy.
> i need to write and read directly to the midi and
Me again.
Wed, May 30, 2007 at 08:46:14AM +0400, Eygene Ryabinkin wrote:
> Then use i386_set_ioperm
> that will be equivalent to the first parameter to the 'int 0x80' to
> 0x04 instead 0x03.
Hmm, that should read "set the first parameter for the 'int 0x80' to
0x04 instead of 0x03" -- it is much m
Raoul, good day.
Tue, May 29, 2007 at 08:10:26PM +0200, [EMAIL PROTECTED] wrote:
> i am trying to port my old assembler soft for Dos to FreeBSD.
> i need to write and read directly to the midi and scsi device.
> when i try something like this i receive a sigbus error
Seems like that the following
hi all,
Sorry for cross posting, but perhaps hackers is a better list than multimedia
for this topic.
i am trying to port my old assembler soft for Dos to FreeBSD.
i need to write and read directly to the midi and scsi device.
when i try something like this i receive a sigbus error
SORRY, i am
Nico -telmich- Schottelius [Mon, May 21, 2007 at 11:24:43AM +0200]:
> [...]
> I did some tests on our Dell Poweredge SC 1425, because our new
> mailserver had one outage (reason unknown) and was onetime running
> extremly slow.
> [...]
Update:
I removed da1 from the array, rebooted, used da1s1a a
dev/mirror/raid1s1a on / (ufs, local, soft-updates)
My question regarding this issue:
- it seems not to be normal to me, that a system is practically dead
when running some i/o heavy processes and it also does not look to
me like a general freebsd issue; what could be the reason for it?
On 2/28/07, Sean Bryant <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> On Thu, 15 Feb 2007, Michel Talon wrote:
>
>>> Give me a few weeks, and if I can band together with a few people I
>>> wanted to try and port sections of portupgrade and its related tools
to
>>> C++ (and maybe do some
[EMAIL PROTECTED] wrote:
On Thu, 15 Feb 2007, Michel Talon wrote:
Give me a few weeks, and if I can band together with a few people I
wanted to try and port sections of portupgrade and its related tools to
C++ (and maybe do some code tweaks along the way). Most of the ruby
files are over 400 li
On Thu, 15 Feb 2007, Florent Thoumie wrote:
[EMAIL PROTECTED] wrote:
On Thu, 15 Feb 2007, Coleman Kane wrote:
On 2/15/07, Alexander Leidinger <[EMAIL PROTECTED]> wrote:
Quoting Olivier Warin <[EMAIL PROTECTED]> (from Wed, 14 Feb 2007
19:54:09 +0100):
This issue is not only related to port
On Thu, 15 Feb 2007 15:54:29 -0600, Doug Barton <[EMAIL PROTECTED]> wrote:
David Gilbert wrote:
"Jeremy" == Jeremy Messenger <[EMAIL PROTECTED]> writes:
Jeremy> Give ports-mgmt/portmaster a try.
I just did. One flaw it has is that I have two no longer supported
ports installed.
What do yo
David Gilbert wrote:
>> "Jeremy" == Jeremy Messenger <[EMAIL PROTECTED]> writes:
>
> Jeremy> Give ports-mgmt/portmaster a try.
>
> I just did. One flaw it has is that I have two no longer supported
> ports installed.
What do you mean by "no longer supported?"
> I want to run portmaster -a
Michel Talon wrote:
> Joerg Sonnenberger wrote:
>
>> Well, the complexity is somewhere in the area of O(nm) with m being
>> small. I strongly suggest some basic bucket hashing if it is not done
>> already. For the pkgsrc bulk build (which has similiar problems) it
>>
On Thu, 15 Feb 2007 12:17:00 -0600, <[EMAIL PROTECTED]> wrote:
=
Pros:
=
-It's written in python (portable).
Isn't our more portable for hardware than Python? Also, it is smaller?
-It's a system which focuses on ports compilation from source, not
binary package installation.
This
On Thu, Feb 15, 2007 at 05:33:59PM +0100, Niclas Zeising wrote, and it was
proclaimed:
> On 2/15/07, Coleman Kane <[EMAIL PROTECTED]> wrote:
> >On 2/15/07, Alexander Leidinger <[EMAIL PROTECTED]> wrote:
> >>
> >> Quoting Olivier Warin <[EMAIL PROTECTED]> (from Wed, 14 Feb 2007
> >> 19:54:09 +0100)
On Thu, 15 Feb 2007, Michel Talon wrote:
A lot of things that I think are half right.
> I think that porting portupgrade to C++ would be time spent in vain. In
> my opinion, some of the basic ideas of portupgrade are deeply flawed,
> and as much as one polishes the algorithms it will not gain muc
[EMAIL PROTECTED] wrote:
> On Thu, 15 Feb 2007, Coleman Kane wrote:
>
>> On 2/15/07, Alexander Leidinger <[EMAIL PROTECTED]> wrote:
>>>
>>> Quoting Olivier Warin <[EMAIL PROTECTED]> (from Wed, 14 Feb 2007
>>> 19:54:09 +0100):
>>>
>>> > This issue is not only related to portupgrade, pkg_add a new p
On Thu, 15 Feb 2007, Michel Talon wrote:
Give me a few weeks, and if I can band together with a few people I
wanted to try and port sections of portupgrade and its related tools to
C++ (and maybe do some code tweaks along the way). Most of the ruby
files are over 400 lines long, sparsely comment
On Thu, 15 Feb 2007, Coleman Kane wrote:
On 2/15/07, Alexander Leidinger <[EMAIL PROTECTED]> wrote:
Quoting Olivier Warin <[EMAIL PROTECTED]> (from Wed, 14 Feb 2007
19:54:09 +0100):
> This issue is not only related to portupgrade, pkg_add a new port takes
> far too long now... and make index
1 - 100 of 443 matches
Mail list logo
