Sorry about the late notice - I've been traveling since last Thursday.
So I'll keep this short and to the point.
WHEN: Tuesday, July 17, 2007. 7-9 PM.
WHERE: RMC Research Offices, Portsmouth, NH
WHAT: This month's meeting will consist of a live coding session where
group members Scott Garman and
Steven W. Orr writes:
> In fact, the card is proprietary but the driver is open source.
So, at this point the "best" solution seems to be obvious: just
modify the driver to respect O_EXCL. Surely the original authors of
the driver would welcome this enhancement.
--kevin
--
GnuPG ID: B280F24E
On 7/16/07, John Abreau <[EMAIL PROTECTED]> wrote:
>> I've often wondered why, after 30+ years of *nix, there's still no
>> good way to handle locking/contention in the filesystem.
>
>
> File locking is pretty basic stuff. Breaking with tradition on it would
> mean a program won't work on BSD, So
Ben Scott wrote:
> On 7/15/07, Ted Roche <[EMAIL PROTECTED]> wrote:
>
> Check the kernel log (it's on one of the Virtual Consoles,
> [CTRL]+[ALT]+[F4] maybe?) for indications as to what the kernel thinks
> is going on.
I didn't see anything obvious, but will try again and report more
detailed r
On Sat, July 14, 2007 1:15 pm, Bill Ricker said:
> right -- you can auto-cleanup old lockfiles if contents are pid of the
> creating process and /proc/$pid doesn't exist when server restarts.
>
> Only if some OTHER process is holding that PID after a reboot or such
> is a stale lockfile a problem
On Sun, July 15, 2007 1:12 pm, Ben Scott said:
> I've often wondered why, after 30+ years of *nix, there's still no
> good way to handle locking/contention in the filesystem. Linux, KDE,
> GNOME, etc., have shown that the *nix community is willing to jettison
> "Unix tradition" when there's an
>
> I've read the CentOS release notes and attempted to Google for clues.
> There's nothing in the installation logs to indicate an error condition.
>
> Can anyone suggest what to look at next?
This CentOS 4.3 bug reports the same kind of behavior. It states that
booting with "linux ide=nodma" may
> Does the centos install support network installations? When dealing
> with computers that lack a DVD drive, I usually use the network install
> and refer back to my laptop. Two useful hints:
> use the IP address to reference the source computer
> (http://192.168.0.10/fc7)
> mou
On Sun, 2007-07-15 at 14:19 -0400, Ted Roche wrote:
> Trying to install CentOS5 from CD on a new server, Dell SC430, Pentium-D
> 2.8 GHz, 1 Gb RAM, 2-250 Gb SATA drives. I had previously installed FC7
> from the LiveCD and run it though some basic functionality tests, SMART
> drive long tests, etc.
On Monday, Jul 16th 2007 at 09:53 -0400, quoth Bill McGonigle:
=>
=>On Jul 15, 2007, at 16:35, Steven W. Orr wrote:
=>
=>> my particular problem would be
=>> solved if the char device I was trying to open would only honor O_EXCL
=>
=>It's a close-source character device?
In fact, the card is pro
On Jul 15, 2007, at 15:08, Ted Roche wrote:
Sorry; I was unclear. I tested both disks on two other machines and
mediacheck passed with flying colors.
I actually don't know - does the media check just verify that it 'can
read' all sectors, or does it actually checksum them?
I seem to recall
On Jul 15, 2007, at 16:35, Steven W. Orr wrote:
my particular problem would be
solved if the char device I was trying to open would only honor O_EXCL
It's a close-source character device?
-Bill
-
Bill McGonigle, Owner Work: 603.448.4440
BFC Computing, LLC Home: 6
> My C is somewhat rusty, but doesn't O_EXCL just prevent one
> from creating/opening the file if it already exists?
That's the generally accepted meaning of that flag when passed to open()
but only when used along with O_CREAT and then only with "normal" files
and even then, not always. And yo
Ben Scott writes:
> On 7/15/07, Steven W. Orr <[EMAIL PROTECTED]> wrote:
> > ... my particular problem would be
> > solved if the char device I was trying to open would only honor O_EXCL.
>
> My C is somewhat rusty, but doesn't O_EXCL just prevent one from
> creating/opening the file if it alrea
14 matches
Mail list logo