On Wed, Oct 31, 2012 at 4:07 AM, Glen Barber wrote:
> On Tue, Oct 30, 2012 at 08:11:15PM -0400, Glen Barber wrote:
> > > Oops, my bad. Yes exact same behavior; make -C release cdrom fails
> with
> > > ...
> > > find //tank/cvs/9.1/src/release/dist/doc -empty -delete
> > > find //tank/cvs/9.1/src
On Wed, Oct 31, 2012 at 4:35 AM, Glen Barber wrote:
> On Tue, Oct 30, 2012 at 11:19:12PM -0400, Glen Barber wrote:
> > So, please also do:
> >
> > svn merge -c241451 ^/head/release release
> >
>
> You'll want to merge one more revision:
>
> svn merge -c241596 ^/head/release release
>
> Sa
Hi
I'm running
FreeBSD stingray 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #3: Mon Oct 29 16:11:35
CET 2012 tl@stingray:/usr/obj/usr/src/sys/stingray amd64
on a new Dell laptop and keep getting these panics (typically once or twice per
day)
(kgdb) set pagination off
(kgdb) bt
#0 doadump (textd
schrieb Attilio Rao am 29.10.2012 23:02 (localtime):
> On Mon, Oct 29, 2012 at 7:37 PM, Harald Schmalzbauer
> wrote:
>> schrieb Attilio Rao am 27.10.2012 23:07 (localtime):
>>> On Sat, Oct 27, 2012 at 9:46 PM, Attilio Rao wrote:
On Sat, Sep 8, 2012 at 12:48 AM, Attilio Rao wrote:
> On
First, late me state status more clearly: solved :) Big thanks for fixing
it.
On a side note, how has re-team not run into this?
Best regards
Andreas
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To
On Wed, Oct 31, 2012 at 02:07:56PM +0100, Andreas Nilsson wrote:
> First, late me state status more clearly: solved :) Big thanks for fixing
> it.
>
Glad to help. To answer one of your previous questions, I've already
merged this to stable/9.
> On a side note, how has re-team not run into this?
On Wed, Oct 31, 2012 at 08:30:29AM +0100, Andreas Nilsson wrote:
> On a more whislist topic: I'd really appreciate if .zfs dirs would be
> excluded from the tarballs.
>
Hmm, I didn't realize this was happening.
So I can verify my change works for all environments, are you using any
local zfs d
Hi,
I am getting the following error on server Cisco UCS C200 M2 running
FreeBSD 8.3 amd64
Oct 31 02:15:22 ucs200 kernel: ACPI Error: No handler for Region [POWS]
(0xff000994f380) [IPMI] (20101013/evregion-487)
Oct 31 02:15:22 ucs200 kernel: ACPI Error: Region IPMI(0x7) has no
handler (
Other info:
zpool list tank2
NAMESIZE ALLOC FREECAP DEDUP HEALTH ALTROOT
tank219T 18.7T 304G98% 1.00x ONLINE -
zfs list tank2
NAMEUSED AVAIL REFER MOUNTPOINT
tank2 13.3T 0 13.3T /tank2
Running: 8.3-RELEASE-p4, zpool: v28, zfs: v5
- Original Messag
Hello,
We're seeing boot-time panics in about 4% of cases when upgrading from
FreeBSD 8.1 to 8.3-RELEASE (i386). This problem is subtle enough that
it escaped detection during our regular testing cycle... now with over
100 systems upgraded we're convinced there's a real issue. Our kernel
co
on 31/10/2012 12:14 Tom Lislegaard said the following:
> Hi
>
> I'm running
> FreeBSD stingray 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #3: Mon Oct 29
> 16:11:35 CET 2012 tl@stingray:/usr/obj/usr/src/sys/stingray amd64
> on a new Dell laptop and keep getting these panics (typically once or twic
On Wed, Oct 31, 2012 at 10:55 AM, Steven Hartland
wrote:
> At that point with the test seemingly successful I went
> to delete test files which resulted in:-
> rm random*
> rm: random1: Unknown error: 122
ZFS is a logging filesystem. Even removing a file apparently requires
some space to write a
On 2012-Oct-31 17:25:09 -, Steven Hartland wrote:
>Been running some tests on new hardware here to verify all
>is good. One of the tests was to fill the zfs array which
>seems like its totally corrupted the tank.
I've accidently "filled" a pool, and had multiple processes try to
write to the
On Wed, Oct 31, 2012 at 4:48 PM, Artem Belevich wrote:
> One way out of this jam is to try truncating some large file in place.
> Make sure that file is not part of any snapshot.
> Something like this may do the trick:
> #dd if=/dev/null of=existing_large_file
>
> Or, perhaps even something as sim
On 2012-Oct-31 17:25:09 -, Steven Hartland wrote:
Been running some tests on new hardware here to verify all
is good. One of the tests was to fill the zfs array which
seems like its totally corrupted the tank.
I've accidently "filled" a pool, and had multiple processes try to
write to the
15 matches
Mail list logo