On Mon, Jul 21, 2008 at 12:29:54AM +0200, Daniel Eriksson wrote:
Pawel Jakub Dawidek wrote:
Can you try this patch?
http://people.freebsd.org/~pjd/patches/space_map.c.patch
Now it panics (solaris assert) at line 431 in dmu.c. I'll try to get a
backtrace in a day or two if it
On Mon, Jul 21, 2008 at 11:02:36AM +0200, Pawel Jakub Dawidek wrote:
On Mon, Jul 21, 2008 at 12:29:54AM +0200, Daniel Eriksson wrote:
Pawel Jakub Dawidek wrote:
Can you try this patch?
http://people.freebsd.org/~pjd/patches/space_map.c.patch
Now it panics (solaris assert) at
Quoting Oleg V. Nauman [EMAIL PROTECTED]:
Quoting Jeremy Chadwick [EMAIL PROTECTED]:
On Sat, Jul 19, 2008 at 10:03:15AM +0300, Oleg V. Nauman wrote:
It seems to be something was changed with ACPI support on 7.0-STABLE so
my next system upgrade ended with ACPI HPET not working anymore on my
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: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0
Timecounter
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
On Thu, 17 Jul 2008 08:31:37 -0400
Kevin K [EMAIL PROTECTED] wrote:
For 7.0-RELEASE, it
seemed to hang at Trying to mount root from ufs:/dev/md0.
How long did you wait? If you didn't wait 10 or 15 minutes, please do.
Various tests / probes take a long time to time out on some hardware.
Pawel Jakub Dawidek wrote:
I'm afraid your pool's metadata is
somehow corrupted that ZFS can't handle that.
Yes, that's my conclusion also. It looks like the intent log is messed
up enough to trigger an assert while ZFS tries to parse/replay it.
I saw warnings in your
first e-mail about ZFS
On Mon, Jul 21, 2008 at 03:49:24PM +0200, Daniel Eriksson wrote:
Pawel Jakub Dawidek wrote:
I'm afraid your pool's metadata is
somehow corrupted that ZFS can't handle that.
Yes, that's my conclusion also. It looks like the intent log is messed
up enough to trigger an assert while ZFS
On Mon, Jul 21, 2008 at 03:51:56PM +0200, Pawel Jakub Dawidek wrote:
On Mon, Jul 21, 2008 at 03:49:24PM +0200, Daniel Eriksson wrote:
Pawel Jakub Dawidek wrote:
I'm afraid your pool's metadata is
somehow corrupted that ZFS can't handle that.
Yes, that's my conclusion also. It
Pete French presumably uttered the following on 07/21/08 07: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
On Mon, Jul 21, 2008 at 9:26 AM, Kevin K [EMAIL PROTECTED] wrote:
On Thu, 17 Jul 2008 08:31:37 -0400
Kevin K [EMAIL PROTECTED] wrote:
For 7.0-RELEASE, it
seemed to hang at Trying to mount root from ufs:/dev/md0.
How long did you wait? If you didn't wait 10 or 15 minutes, please do.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Brett Glass wrote:
| Everyone:
|
| Will FreeBSD 7.1 be released in time to use it as an upgrade to
| close the BIND cache poisoning hole?
Brett, et al,
I'll make this simple for you. If you have a server that is running
BIND, update BIND now.
On Monday 21 July 2008 21:14:22 Doug Barton wrote:
Brett Glass wrote:
| Everyone:
|
| Will FreeBSD 7.1 be released in time to use it as an upgrade to
| close the BIND cache poisoning hole?
Brett, et al,
I'll make this simple for you. If you have a server that is running
BIND, update BIND
From: Max Laier [EMAIL PROTECTED]
Date: Mon, 21 Jul 2008 21:38:46 +0200
Sender: [EMAIL PROTECTED]
On Monday 21 July 2008 21:14:22 Doug Barton wrote:
Brett Glass wrote:
| Everyone:
|
| Will FreeBSD 7.1 be released in time to use it as an upgrade to
| close the BIND cache poisoning
On Monday 21 July 2008 06:46:48 am Jeremy Chadwick wrote:
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: High Precision
Thanks for the note. No, just a coincidence. The chipset is a VIA
ProSavageDDR KM266.
But thanks for bringing that up ;-)
FWIW, as others have speculated enabling more logging from GEOM
produced nothing. It does appear to be a hardware failure of some sort.
On Jul 18, 2008, at 11:29
The ZFS code in 7.0 is the same as in HEAD, so no worries.
I'm trying zfs myself in a small enviroment at home, but for that I do
follow 7-STABLE. there's no need to do that, as based in the above
statement ?
thanks,
matheus
--
We will call you cygnus,
The God of balance you shall be
On Monday 21 July 2008 06:07:52 am Oleg V. Nauman wrote:
Quoting Oleg V. Nauman [EMAIL PROTECTED]:
Quoting Jeremy Chadwick [EMAIL PROTECTED]:
On Sat, Jul 19, 2008 at 10:03:15AM +0300, Oleg V. Nauman wrote:
It seems to be something was changed with ACPI support on 7.0-STABLE so
my next
At 02:24 PM 7/21/2008, Kevin Oberman wrote:
Don't forget that ANY server that caches data, including an end system
running a caching only server is vulnerable.
Actually, there is an exception to this. A forward only cache/resolver is
only as vulnerable as its forwarder(s). This is a workaround
On Mon, 21 Jul 2008, Kevin Oberman wrote:
From: Max Laier [EMAIL PROTECTED]
Date: Mon, 21 Jul 2008 21:38:46 +0200
Sender: [EMAIL PROTECTED]
On Monday 21 July 2008 21:14:22 Doug Barton wrote:
Brett Glass wrote:
| Everyone:
|
| Will FreeBSD 7.1 be released in time to use it as an upgrade to
|
On Tuesday 22 July 2008 00:31:53 Charles Sprickman wrote:
On Mon, 21 Jul 2008, Kevin Oberman wrote:
From: Max Laier [EMAIL PROTECTED]
Date: Mon, 21 Jul 2008 21:38:46 +0200
Sender: [EMAIL PROTECTED]
On Monday 21 July 2008 21:14:22 Doug Barton wrote:
Brett Glass wrote:
| Everyone:
|
21 matches
Mail list logo
