|
|
 Up |
|
|
  |
Author: Pete FrenchPete French
Date: Jul 21, 2008 04:08
> The *big* issue I have right now is dealing with the slave machine going
> down. Once the master no longer has a connection to the ggated devices,
> all processes trying to use the device hang in D status. I have tried
> pkill'ing ggatec to no avail and ggatec destroy returns a message of
> gctl being busy. Trying to ggatec destroy -f panics the machine.
Oddly enough, this was the issue I had with iscsi which made me move
to using ggated instead. On our machines I use '-t 10' as an argument to
ggatec, and this makes it timeout once the connection has been down for
a certain amount of time. I am using gmirror on top, not ZFS, and this
handled the drive vanishing from the mirror quite happily. I haven't
tried it with ZFS, which may not like having the device suddenly dissapear.
-pete.
|
| |
|
| |
1 Comment |
|
|
Author: Jeremy ChadwickJeremy Chadwick
Date: Jul 21, 2008 03:46
On Mon, Jul 21, 2008 at 01:07:52PM +0300, Oleg V. Nauman wrote:
> Well.. Backout 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c
> (committed to RELENG_7 at July 10 by jhb) fixes this issue for me:
>
> acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0
> Timecounter "HPET" frequency 14318180 Hz quality 900
>
> kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0)
> dummy(-1000000)
> kern.timecounter.hardware: HPET
>
> Hopefully it helps to understand what is went wrong there.
John, do you have any ideas WRT this regression? HPET on this user's
system has the most granularity.
--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
|
| |
|
| |
no comments
|
|
|
Author: UngaUnga
Date: Jul 20, 2008 22:11
--- On Sun, 7/20/08, Peter Jeremy optushome.com.au> wrote:
> From: Peter Jeremy optushome.com.au>
> Subject: Re: Pseudoterminals increase: compilation error
> To: "Unga" yahoo.com>
> Cc: freebsd-stable@freebsd.org
> Date: Sunday, July 20...
|
| Show full article (1.14Kb) |
|
no comments
|
|
|
Author: UngaUnga
Date: Jul 20, 2008 06:41
--- On Sun, 7/20/08, Peter Jeremy optushome.com.au> wrote:
> From: Peter Jeremy optushome.com.au>
> Subject: Re: Pseudoterminals increase: compilation error
> To: "Unga" yahoo.com>
> Cc: freebsd-stable@freebsd.org
> Date: Sunday, July 20...
|
| Show full article (1.38Kb) |
|
no comments
|
|
|
Author: UngaUnga
Date: Jul 19, 2008 22:19
--- On Sun, 7/20/08, Unga yahoo.com> wrote:
> From: Unga yahoo.com>
> Subject: Re: Pseudoterminals increase: compilation error
> To: "Dan Nelson" allantgroup.com>
> Cc: freebsd-stable@freebsd.org
> Date: Sunday, July 20, 2008,...
|
| Show full article (3.63Kb) |
|
no comments
|
|
|
|
|
|
|
|
|
Author: Daniel ErikssonDaniel Eriksson
Date: Jul 19, 2008 01:51
I have a large ZFS pool that seems to be partially corrupt, causing a
panic on ZFS startup. This is on a RELENG_7_0 machine.
This is what happens when I try to start ZFS (written down by hand):
ZFS: WARNING: can't process intent log for tank02/home
ZFS: WARNING: can't process intent log for tank02
panic: solaris assert: dmu_read(os, smo->smo_object, offset, size,
entry_map) == 0 (0x5 == 0x0), file:
/usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/spa
ce_map.c, line: 341
The pool sits on top of a geli-encrypted hardware raid-array (Highpoint
RocketRAID 2340, 8 x 500GB in RAID-5 config). Unfortunately the array
broke (2 drives disconnected) due to a bad PSU, and this eventually
crashed the box. When I restarted the box the above message showed up as
soon as I started ZFS.
It is my understanding that the intent log is emptied on clean shutdown,
and if it is not empty during startup ZFS tries to "replay" the
transactions recorded in it. I assume the initial crash left the intent
log in an inconsistent state and that ZFS panics on startup due to badly
formatted data in the intent log.
|
| Show full article (1.22Kb) |
|
11 Comments |
|
|
Author: UngaUnga
Date: Jul 18, 2008 19:53
--- On Sat, 7/19/08, Unga yahoo.com> wrote:
> From: Unga yahoo.com>
> Subject: Re: Pseudoterminals increase: compilation error
> To: "Steven Hartland" multiplay.co.uk>
> Cc: freebsd-stable@freebsd.org
> Date: Saturday, July 19...
|
| Show full article (1.02Kb) |
|
no comments
|
|
|
|
|
|
Author: UngaUnga
Date: Jul 18, 2008 19:50
--- On Sat, 7/19/08, Steven Hartland multiplay.co.uk> wrote:
> From: Steven Hartland multiplay.co.uk>
> Subject: Re: Pseudoterminals increase: compilation error
> To: unga888@yahoo.com
> Cc: freebsd-stable@freebsd.org
> Date: Saturday, July 19, 2008, 10:38 AM
> Ahh according to the man page its not a sysctl:
> kern.pts.max
>
> man 4 pty for more info.
>
I use the the original BSD pty. According to the man page kern.pts.max is for SysVR4 pts-like implementation, well, that how I understand. Anyway, I'll give it a try and let the list know.
Regards
Unga
|
| |
|
no comments
|
|
|
|
|
|
|
