On Wed, 24 Nov 2021, Warner Losh wrote:
On Wed, Nov 24, 2021 at 9:52 AM John Baldwin wrote:
On 11/24/21 3:30 AM, Bjoern A. Zeeb wrote:
Hi,
673 ===> usr.bin/diff/tests (cleandir)
674 ===> lib/geom (cleandir)
675 ===> sbin/mount_udf (cleandir)
676 make[6
On Wed, 24 Nov 2021 10:03:22 -0700
Warner Losh wrote:
> On Wed, Nov 24, 2021 at 9:52 AM John Baldwin wrote:
>
> > On 11/24/21 3:30 AM, Bjoern A. Zeeb wrote:
> > > Hi,
> > >
> > > 673 ===> usr.bin/diff/tests (cleandir)
> > > 674
On Wed, Nov 24, 2021 at 9:52 AM John Baldwin wrote:
> On 11/24/21 3:30 AM, Bjoern A. Zeeb wrote:
> > Hi,
> >
> > 673 ===> usr.bin/diff/tests (cleandir)
> > 674 ===> lib/geom (cleandir)
> > 675 ===> sbin/mount_udf (cleandir)
> >
On 11/24/21 3:30 AM, Bjoern A. Zeeb wrote:
Hi,
673 ===> usr.bin/diff/tests (cleandir)
674 ===> lib/geom (cleandir)
675 ===> sbin/mount_udf (cleandir)
676 make[6] warning: /lib/geom: Permission denied.
not sure what is going on here?
677 ===> sha
Hi,
673 ===> usr.bin/diff/tests (cleandir)
674 ===> lib/geom (cleandir)
675 ===> sbin/mount_udf (cleandir)
676 make[6] warning: /lib/geom: Permission denied.
not sure what is going on here?
677 ===> share/i18n/esdb/ISO-8859 (cleandir)
678 ===> tes
dev_p() failed (gp->name=ada1, error=17)
g_dev_taste: make_dev_p() failed (gp->name=ada1p2, error=17)
which may be a result of ZFS's GEOM integration (ada1p2 is the root
zpool); I can't really test the ZFS situation yet as I don't have a USB
drive at hand and still waiting for my
t; ===
> >
> > On 6/5/20 9:12 AM, Conrad Meyer wrote:
> > > Author: cem
> > > Date: Fri Jun 5 16:12:21 2020
> > > New Revision: 361838
> > > URL: https://svnweb.freebsd.org/changeset/base/361838
> > >
> > > Log:
> > > geom_label: Use pr
361838
> > URL: https://svnweb.freebsd.org/changeset/base/361838
> >
> > Log:
> > geom_label: Use provider aliasing to alias upstream geoms
> >
> > For synthetic aliases (just pseudonyms inferred from metadata like GPT or
> > UFS labels, GPT UUIDs
rred from metadata like GPT
> or
> > UFS labels, GPT UUIDs, etc), use the GEOM provider aliasing system to
> create
> > a symlink to the real device instead of creating an independent device.
> > This makes it more clear which labels and devices correspond, and we
>
; URL: https://svnweb.freebsd.org/changeset/base/361838
>
> Log:
> geom_label: Use provider aliasing to alias upstream geoms
>
> For synthetic aliases (just pseudonyms inferred from metadata like GPT or
> UFS labels, GPT UUIDs, etc), use the GEOM provider aliasing system to create
&g
attach the drive to the new 12 server. Reboot, and can't
> > boot to it && get the corrupt GPT message.
> >
> > GEOM seems to be broken in 12, maybe even (recent) 11. As the 11
> > server I used for testing is ~9 mos out.
> >
> > What can I do to (he
mnt && restore again. When I
> reboot to the external drive still connected to the old 11 server,
> I do *NOT* receive the corrupt GPT message. WooHoo! I think.
> So I re-attach the drive to the new 12 server. Reboot, and can't
> boot to it && get the corrupt GPT me
Hi I brought this up earlier, but didn't have as
much to go on as I do now. So I'd like to try this again;
On a recent(ish) install of CURRENT followed by a new
kernel/world. I'm finding I can't depend on geom(8) for
anything, but the primary (SATA3) drive, it's installed
On Mon, 20 Mar 2017 19:08:41 -0700
"Chris H" wrote:
> I've seen this discussed before, but there were so many
> "solutions", I was left feeling this *must* be some sort
> of bug in GEOM/gpart. So. I just blew away the tables on
> a USB3 flash drive:
>
On Tue, 21 Mar 2017 06:16:03 +0100 "O. Hartmann"
wrote
> On Mon, 20 Mar 2017 19:08:41 -0700
> "Chris H" wrote:
>
> > I've seen this discussed before, but there were so many
> > "solutions", I was left feeling this *must* be some sort
>
I've seen this discussed before, but there were so many
"solutions", I was left feeling this *must* be some sort
of bug in GEOM/gpart. So. I just blew away the tables on
a USB3 flash drive:
# gpart destroy -F da0
# gpart create -s gpt da0
# gpart add -t freebsd-ufs -l jails da0
On 15.09.2016 08:10, Zaphod Beeblebrox wrote:
> After this fail, I decided I didn't really _need_ to run linux here and I
> discovered 'geom_linux_lvm.ko' ... cool. But fail, too. Doesn't emit any
> messages. I even enabled the debug messages for it.
>
> The linux disk is partitioned thusly:
>
On Fri, Sep 16, 2016 at 1:06 AM, Allan Jude wrote:
> On 2016-09-16 01:04, Zaphod Beeblebrox wrote:
> >
> >
> >
> > Are you using zvols to back the VMs? Make sure they are in
> 'volmode=dev'
> > not 'geom' (the default), or GEOM wi
On 2016-09-16 01:04, Zaphod Beeblebrox wrote:
>
>
>
> Are you using zvols to back the VMs? Make sure they are in 'volmode=dev'
> not 'geom' (the default), or GEOM will lock the device when it detects a
> partition table being written to the zvo
> Are you using zvols to back the VMs? Make sure they are in 'volmode=dev'
> not 'geom' (the default), or GEOM will lock the device when it detects a
> partition table being written to the zvol (from the installer inside the
> VM)
>
> Note that this setting
;
> I can't seem to find any further documentation on my problem. Linux boots
> to it's initrd filesystem state and fails to leave it because it (claims
> it) can't find /sbin/init (even though in the CD case, it's there)
>
> GEOM ATTEMPT
>
> After this fail,
#x27;t find /sbin/init (even though in the CD case, it's there)
GEOM ATTEMPT
After this fail, I decided I didn't really _need_ to run linux here and I
discovered 'geom_linux_lvm.ko' ... cool. But fail, too. Doesn't emit any
messages. I even enabled the debug messages for
Garrett Cooper wrote:
> More breakage from projects/bmake. This should be fixed in theory, but
> bapt/sjg can confirm if it’s fixed. Cheers,
Yes, sorry everyone - took a bit to identify the root cause
(ie. specific line)
*Should* be fixed now.
___
fre
On Mon, Jun 15, 2015 at 11:57:10AM -0700, Garrett Cooper wrote:
> On Jun 15, 2015, at 4:40, Andrey Fesenko wrote:
>
> > Hello,
> > I'm build CURENT (r284408) for arm with crochet.
> >
> > all geom lasse's geom_*.so installed /usr/lib/ instead of /lib/geo
On Jun 15, 2015, at 4:40, Andrey Fesenko wrote:
> Hello,
> I'm build CURENT (r284408) for arm with crochet.
>
> all geom lasse's geom_*.so installed /usr/lib/ instead of /lib/geom
>
> /usr/obj/_.installworld.armv6.log
> ...
> ===> sbin/geom/class/cache (i
Hello,
I'm build CURENT (r284408) for arm with crochet.
all geom lasse's geom_*.so installed /usr/lib/ instead of /lib/geom
/usr/obj/_.installworld.armv6.log
...
===> sbin/geom/class/cache (install)
install -s -o root -g wheel -m 444 geom_cache.so
/usr/obj/_.mount.freebsd/usr/l
Hi.
> I've got the following panic running FreeBSD-11-current:
I'm sorry, it was my mistake. Should be fixed by r281310.
Though that is generally a bad Carma to loose active swap device.
--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
Hi,
I've got the following panic running FreeBSD-11-current:
panic: sleepq_add: td 0xc128a330 to sleep on wchan 0xc1bdd080 with
sleeping prohibited
After some digging, the call stack is the following:
...
g_io_schedule_up()
biodone()
swapgeom_done()
g_waitfor_event()
_sleep()
...
As biodone()
ystem from 2009 (only ggated) and didn't notice
any problems.
The patch didn't seem to affect the performance either way,
but then again I'm using slow disks and ssh so I didn't expect
geom gate to be the bottle neck.
Fabian
pgpSuTNRvSM3g.pgp
Description: OpenPGP digital signature
John-Mark Gurney wrote this message on Fri, Oct 17, 2014 at 09:58 -0700:
> Sourish Mazumder wrote this message on Fri, Oct 17, 2014 at 17:34 +0530:
> > I am planning to use geom gate network for accessing remote disks. I set up
> > geom gate as per the freebsd handbook. I am us
I am seeing this crash on r271882, booting a Soekris 4501.
POST: 012345689bcefghipsajklnopqr,,,tvwxy
comBIOS ver. 1.33 20080103 Copyright (C) 2000-2007 Soekris Engineering.
net45xx
0064 Mbyte MemoryCPU Elan SC520 133 Mhz
Pri Mas SanDisk SDCFX-016G LBA Xl
On Wednesday, December 18, 2013 11:52:54 pm Kurt Lidl wrote:
> Greetings all -
>
> I've got a completely reproducible panic when issuing a
> 'gmirror status' command on a recently deactivated gmirror.
>
> NOTE: This only happens on a machine with more than 1 CPU.
>
> I filed a bug report on it:
52
#9 0x81a371bf in g_mirror_dumpconf (sb=0xf80018310540,
indent=0x80ea9f7d "\t", gp=,
cp=, pp=)
at
/usr/src/sys/modules/geom/geom_mirror/../../../geom/mirror/g_mirror.c:3202
#10 0x8081a35c in g_conf_specific (sb=0xf80018310540, mp=0x0,
gp=0
.. the main reason to use machdep.idle=hlt is that it is a different code path.
But to ensure you're always going via the hlt codepath, you _first_
have to disable mwait.
The idle code first decides whether to run mwait or , then if it
doesn't choose mwait, it chooses machdep.idle. That's why you
On Tuesday, November 05, 2013 3:14:22 pm Oliver Pinter wrote:
> hmm, and seems like, the bottleneck are not in geom or cam, but in em
> driver or in networking stack
>
> the scenario is:
>
> A machine: dd if=/dev/ada1 bs=1M | nc -l
> B machine: nc IP | dd of=/de
hmm, and seems like, the bottleneck are not in geom or cam, but in em
driver or in networking stack
the scenario is:
A machine: dd if=/dev/ada1 bs=1M | nc -l
B machine: nc IP | dd of=/dev/null bs=1M
hmm, when dd-ing from /dev/zero and switch back to idletick to 0, then
the performance
dmesg corrected
On 11/5/13, Oliver Pinter wrote:
> On 11/5/13, Adrian Chadd wrote:
>> Ok, so it's only hitting C1. It's not going into C2.
>>
>> Is this a dual core CPU with hyperthreading enabled, or a quad core CPU?
>
> quad core, i5-4670
>
>>
>> How about changing the idle loop from acpi to h
On 11/5/13, Adrian Chadd wrote:
> Ok, so it's only hitting C1. It's not going into C2.
>
> Is this a dual core CPU with hyperthreading enabled, or a quad core CPU?
quad core, i5-4670
>
> How about changing the idle loop from acpi to hlt, see if that fixes
> things? (Without tweaking the event ti
and sysctl machdep.idle_mwait=0
-adrian
On 5 November 2013 10:12, Adrian Chadd wrote:
> Ok, so it's only hitting C1. It's not going into C2.
>
> Is this a dual core CPU with hyperthreading enabled, or a quad core CPU?
>
> How about changing the idle loop from acpi to hlt, see if that fixes
>
Ok, so it's only hitting C1. It's not going into C2.
Is this a dual core CPU with hyperthreading enabled, or a quad core CPU?
How about changing the idle loop from acpi to hlt, see if that fixes
things? (Without tweaking the event timer logic.)
I'm worried that what you're seeing here are missed
op@perpetua ~> sysctl dev.cpu
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.coretemp.delta: 59
dev.cpu.0.coretemp.resolution: 1
dev.cpu.0.coretemp.tjmax: 100.0C
dev.cpu.0.coretemp.throt
Hi!
Can you do 'sysctl dev.cpu' please? I'd like to see what sleep
state(s) your CPU is entering.
Thanks!
-adrian
On 5 November 2013 06:07, Oliver Pinter wrote:
> Hi all!
>
> The machine is a Haswell machine, the disc performance was very poor
> (20-30MByte/sec).
> When I change the kern.eve
Hi all!
The machine is a Haswell machine, the disc performance was very poor
(20-30MByte/sec).
When I change the kern.eventtimer.idletick from 0 to 1, the normal
performance restored back to normal (70-90MByte/sec).
The default eventtimer was LAPIC.
On other machine Q9300, this was fully reprodu
the feedback. But looking on mfi driver sources I would
say that it calls biodone() from mfi_disk_complete() from cm_complete()
method, which is called while holding mfi_io_lock mutex. I guess that if
on top of mfi device would be some GEOM class, supporting direct
dispatch and sending new reques
d worked fine for handling
g_up
> > directly:
> >
> > Index: dev/mfi/mfi_disk.c
> > ===
> > --- dev/mfi/mfi_disk.c (revision 257407)
> > +++ dev/mfi/mfi_disk.c (working copy)
> > @@ -162,6 +
cm_complete()
method, which is called while holding mfi_io_lock mutex. I guess that if
on top of mfi device would be some GEOM class, supporting direct
dispatch and sending new requests down on previous request completion
(or retrying requests), that could cause recursive mfi_io_lock
acquisition
On Saturday, September 07, 2013 2:32:45 am Alexander Motin wrote:
> On 07.09.2013 02:02, Jeremie Le Hen wrote:
> > On Fri, Sep 06, 2013 at 11:29:11AM +0300, Alexander Motin wrote:
> >> On 06.09.2013 11:06, Jeremie Le Hen wrote:
> >>> On Fri, Sep 06, 2013 at 12:46:27AM +0200, Olivier Cochard-Labbé w
2 controller): Used for generating package with
> poudriere? no probleme since;
> - HAL/Fujitsu SPARC64-V (sparc64: r255178) with two SCSI-3 disks in
> gmirror: Used for generating package with poudriere too? no probleme
> since;
For testing GEOM direct dispatch on sparc64, please additionally
Alexander Motin wrote:
> I would like to invite more people to review and test my patches for
> improving CAM and GEOM scalability, that for last six months you could
> see developing in project/camlock SVN branch. Full diff of that branch
> against present head (r255131) can b
On 07.09.2013 02:02, Jeremie Le Hen wrote:
On Fri, Sep 06, 2013 at 11:29:11AM +0300, Alexander Motin wrote:
On 06.09.2013 11:06, Jeremie Le Hen wrote:
On Fri, Sep 06, 2013 at 12:46:27AM +0200, Olivier Cochard-Labbé wrote:
On Thu, Sep 5, 2013 at 11:38 PM, Alexander Motin wrote:
I've found and
On Fri, Sep 06, 2013 at 11:29:11AM +0300, Alexander Motin wrote:
> On 06.09.2013 11:06, Jeremie Le Hen wrote:
> > On Fri, Sep 06, 2013 at 12:46:27AM +0200, Olivier Cochard-Labbé wrote:
> >> On Thu, Sep 5, 2013 at 11:38 PM, Alexander Motin wrote:
> >>> I've found and fixed possible double request c
On 06.09.2013 11:06, Jeremie Le Hen wrote:
On Fri, Sep 06, 2013 at 12:46:27AM +0200, Olivier Cochard-Labbé wrote:
On Thu, Sep 5, 2013 at 11:38 PM, Alexander Motin wrote:
I've found and fixed possible double request completion, that could cause
such symptoms if happened. Updated patch located a
On Fri, Sep 06, 2013 at 12:46:27AM +0200, Olivier Cochard-Labbé wrote:
> On Thu, Sep 5, 2013 at 11:38 PM, Alexander Motin wrote:
> > I've found and fixed possible double request completion, that could cause
> > such symptoms if happened. Updated patch located as usual:
> > http://people.freebsd.or
On Thu, Sep 5, 2013 at 11:38 PM, Alexander Motin wrote:
> I've found and fixed possible double request completion, that could cause
> such symptoms if happened. Updated patch located as usual:
> http://people.freebsd.org/~mav/camlock_patches/camlock_20130905.patch
>
Good catch!
this new patch (ap
On 04.09.2013 19:31, Olivier Cochard-Labbé wrote:
On Wed, Sep 4, 2013 at 9:01 AM, Alexander Motin wrote:
- HP EliteBook 8460p (amd64: r255188) with DVD replaced by a second
hardrive (where fbsd is installed): It crash just after the message
"GEOM: new disk ada1" during boot
scr
On 09/04/13 11:00, John Baldwin wrote:
On Wednesday, September 04, 2013 10:11:28 am Nathan Whitehorn wrote:
On 09/04/13 08:20, Ryan Stone wrote:
On Wed, Sep 4, 2013 at 8:45 AM, Nathan Whitehorn
wrote:
Could you describe what this macro is supposed to do so that we can do
the
porting work?
On Wed, Sep 4, 2013 at 9:01 AM, Alexander Motin wrote:
>
>> - HP EliteBook 8460p (amd64: r255188) with DVD replaced by a second
>> hardrive (where fbsd is installed): It crash just after the message
>> "GEOM: new disk ada1" during boot
>>
>> screenshot o
On Wednesday, September 04, 2013 10:11:28 am Nathan Whitehorn wrote:
> On 09/04/13 08:20, Ryan Stone wrote:
> > On Wed, Sep 4, 2013 at 8:45 AM, Nathan Whitehorn
wrote:
> >> Could you describe what this macro is supposed to do so that we can do
the
> >> porting work?
> >> -Nathan
> > #define GET_
On 09/04/13 08:20, Ryan Stone wrote:
On Wed, Sep 4, 2013 at 8:45 AM, Nathan Whitehorn wrote:
Could you describe what this macro is supposed to do so that we can do the
porting work?
-Nathan
#define GET_STACK_USAGE(total, used)
GET_STACK_USAGE sets the variable passed in total to the total amo
oller): Used for generating package with
poudriere… no probleme since;
- HAL/Fujitsu SPARC64-V (sparc64: r255178) with two SCSI-3 disks in
gmirror: Used for generating package with poudriere too… no probleme
since;
I've forgot to mention, but GEOM direct dispatch is now active only on
x
On Wed, Sep 4, 2013 at 8:45 AM, Nathan Whitehorn wrote:
> Could you describe what this macro is supposed to do so that we can do the
> porting work?
> -Nathan
#define GET_STACK_USAGE(total, used)
GET_STACK_USAGE sets the variable passed in total to the total amount
of stack space available to th
with
poudriere… no probleme since;
- HAL/Fujitsu SPARC64-V (sparc64: r255178) with two SCSI-3 disks in
gmirror: Used for generating package with poudriere too… no probleme
since;
I've forgot to mention, but GEOM direct dispatch is now active only on
x86 because GET_STACK_USAGE macro now defined only
On 04.09.2013 11:20, Johan Hendriks wrote:
Alexander Motin wrote:
I would like to invite more people to review and test my patches for
improving CAM and GEOM scalability, that for last six months you could
see developing in project/camlock SVN branch. Full diff of that branch
against present
Alexander Motin wrote:
Hi.
I would like to invite more people to review and test my patches for
improving CAM and GEOM scalability, that for last six months you could
see developing in project/camlock SVN branch. Full diff of that branch
against present head (r255131) can be found here
C64-V (sparc64: r255178) with two SCSI-3 disks in
gmirror: Used for generating package with poudriere too… no probleme
since;
I've forgot to mention, but GEOM direct dispatch is now active only on
x86 because GET_STACK_USAGE macro now defined only there and I wanted to
stay on a safe side
> > > Hi.
> > > >
> > > > I would like to invite more people to review and test my patches for
> > > > improving CAM and GEOM scalability, that for last six months you could
> > > > see developing in project/camlock SVN branch. Full diff o
ond
> hardrive (where fbsd is installed): It crash just after the message
> "GEOM: new disk ada1" during boot
>
> screenshot of the crash screen:
> http://goo.gl/tW1VIx
>
> A little more information:
> addr2line -e /boot/kernel/kernel.symbols 0x8083abd3
>
o SCSI-3 disks in
gmirror: Used for generating package with poudriere too… no probleme
since;
- HP EliteBook 8460p (amd64: r255188) with DVD replaced by a second
hardrive (where fbsd is installed): It crash just after the message
"GEOM: new disk ada1" during boot
screenshot of the crash s
and test my patches for
> > > improving CAM and GEOM scalability, that for last six months you could
> > > see developing in project/camlock SVN branch. Full diff of that branch
> > > against present head (r255131) can be found here:
> > > http://people.free
On Tue, Sep 3, 2013 at 9:42 AM, Jeremie Le Hen wrote:
> On Mon, Sep 02, 2013 at 11:49:33AM +0300, Alexander Motin wrote:
> > Hi.
> >
> > I would like to invite more people to review and test my patches for
> > improving CAM and GEOM scalability, that for last s
On Mon, Sep 02, 2013 at 11:49:33AM +0300, Alexander Motin wrote:
> Hi.
>
> I would like to invite more people to review and test my patches for
> improving CAM and GEOM scalability, that for last six months you could
> see developing in project/camlock SVN branch. Full diff
Hi.
I would like to invite more people to review and test my patches for
improving CAM and GEOM scalability, that for last six months you could
see developing in project/camlock SVN branch. Full diff of that branch
against present head (r255131) can be found here:
http://people.freebsd.org
I am try to build SAN with iSCSI access based on FreeBSD+ZFS.
LUN emulated by ZFS volume. Because partitioned not contrlled and can
be dangerous (even threat host OS) I needed to filtered some /dev
subtree from GPART (temporary or permanently).
How do i do this?
___
In message
, Ivan Voras writes:
> On 17 April 2013 00:44, Cy Schubert wrote:
>
> > You were correct. Backing out r249508 in my tree resolves the panic on both
> > hosts.
>
> Hi,
>
> Sorry about that - should be fixed by
> http://svnweb.freebsd.org/base?view=revision&revision=249564 .
>
hey,
On 17 April 2013 00:44, Cy Schubert wrote:
> You were correct. Backing out r249508 in my tree resolves the panic on both
> hosts.
Hi,
Sorry about that - should be fixed by
http://svnweb.freebsd.org/base?view=revision&revision=249564 .
___
freebsd-curr
_
> > freebsd-current@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
> Hi,
>
> It should be related
On Tue, Apr 16, 2013 at 01:01:49PM -0700, Jim Harris wrote:
> ...
> > I had built head @r249538 this morning, and that's the build where
> > my smoke-test failed.
> >
> >
> This stack trace corruption was noted on svn-src-head@ as well, and appears
> to be fixed with r249564.
>
Cool; thanks -
On Tue, Apr 16, 2013 at 11:13 AM, David Wolfskill wrote:
> On Tue, Apr 16, 2013 at 10:56:31AM -0700, Cy Schubert wrote:
> > Has anyone see this before? Just updated my CURRENT partitions on my
> > testbed and laptop. The laptop just boots but I've managed to capture
> this
> > on my testbed (attac
On Tue, Apr 16, 2013 at 10:56:31AM -0700, Cy Schubert wrote:
> Has anyone see this before? Just updated my CURRENT partitions on my
> testbed and laptop. The laptop just boots but I've managed to capture this
> on my testbed (attached to a serial port on another system).
>
> This is HEAD from ye
Has anyone see this before? Just updated my CURRENT partitions on my
testbed and laptop. The laptop just boots but I've managed to capture this
on my testbed (attached to a serial port on another system).
This is HEAD from yesterday (Apr 15) morning (PDT). The partition being
booted is ada0s1d.
On Mon, 2012-08-06 at 08:34 -0700, Maksim Yevmenkin wrote:
> Michael,
>
> > Something in -current and recently MFC'd to -stable is causing all of my
> > gmirror drives to rebuild on reboot :-(
> >
> > Being remote and these being production machines, I suspect SVN r237929
> > and r237930 in -curre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/06/12 14:06, Gleb Smirnoff wrote:
> Michael,
>
> On Sat, Aug 04, 2012 at 12:49:49PM -0400, Michael Butler wrote:
> M> Something in -current and recently MFC'd to -stable is causing all of my
> M> gmirror drives to rebuild on reboot :-(
> M>
>
Alexander Motin wrote:
I think the right answer would be to remove stale Promise format RAID metadata
from the disk. You should be able to do it by booting from any source and
doing `graid list -a` to see all RAID GEOMs (even broken) and then remove them
with `graid remove Promise ad4`.
thanks,
On 07.08.2012 17:09, Andrey V. Elsukov wrote:
On 07.08.2012 04:03, Tom Uffner wrote:
GEOM_RAID: Promise: Array Promise Created
GEOM_RAID: Promise: Disk ad4 state changed from NONE to SPARE
GEOM_MIRROR: Cannot open consumer ad4 (error=1)
GEOM_MIRROR: Cannot add disk ad4 to gm0 (error=1)
wondering
On 07.08.2012 04:03, Tom Uffner wrote:
> GEOM_RAID: Promise: Array Promise Created
> GEOM_RAID: Promise: Disk ad4 state changed from NONE to SPARE
> GEOM_MIRROR: Cannot open consumer ad4 (error=1)
> GEOM_MIRROR: Cannot add disk ad4 to gm0 (error=1)
> wondering if anyone knew offhand what is going o
by any chance...
... is this maybe related to my PR:
http://www.freebsd.org/cgi/query-pr.cgi?pr=170038
cheers,
Frank Reppin
--
43rd Law of Computing:
Anything that can go wr
fortune: Segmentation violation -- Core dumped
___
freebsd-current@
not quite the same issue, but i tried to update a system with gmirror from
FreeBSD eris.uffner.com 10.0-CURRENT FreeBSD 10.0-CURRENT #210: Thu Mar 15
16:41:18 EDT 2012 t...@eris.uffner.com:/usr/obj/usr/src/sys/ERIS i386
to -current from Aug 4th, and booting now fails into mountroot> with
On Aug 6, 2012, at 12:06 PM, Gleb Smirnoff wrote:
> Michael,
>
> On Sat, Aug 04, 2012 at 12:49:49PM -0400, Michael Butler wrote:
> M> Something in -current and recently MFC'd to -stable is causing all of my
> M> gmirror drives to rebuild on reboot :-(
> M>
> M> Being remote and these being pr
Sorry but I'm not going to be able to get to this until next w/e as I'm ~1500
miles away from them at present :-(
-Original Message-
From: Gleb Smirnoff
Sent: Monday, 6 August 2012 14:06
To: Michael Butler
Cc: curr...@freebsd.org; sta...@freebsd.org
Subject: Re: geom
: geom mirror now rebuilding on every reboot?
On Mon, Aug 6, 2012 at 9:23 AM, Garrett Cooper wrote:
> On Mon, Aug 6, 2012 at 8:34 AM, Maksim Yevmenkin
> wrote:
>> Michael,
>>
>>> Something in -current and recently MFC'd to -stable is causing all of my
>>
Michael,
On Sat, Aug 04, 2012 at 12:49:49PM -0400, Michael Butler wrote:
M> Something in -current and recently MFC'd to -stable is causing all of my
M> gmirror drives to rebuild on reboot :-(
M>
M> Being remote and these being production machines, I suspect SVN r237929
M> and r237930 in -curren
On Aug 6, 2012, at 9:40 AM, Maksim Yevmenkin wrote:
> On Mon, Aug 6, 2012 at 9:33 AM, Kevin Oberman wrote:
>> On Mon, Aug 6, 2012 at 9:26 AM, Maksim Yevmenkin
>> wrote:
>>> On Mon, Aug 6, 2012 at 9:23 AM, Garrett Cooper wrote:
On Mon, Aug 6, 2012 at 8:34 AM, Maksim Yevmenkin
wrote:
On Mon, Aug 6, 2012 at 9:33 AM, Kevin Oberman wrote:
> On Mon, Aug 6, 2012 at 9:26 AM, Maksim Yevmenkin
> wrote:
>> On Mon, Aug 6, 2012 at 9:23 AM, Garrett Cooper wrote:
>>> On Mon, Aug 6, 2012 at 8:34 AM, Maksim Yevmenkin
>>> wrote:
Michael,
> Something in -current and recently M
On Mon, Aug 6, 2012 at 9:26 AM, Maksim Yevmenkin
wrote:
> On Mon, Aug 6, 2012 at 9:23 AM, Garrett Cooper wrote:
>> On Mon, Aug 6, 2012 at 8:34 AM, Maksim Yevmenkin
>> wrote:
>>> Michael,
>>>
Something in -current and recently MFC'd to -stable is causing all of my
gmirror drives to rebu
On Mon, Aug 6, 2012 at 9:23 AM, Garrett Cooper wrote:
> On Mon, Aug 6, 2012 at 8:34 AM, Maksim Yevmenkin
> wrote:
>> Michael,
>>
>>> Something in -current and recently MFC'd to -stable is causing all of my
>>> gmirror drives to rebuild on reboot :-(
>>>
>>> Being remote and these being production
On Mon, Aug 6, 2012 at 8:34 AM, Maksim Yevmenkin
wrote:
> Michael,
>
>> Something in -current and recently MFC'd to -stable is causing all of my
>> gmirror drives to rebuild on reboot :-(
>>
>> Being remote and these being production machines, I suspect SVN r237929
>> and r237930 in -current and S
Michael,
> Something in -current and recently MFC'd to -stable is causing all of my
> gmirror drives to rebuild on reboot :-(
>
> Being remote and these being production machines, I suspect SVN r237929
> and r237930 in -current and SVN r238500 to -stable but haven't yet been
> able to prove it.
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Something in -current and recently MFC'd to -stable is causing all of my
gmirror drives to rebuild on reboot :-(
Being remote and these being production machines, I suspect SVN r237929
and r237930 in -current and SVN r238500 to -stable but haven't yet
On Fri, Jun 22, 2012 at 19:50:01 +0300, Alexander Motin wrote:
> Hi.
>
> I understand problem you are going to fix and I think your patch should
> do it. What I don't very like is addition of new GEOM method. Now GEOM
> doesn't need it because all internal open/clos
Hi.
I understand problem you are going to fix and I think your patch should
do it. What I don't very like is addition of new GEOM method. Now GEOM
doesn't need it because all internal open/close operations and provider
destructions there protected by the topology SX lock. Unluckily
1 - 100 of 669 matches
Mail list logo
