On Fri, 15 Sep 2006, Roland Smith wrote:
On Fri, Sep 15, 2006 at 08:46:57PM +0200, Martin Nilsson wrote:
Hans Lambermont wrote:
.. or just stop calling it STABLE and call it RELENG_6 instead
That's a good idea, IMHO. When I started with FreeBSD I found the
difference between the branch names
You can track changes to a particular release - say by using
RELENG_6_1 rather than RELENG_6. In which case, would you still
say you are tracking STABLE?
If I track RELENG_6 (once 6.0-RELEASE has gone out) then I'm by definition
tracking -STABLE.
Damn, I'm confused now. Let me try and get
I was playing with a USB card reader and FreeBSD, and I've discovered some
quirks that I imagine need attention. The driver involved is umass(4).
The card reader itself has four slots in which various formats of flash
card can be inserted, and is a USB device. The quirks are as follows:
1.
On Sun, 3 Sep 2006, Kevin Oberman wrote:
From: Michael Abbott [EMAIL PROTECTED]
# ls /dev/da*
/dev/da0 /dev/da1 /dev/da1 /dev/da2 /dev/da2 /dev/da3 /dev/da3
How very very strange.
Strange, yes. Surprising, no.
umass (and USB support) is not in the best of shape in FreeBSD
On Tue, 29 Aug 2006, Alexey Karagodov wrote:
it's all is very good, but what can you say about to fix problem with
rpc.lockd ???
Well, I will repeat the test with RELENG_6 (as of yesterday lunchtime),
probably tonight, and report back. Unfortunately building takes around 8
hours on my test
An alternative would be to update to RELENG_6 (or at least RELENG_6_1)
and then try again.
So. I have done this. And I can't reproduce the problem.
# uname -a
FreeBSD venus.araneidae.co.uk 6.1-STABLE FreeBSD 6.1-STABLE #1: Mon Aug 28
18:32:17 UTC 2006
[EMAIL
Well, the result I have to report is so interesting, I'll give the
executive summary right away:
If rpc.lockd is run with -d255 it works perfectly
If rpc.lockd is run with -d1 (or no -d option) it locks up
Sweet.
Does anyone out there who understands rpc.lockd fancy a deeper
On Sun, 27 Aug 2006, Kostik Belousov wrote:
On server,
tcpdump -p -s 1500 -w file -i iface host client host ip
Ok. I've run
saturn# tcpdump -p -s 1500 -w tcpdump.out -i xl0 host 10.0.0.105
and run the failing test on venus (with `rpc.lockd -d1`). The failing
lockf has moved -- it took
On Mon, 28 Aug 2006, Oliver Fromme wrote:
SIGKILL _does_ always work. However, signal processing can be delayed
for various reasons.
[...]
Well, in theory, a special case could be made for SIGKILL, but it's
quite difficult if you don't want break existing semantics (or creating
holes).
I've been trying to make some sense of the NFS locking issue. I am
trying to run
# make installworld DESTDIR=/mnt
where /mnt is an NFS mount on a FreeBSD 4.11 server, but I am unable to
get past a call to `lockf`.
On this mailing list I've seen a thread starting with this message:
On Sun, 27 Aug 2006, Greg Byshenk wrote:
On Sun, Aug 27, 2006 at 11:24:13AM +, Michael Abbott wrote:
I've been trying to make some sense of the NFS locking issue. I am
trying to run
# make installworld DESTDIR=/mnt
where /mnt is an NFS mount on a FreeBSD 4.11 server, but I am
On Sun, 27 Aug 2006, Kostik Belousov wrote:
Make sure that rpc.statd is running.
Yep. Took me some while to figure that one out, but the first lockf test
failed without that.
For debugging purposes, tcpdump of the corresponding communications
would be quite useful. Besides this, output of
12 matches
Mail list logo
