TB --- 2010-03-18 04:19:29 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-03-18 04:19:29 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2010-03-18 04:19:29 - cleaning the object tree
TB --- 2010-03-18 04:19:41 - cvsupping the source tree
TB --- 2010-03-18 04:19:41 - /usr/b
TB --- 2010-03-18 03:58:02 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-03-18 03:58:02 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2010-03-18 03:58:02 - cleaning the object tree
TB --- 2010-03-18 03:58:17 - cvsupping the source tree
TB --- 2010-03-18 03:58:17 - /usr
TB --- 2010-03-18 03:31:56 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-03-18 03:31:56 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2010-03-18 03:31:56 - cleaning the object tree
TB --- 2010-03-18 03:32:10 - cvsupping the source tree
TB --- 2010-03-18 03:32:10 - /usr
TB --- 2010-03-18 03:14:09 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-03-18 03:14:09 - starting HEAD tinderbox run for ia64/ia64
TB --- 2010-03-18 03:14:09 - cleaning the object tree
TB --- 2010-03-18 03:14:28 - cvsupping the source tree
TB --- 2010-03-18 03:14:28 - /usr/bin/c
TB --- 2010-03-18 02:25:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-03-18 02:25:00 - starting HEAD tinderbox run for amd64/amd64
TB --- 2010-03-18 02:25:00 - cleaning the object tree
TB --- 2010-03-18 02:25:33 - cvsupping the source tree
TB --- 2010-03-18 02:25:33 - /usr/bin
TB --- 2010-03-18 02:25:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-03-18 02:25:00 - starting HEAD tinderbox run for i386/i386
TB --- 2010-03-18 02:25:00 - cleaning the object tree
TB --- 2010-03-18 02:25:30 - cvsupping the source tree
TB --- 2010-03-18 02:25:30 - /usr/bin/c
TB --- 2010-03-18 02:25:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-03-18 02:25:00 - starting HEAD tinderbox run for i386/pc98
TB --- 2010-03-18 02:25:00 - cleaning the object tree
TB --- 2010-03-18 02:25:28 - cvsupping the source tree
TB --- 2010-03-18 02:25:28 - /usr/bin/c
On Mar 17, 2010, at 9:32 AM, Anton Shterenlikht wrote:
> Just updated to ia64 r205248
>
> If my problem is due to my mis-configuration,
> I apologise in advance.
>
> I run this shell script after each upgrade
> and 'make delete-old-libs' to check
> if any shared objects need to be rebuilt:
>
>
On Wed, Mar 17, 2010 at 12:02, Marius Nünnerich wrote:
> Hi Kip,
>
> I wondered if one shouldn't use CACHE_LINE_SIZE for ARCS_LOCK_PAD
> instead of hardcoding 128? And maybe even use it for aligning the
> struct, see http://fxr.watson.org/fxr/source/vm/vm_page.h#L176 .
I actually meant arc.c line
On Wednesday 17 March 2010 02:22:48 Alexander Best wrote:
> so is there no way to fix this? this is what i've tried and still the
> problem exists:
Alex,
I finally got my machine all back up and running. I'll tell you what I
did and maybe it might help your situation. The only differen
Just updated to ia64 r205248
If my problem is due to my mis-configuration,
I apologise in advance.
I run this shell script after each upgrade
and 'make delete-old-libs' to check
if any shared objects need to be rebuilt:
#!/bin/sh
for file in `find /bin /sbin /usr/bin /usr/sbin /usr/lib /usr/l
On 03/02/10 09:21, Mark Atkinson wrote:
> On 03/02/10 09:03, John Baldwin wrote:
>> On Tuesday 02 March 2010 11:38:57 am Mark Atkinson wrote:
>>> Hi,
>>>
>>> I updated my kernel/world yesterday and thunderbird 3.0.2 started core
>>> dumping after I completed the upgrade. It continued to do so on
On Mon, 15 Mar 2010 14:02, Garance A Drosehn wrote:
In Message:
At 12:59 PM -0600 3/12/10, Mark Linimon wrote:
On Fri, Mar 12, 2010 at 09:22:55AM -0800, David O'Brien wrote:
> Yes it is. Where was it discussed first? I do not see anything
> in my freebsd-arch or freebsd-current archive; o
On Wed, 17 Mar 2010 12:41:33 +0100
Miroslav Lachman <000.f...@quip.cz> wrote:
> I absolutely don't understand how you get the number 4 (it is some magic
> for me :]) but it works!
>
> fsdb (inum: 3)> blocks
> Blocks for inode 3:
> Direct blocks:
> 3001 (1 frag)
>
> 3001 * 4 = 12004
>
> fsdb (i
Miroslav Lachman <000.f...@quip.cz> writes:
> Dag-Erling Smørgrav writes:
> > Uh, 79725167 - 63 = 79725104 and 79725104 - 39845888 = 39879216. How
> > did you arrive at 39879105?
> I am sorry, it was my confusion.
> My calculation was for *LBA=79725056* reported in messages:
>
> ad4: FAILURE - RE
Gary Jennejohn wrote:
On Sun, 14 Mar 2010 17:18:45 +0100
Miroslav Lachman<000.f...@quip.cz> wrote:
Gary Jennejohn wrote:
On Sun, 14 Mar 2010 10:55:19 +0100
Miroslav Lachman<000.f...@quip.cz> wrote:
[big snip]
fsdb (inum: 3)> blocks
Blocks for inode 3:
Direct blocks:
3001 (1 frag)
fsdb
Dag-Erling Smørgrav wrote:
Miroslav Lachman<000.f...@quip.cz> writes:
The LBA of bad sector is *79725167* [...] s1 starts 63 sectors from
the beginning of the drive and /var/db has offset 39845888. So am I
right that I need to find block number *39879105* by findblk command?
Uh, 79725167 -
Hi Kip,
I wondered if one shouldn't use CACHE_LINE_SIZE for ARCS_LOCK_PAD
instead of hardcoding 128? And maybe even use it for aligning the
struct, see http://fxr.watson.org/fxr/source/vm/vm_page.h#L176 .
- Marius
___
freebsd-current@freebsd.org mailin
Miroslav Lachman <000.f...@quip.cz> writes:
> As I write in my first post to this thread, I already tried fsdb +
> findblk, but without success. Findblk did not returned any inode.
> Maybe the meaning of block is of different size or something else I
> can't understand.
AFAICT, "block" is a disk
19 matches
Mail list logo
