On 2009-Mar-25 07:21:37 -0500, "Jack L. Stone" wrote:
>However, last month upon upon upgrading those servers from FBSD-6.3px
>(RELEASE) to 7.0px (RELEASE) we found that about one-half of the servers
>had a similar problem as the original poster while the other half did not.
...
>the next day, and
On Thursday 26 March 2009 19:55:04 Peter Jeremy wrote:
> On 2009-Mar-25 19:25:28 +1030, Daniel O'Connor
wrote:
> >One other thing would be to make absolutely sure that your version of dump
> > & restore are in sync, the are very machine/version dependent.
>
> Actually, they aren't - the archive f
On 2009-Mar-25 19:25:28 +1030, Daniel O'Connor wrote:
>One other thing would be to make absolutely sure that your version of dump &
>restore are in sync, the are very machine/version dependent.
Actually, they aren't - the archive format is very stable. (This is a
fairly important requirement -
On Thu, Mar 26, 2009 at 10:59:25AM +, John wrote:
> Weongyo Jeong wrote:
>
> > Could you please test it with attached patch to fix a page fault? I
> > don't know why bus_dma_tag_create() returns ENOMEM that it looks
> > temporary.
>
> Hi, thanks for this, I'll try it when I get home tonight.
Weongyo Jeong wrote:
> Could you please test it with attached patch to fix a page fault? I
> don't know why bus_dma_tag_create() returns ENOMEM that it looks
> temporary.
Hi,
Seems the patch failed to apply:
[r...@potato /usr/src/sys/dev/malo]# ls -la
total 140
drwxr-xr-x2 root wheel5
Weongyo Jeong wrote:
> Could you please test it with attached patch to fix a page fault? I
> don't know why bus_dma_tag_create() returns ENOMEM that it looks
> temporary.
Hi, thanks for this, I'll try it when I get home tonight. Not all that
familiar with patching though. I guess I go to where m
At 09:45 AM 3.25.2009 -0500, Peggy Wilkins wrote:
>> Jack L Stone writes:
>
>>> I've been watching this thread with some interest since we've had some
>>> similar problems with dump/restore which we use every morning via cron
>>> scripts on a number of servers to produce bootable
At 07:53 AM 3/26/2009, Jack L. Stone wrote:
>>> SOLUTION
>>> The "clones" are a very important pasrt of our backup program.
Since the
>>> dump side of the problems simply stuck and provided no error
message at all
>>> and the errors from any restores were not useful, our only solu
Hi,
I followed this thread out of interest since I do not suffer from this error.
But I wonder if truss could shed some light into this issue. If for
example a dump hangs at 99%, it might be an idea to set up truss to
trace the dump process. Yes, this will produce lots of output, but
maybe it give
At 07:57 AM 3.26.2009 -0400, Mike Tancsa wrote:
>>
>>Thanks for the reply. Forgot to mention, our machines are all i386 with the
>>problem -- so are the ones without the problem.
>>
>>Yes, I found that patch too and tried it on one of the servers -- no joy.
>>
>>Guess we'll continue to wait also fo
Pyun YongHyeon wrote:
> #cd /usr/src/sys/dev/malo
> #patch -p0 < /path/to/patch_malo_20090326_panic.diff
>
> And rebuild malo(4)/kernel.
Ok thanks for that, I'll try again
--
John
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/ma
Pyun YongHyeon wrote:
> #cd /usr/src/sys/dev/malo
> #patch -p0 < /path/to/patch_malo_20090326_panic.diff
>
> And rebuild malo(4)/kernel.
No luck I'm afraid:
[r...@potato /usr/src/sys/dev/malo]# patch -p0 <
patch_malo_20090326_panic.diff
Hmm... Looks like a unified diff to me...
The text leadi
On 3/26/09, John wrote:
> Weongyo Jeong wrote:
>
>> Could you please test it with attached patch to fix a page fault? I
>> don't know why bus_dma_tag_create() returns ENOMEM that it looks
>> temporary.
>
> Hi,
>
> Seems the patch failed to apply:
Patch is so trivial and short that it can be appl
Paul B. Mahol wrote:
>
> Patch is so trivial and short that it can be applied manually.
>
> Are you sure that you use 7 STABLE sources and not CURRENT one?
I'm absolutely certain. Sources from the 25th March, make world and
kernel the day after:
[r...@potato ~]# uname -a
FreeBSD potato.growveg
Hello,
In the past I could catch a panic during boot via a serial cable connected
to another computer.
My new computer only has USB-ports and ethernet. What kind of cable do I
need now to do remote debugging?
The old computer also has usb, so I think the connection should be in that
corner.
On Thu, Mar 26, 2009 at 01:56:13PM +0100, Ronald Klop wrote:
> Hello,
>
> In the past I could catch a panic during boot via a serial cable connected
> to another computer.
> My new computer only has USB-ports and ethernet. What kind of cable do I
> need now to do remote debugging?
> The old co
At 08:08 AM 3/26/2009, Jack L. Stone wrote:
Yes, but it's for running a dump on a (L)ive FS and just spits out warnings
to that effect and has no effect on solving the problem(s).
Unless the filesystem is very busy, you will get your data backed up.
If you have things like databases, I still
On 3/26/09, John wrote:
> Paul B. Mahol wrote:
>
>>
>> Patch is so trivial and short that it can be applied manually.
>>
>> Are you sure that you use 7 STABLE sources and not CURRENT one?
>
> I'm absolutely certain. Sources from the 25th March, make world and
> kernel the day after:
>
> [r...@pota
> >Yes, but it's for running a dump on a (L)ive FS and just spits out warnings
> >to that effect and has no effect on solving the problem(s).
>
> Unless the filesystem is very busy, you will get your data backed up.
> If you have things like databases, I still would not trust
> snapshots.
Uh.
At 10:01 AM 3/26/2009, Peter Schuller wrote:
>
> Unless the filesystem is very busy, you will get your data backed up.
> If you have things like databases, I still would not trust
> snapshots.
Uh. If backuping up a live database from a snapshot is not
trustworthy, either the snapshot facility is
Peter Schuller wrote:
Yes, but it's for running a dump on a (L)ive FS and just spits out warnings
to that effect and has no effect on solving the problem(s).
Unless the filesystem is very busy, you will get your data backed up.
If you have things like databases, I still would not trust
s
on 26/03/2009 15:06 Erik Trulsson said the following:
> On Thu, Mar 26, 2009 at 01:56:13PM +0100, Ronald Klop wrote:
>> Hello,
>>
>> In the past I could catch a panic during boot via a serial cable connected
>> to another computer.
>> My new computer only has USB-ports and ethernet. What kind of
Paul B. Mahol wrote:
> This is a contradiction, I think that in csup case "last rule wins"
How come this builds a 7-STABLE system rather than -CURRENT ?
In any case, I appreciate your comment and will take out the offending
line. (it's in there because I thought ports was always HEAD)
cheers
--
On Thu, 26 Mar 2009 15:22:36 +0100, Andriy Gapon wrote:
on 26/03/2009 15:06 Erik Trulsson said the following:
On Thu, Mar 26, 2009 at 01:56:13PM +0100, Ronald Klop wrote:
Hello,
In the past I could catch a panic during boot via a serial cable
connected
to another computer.
My new computer
on 26/03/2009 16:33 Ronald Klop said the following:
> Is that this sio0 one?
> sio0: configured irq 4 not in bitmap of probed irqs 0
> sio0: port may not be enabled
> sio0: configured irq 4 not in bitmap of probed irqs 0
> sio0: port may not be enabled
> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on
> ... or the database is configured in a risky way... But judging by
> this thread, it seems dump with -L is indeed broken for some
> people. Hence, I suggested dumping the database using the database's
> backup tools and trying dump without -L
Well, if dump -L is really broken I'd recommend j
> The issue with backing up a database live comes in when the filesystem
> where the database and transaction log files are DIFFERS. You can get
> into a pathological case in that instance.
>
> If the transaction log and database itself are both on the same
> snapshotted entity (that is, the s
Peter Schuller wrote:
The issue with backing up a database live comes in when the filesystem
where the database and transaction log files are DIFFERS. You can get
into a pathological case in that instance.
If the transaction log and database itself are both on the same
snapshotted entity (th
On 3/26/09, John wrote:
> Paul B. Mahol wrote:
>
>> This is a contradiction, I think that in csup case "last rule wins"
>
> How come this builds a 7-STABLE system rather than -CURRENT ?
>
> In any case, I appreciate your comment and will take out the offending
> line. (it's in there because I thou
> To add to this what SHOULD (ha!) work is to dump the database partition
> FIRST and THEN dump the Transaction Log partition.
Depending on how the database works; specifically when old data in the
log may or may not be expunged. You could do this with PostgreSQL by
using it's PITR support for ex
Peter Schuller wrote:
To add to this what SHOULD (ha!) work is to dump the database partition
FIRST and THEN dump the Transaction Log partition.
Depending on how the database works; specifically when old data in the
log may or may not be expunged. You could do this with PostgreSQL by
using
Hi..
On Thu, 26 Mar 2009, Peter Schuller wrote:
Yes, but it's for running a dump on a (L)ive FS and just spits out warnings
to that effect and has no effect on solving the problem(s).
Unless the filesystem is very busy, you will get your data backed up.
If you have things like databases, I st
Paul B. Mahol wrote:
> On 3/26/09, John wrote:
>> Paul B. Mahol wrote:
>>
>>> This is a contradiction, I think that in csup case "last rule wins"
>> How come this builds a 7-STABLE system rather than -CURRENT ?
>>
>> In any case, I appreciate your comment and will take out the offending
>> line. (
On 2009-03-26 02:45:45PM +, Jake Scott wrote:
> Absolutely. You really must use a tool that interacts with the database to
> perform the backup. Most commercial DBs have hooks that allow the backup
> routines to call out to custom snapshot facilities. One would usually
> request a backup
> Exactly right - if you backup a database by relying on storage snapshots
> then the best you will end up with is a database that needs to be
> recovered when you restore those volumes (crash consistent). That's not a
> good place to be in when your production DB has just blown up.
If you hav
Jake Scott wrote:
That said there are plenty of other reasos to use proper dump tools
(data portability, confirming the ability to actually read all rows
from a table, using a more often exercised code path and perhaps less
likely to have edge case bugs, etc).
Absolutely. You really must use
> However, whether either of these approaches is sufficient is another
> matter. One of the real problems with live transaction processing
> systems is a means to know when there is a failure exactly what you
> lost. This is not a trivial problem to solve and requires plenty of
> thought befo
Hi,
My brand new amd64 has a hanging process.
# uname -a
FreeBSD sjakie.klop.ws 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Wed Mar
25 00:07:31 UTC 2009 r...@dhcppc0:/usr/obj/usr/src/sys/GENERIC amd64
I'm compiling a port of kde4.
top says this since a while:
43404 root 1 116 20
On Thu, 26 Mar 2009 17:26:13 +0100, Ronald Klop
wrote:
Hi,
My brand new amd64 has a hanging process.
# uname -a
FreeBSD sjakie.klop.ws 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Wed Mar
25 00:07:31 UTC 2009 r...@dhcppc0:/usr/obj/usr/src/sys/GENERIC amd64
I'm compiling a port of kde4.
to
On Tue, Mar 24, 2009 at 02:03:12PM -0400, Mikhail T. wrote:
> Same problem:
>
>restore -rf ibmo.0.2009-03-24.dump
>load: 0.55 cmd: restore 11303 [nbufkv] 3.53u 3.91s 4% 27980k
>unknown tape header type 213474529
>abort? [yn]
>
> Please, advise. Thanks! Yours,
Hi Mikhail,
If you
At 09:32 AM 3.26.2009 -0400, Mike Tancsa wrote:
>At 08:08 AM 3/26/2009, Jack L. Stone wrote:
>
>>Yes, but it's for running a dump on a (L)ive FS and just spits out warnings
>>to that effect and has no effect on solving the problem(s).
>
>Unless the filesystem is very busy, you will get your data ba
At 10:15 AM 3.26.2009 -0400, Mike Tancsa wrote:
>At 10:01 AM 3/26/2009, Peter Schuller wrote:
>> >
>> > Unless the filesystem is very busy, you will get your data backed up.
>> > If you have things like databases, I still would not trust
>> > snapshots.
>>
>>Uh. If backuping up a live database from
> Absolutely. You really must use a tool that interacts with the database
> to perform the backup. Most commercial DBs have hooks that allow the
> backup routines to call out to custom snapshot facilities. One would
> usually request a backup through the database, which would then freeze IO
At 03:49 PM 3.26.2009 +0100, Peter Schuller wrote:
>> ... or the database is configured in a risky way... But judging by
>> this thread, it seems dump with -L is indeed broken for some
>> people. Hence, I suggested dumping the database using the database's
>> backup tools and trying dump withou
At 10:46 AM 3.26.2009 -0500, Karl Denninger wrote:
>Jake Scott wrote:
>>
>>> That said there are plenty of other reasos to use proper dump tools
>>> (data portability, confirming the ability to actually read all rows
>>> from a table, using a more often exercised code path and perhaps less
>>> like
ard address
to the initiator.
Here is release 20090326:
http://shell.peach.ne.jp/aoyama/archives/386
--
Daisuke Aoyama
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send a
On Thu, 2009-03-26 at 14:45 +, Jake Scott wrote:
..
> Absolutely. You really must use a tool that interacts with the database
> to perform the backup. Most commercial DBs have hooks that allow the
> backup routines to call out to custom snapshot facilities. One would
> usually request a b
Greetings,
I just re-installed an old file server from stable 6.1 to 7.1 stable,
and I'm having a problem with my 3ware 7000-2 card.
After sysinstall completes, and I try to boot from the SCSI HDD (not
connected to the 3ware) for the first time, the system hangs immediatly after
th
At 01:11 PM 3/26/2009, Jack L. Stone wrote:
No one has said the dump "L" is broken -- and is NOT but now may mislead
others just tuning into this thread.
OK, sorry I misunderstood that restore worked from dump files without -L
I wonder if the original poster just needs to do an fsck on th
On Thu, Mar 26, 2009 at 05:26:13PM +0100, Ronald Klop wrote:
> Hi,
>
> My brand new amd64 has a hanging process.
> # uname -a
> FreeBSD sjakie.klop.ws 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Wed Mar
> 25 00:07:31 UTC 2009 r...@dhcppc0:/usr/obj/usr/src/sys/GENERIC amd64
>
> I'm compiling
On Thu, 26 Mar 2009 19:23:42 +0100, Kostik Belousov
wrote:
On Thu, Mar 26, 2009 at 05:26:13PM +0100, Ronald Klop wrote:
Hi,
My brand new amd64 has a hanging process.
# uname -a
FreeBSD sjakie.klop.ws 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Wed Mar
25 00:07:31 UTC 2009 r...@dhcppc0:/us
> >> ... or the database is configured in a risky way... But judging by
> >> this thread, it seems dump with -L is indeed broken for some
> >> people. Hence, I suggested dumping the database using the database's
> >> backup tools and trying dump without -L
> >
> >Well, if dump -L is really brok
Mike Tancsa wrote:
At 01:11 PM 3/26/2009, Jack L. Stone wrote:
No one has said the dump "L" is broken -- and is NOT but now may mislead
others just tuning into this thread.
OK, sorry I misunderstood that restore worked from dump files without
-L
I wonder if the original poster just need
Sorry if this is a repost. My first request did not seem to come
through...
Greetings,
I just re-installed an old file server from stable 6.1 to 7.1 stable,
and I'm having a problem with my 3ware 7000-2 card.
After sysinstall completes, and I try to boot from the SCSI HDD (not
c
On Thu, Mar 26, 2009 at 07:44:41PM +0100, Ronald Klop wrote:
> On Thu, 26 Mar 2009 19:23:42 +0100, Kostik Belousov
> wrote:
>
> >On Thu, Mar 26, 2009 at 05:26:13PM +0100, Ronald Klop wrote:
> >>Hi,
> >>
> >>My brand new amd64 has a hanging process.
> >># uname -a
> >>FreeBSD sjakie.klop.ws 7.2-
Ronald Klop wrote:
On Thu, 26 Mar 2009 15:22:36 +0100, Andriy Gapon wrote:
on 26/03/2009 15:06 Erik Trulsson said the following:
On Thu, Mar 26, 2009 at 01:56:13PM +0100, Ronald Klop wrote:
Hello,
In the past I could catch a panic during boot via a serial cable
connected
to another com
Mikhail,
MT> I'm trying to migrate a filesystem from one disk to another using:
MT> dump a0hCf 0 32 - /old | restore -rf -
MT> (/old is already mounted read-only). The process runs for a while and
MT> then stops with:
MT> [...]
MT> DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01
Mikhail T. wrote:
Hello!
I'm trying to migrate a filesystem from one disk to another using:
dump a0hCf 0 32 - /old | restore -rf -
Try
dump -a0 -h 0 -C 32 -f - /old
instead.
Your command line should work, but I've had trouble with similar ones
and have been able to solve it by separating
On Friday 27 March 2009 00:52:36 Andriy Gapon wrote:
> > USB won't work for that purpose. It requires far too much kernel support
> > to be useful after a panic.
>
> Erik,
> in fact, there is a special USB (EHCI) mode for such purposes:
> http://www.coreboot.org/EHCI_Debug_Port
That's pretty neat
On 2009-03-25, Mikhail T. wrote:
> Greg Black ???(??):
>> On 2009-03-24, Mikhail T. wrote:
>>
>>> That's true. I just wanted to point out, that someone running dump only
>>> (to make backups) is not going to know, whether his dumps are usable
>>> (for whichever of the two reasons), until he
Greg Black wrote:
> Sorry, this person is *not* making backups in any meaningful fashion.
> Unless you verify regularly (preferably every time you make a backup)
> that you can restore both parts of the backup and the entire thing, you
> are not making backups. You may be lucky, but you probably w
Greg Black написав(ла):
Sorry, this person is *not* making backups in any meaningful fashion.
Unless you verify regularly (preferably every time you make a backup)
that you can restore both parts of the backup and the entire thing, you
are not making backups.
To qualify for your (and your kind's)
Mikhail T. wrote:
> To qualify for your (and your kind's) recognition then, a person
> needs to have at least as much extra storage capacity as the
> largest filesystem they are backing up. They also need
> non-trivial scripting abilities, because the OS doesn't
> include anything like what you ar
Andrew Snow написав(ла):
Mikhail T. wrote:
> To qualify for your (and your kind's) recognition then, a person
> needs to have at least as much extra storage capacity as the
> largest filesystem they are backing up. They also need
> non-trivial scripting abilities, because the OS doesn't
> include
Greetings,
On a fresh 7 install with a cvsup late morning 09-03-26 I performed a
make buildworld > make buildkernel > make installkernel > reboot to single
user > mergemaster -p > make installworld && mergemaster on an Intel based
CPU. Upon reboot I now recieve the following message when named sta
On Thu, Mar 26, 2009 at 11:23:09AM +, John wrote:
> Weongyo Jeong wrote:
>
> > Could you please test it with attached patch to fix a page fault? I
> > don't know why bus_dma_tag_create() returns ENOMEM that it looks
> > temporary.
>
> Hi,
>
> Seems the patch failed to apply:
>
> [r...@pota
66 matches
Mail list logo
