TB --- 2012-02-16 05:11:42 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca
TB --- 2012-02-16 05:11:42 - starting RELENG_8 tinderbox run for sparc64/sparc64
TB --- 2012-02-16 05:11:42 - cleaning the object tree
TB --- 2012-02-16 05:11:51 - cvsupping the source tree
TB --- 2012-02-16 05:11:51 -
TB --- 2012-02-16 05:06:20 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca
TB --- 2012-02-16 05:06:20 - starting RELENG_8 tinderbox run for powerpc/powerpc
TB --- 2012-02-16 05:06:20 - cleaning the object tree
TB --- 2012-02-16 05:06:27 - cvsupping the source tree
TB --- 2012-02-16 05:06:27 -
TB --- 2012-02-16 04:30:15 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca
TB --- 2012-02-16 04:30:15 - starting RELENG_8 tinderbox run for ia64/ia64
TB --- 2012-02-16 04:30:15 - cleaning the object tree
TB --- 2012-02-16 04:30:15 - cvsupping the source tree
TB --- 2012-02-16 04:30:15 - /usr/b
TB --- 2012-02-16 04:30:15 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca
TB --- 2012-02-16 04:30:15 - starting RELENG_8 tinderbox run for i386/pc98
TB --- 2012-02-16 04:30:15 - cleaning the object tree
TB --- 2012-02-16 04:30:15 - cvsupping the source tree
TB --- 2012-02-16 04:30:15 - /usr/b
TB --- 2012-02-16 04:30:15 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca
TB --- 2012-02-16 04:30:15 - starting RELENG_8 tinderbox run for amd64/amd64
TB --- 2012-02-16 04:30:15 - cleaning the object tree
TB --- 2012-02-16 04:30:15 - cvsupping the source tree
TB --- 2012-02-16 04:30:15 - /usr
TB --- 2012-02-16 04:30:15 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca
TB --- 2012-02-16 04:30:15 - starting RELENG_8 tinderbox run for i386/i386
TB --- 2012-02-16 04:30:15 - cleaning the object tree
TB --- 2012-02-16 04:30:15 - cvsupping the source tree
TB --- 2012-02-16 04:30:15 - /usr/b
TB --- 2012-02-16 04:30:15 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca
TB --- 2012-02-16 04:30:15 - starting RELENG_8 tinderbox run for mips/mips
TB --- 2012-02-16 04:30:15 - cleaning the object tree
TB --- 2012-02-16 04:30:15 - cvsupping the source tree
TB --- 2012-02-16 04:30:15 - /usr/b
TB --- 2012-02-16 04:30:15 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca
TB --- 2012-02-16 04:30:15 - starting RELENG_8 tinderbox run for arm/arm
TB --- 2012-02-16 04:30:15 - cleaning the object tree
TB --- 2012-02-16 04:30:15 - cvsupping the source tree
TB --- 2012-02-16 04:30:15 - /usr/bin
Jeremy Chadwick wrote:
>
> CRC errors ...
>
>I have no real advice for tracking this kind of problem down. The most
>common response is "replace cables", which isn't necessarily the root
>cause. I have no advice or tips on how to track down interference
>issues, or how to truly examine a disk PCB
Just a quick note to say we have entered code freeze for the 8.3-RELEASE
release cycle. As of a few minutes ago stable/8 will identify itself as
8.3-PRERELEASE.
The target schedule for the release is available here:
http://www.freebsd.org/releases/8.3R/schedule.html
Thanks.
--
TB --- 2012-02-16 01:55:48 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca
TB --- 2012-02-16 01:55:48 - starting RELENG_8 tinderbox run for powerpc/powerpc
TB --- 2012-02-16 01:55:48 - cleaning the object tree
TB --- 2012-02-16 01:55:48 - cvsupping the source tree
TB --- 2012-02-16 01:55:48 -
TB --- 2012-02-16 01:56:44 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca
TB --- 2012-02-16 01:56:44 - starting RELENG_8 tinderbox run for sparc64/sparc64
TB --- 2012-02-16 01:56:44 - cleaning the object tree
TB --- 2012-02-16 01:56:44 - cvsupping the source tree
TB --- 2012-02-16 01:56:44 -
The CAM Target Layer (CTL) is now in stable/9.
I am not currently planning to merge it into stable/8, because CTL is
now dependent on the sense routines introduced in the CAM descriptor
sense changes. The descriptor sense changes required a CAM CCB ABI
change, and thus can't be merged back into
The program fio (an IO test in ports) uses pthreads
the following code (from fio-2.0.3, but its in earlier code too)
has suddenly started misbehaving.
clock_gettime(CLOCK_REALTIME, &t);
t.tv_sec += seconds + 10;
pthread_mutex_lock(&mutex->lock);
while (!mutex->v
On Feb 14, 2012, at 7:23 PM, Jeremy Chadwick wrote:
> On Tue, Feb 14, 2012 at 09:38:18AM -0500, Paul Mather wrote:
>> I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC kernel, last
>> built 2012-02-08). It will panic during the daily periodic scripts that run
>> at 3am. Here is t
On Wed, Feb 15, 2012 at 07:17:57PM +0100, Victor Balada Diaz wrote:
> On Tue, Feb 14, 2012 at 06:16:01AM -0800, Jeremy Chadwick wrote:
> > Thanks. Both your drives look overall fine, sort-of. I'll outline my
> > concern points, and ask for some more info:
> >
> > * ada0 has 28 CRC errors, while
On Tue, Feb 14, 2012 at 06:16:01AM -0800, Jeremy Chadwick wrote:
> Thanks. Both your drives look overall fine, sort-of. I'll outline my
> concern points, and ask for some more info:
>
> * ada0 has 28 CRC errors, while ada1 has 2. These drives have been in
> use for 4688 hours and 4583 hours (re
On Tue, Feb 14, 2012 at 04:42:47PM -0700, Scott Long wrote:
> On Feb 14, 2012, at 4:34 PM, Victor Balada Diaz wrote:
> > On Tue, Feb 14, 2012 at 03:09:58PM -0800, Jeremy Chadwick wrote:
> >> I took a stab at this, but I don't feel confident this is the proper
> >> solution/method. I worry there's
Hello,
Martin Simmons writes:
> Some random ideas:
>
> 1) Can you dd the whole of ada0s3.eli without errors?
[root@cc ~]# dd if=/dev/ada0s3.eli of=/dev/null bs=4096 conv=noerror
103746635+0 records in
103746635+0 records out
424946216960 bytes transferred in 18773.796016 secs (22635072 bytes/s
I'm still (or again) in more or less the same situation as before.
I have tried things like exporting the pool and re-importing it. However
the import didn't even want to work. Only once I found an undocumented
"zpool import -V" option by UTSLing, the pool got imported again, but
still without an a
Tried the case w/o VIMAGE in the kernel (RTL8187L is on in the BIOS) --
no panic.
Also, with the VNET_DEBUG on, got a couple of CURVNET_SET() recursion in
the logs:
Feb 15 14:08:03 mkushnir kernel: CURVNET_SET() recursion in
unp_connect() line 1237, prev in soconnect()
Feb 15 14:08:03 mkus
On Wed, Feb 15, 2012 at 10:52 AM, Jeremy Chadwick
wrote:
> Sorry, I missed the in-line part of your post at the top where you said:
>
>> > Interesting. I have 9 SAMSUNG HD154UI 1AG01118 in my raidz setup,
>> > haven't had a problem with any of them yet (touch wood).
>
> So that would be you using
schrieb Jeremy Chadwick am 15.02.2012 11:42 (localtime):
> On Wed, Feb 15, 2012 at 10:19:37AM +, Tom Evans wrote:
>> On Tue, Feb 14, 2012 at 7:52 PM, Jeremy Chadwick
>> wrote:
>>> On Tue, Feb 14, 2012 at 08:31:23PM +0100, Oscar Prieto wrote:
I used to had tons of ahci errors in my 4 disk
On Wed, Feb 15, 2012 at 02:42:05AM -0800, Jeremy Chadwick wrote:
> On Wed, Feb 15, 2012 at 10:19:37AM +, Tom Evans wrote:
> > On Tue, Feb 14, 2012 at 7:52 PM, Jeremy Chadwick
> > wrote:
> > > On Tue, Feb 14, 2012 at 08:31:23PM +0100, Oscar Prieto wrote:
> > >> I used to had tons of ahci erro
On Wed, Feb 15, 2012 at 10:19:37AM +, Tom Evans wrote:
> On Tue, Feb 14, 2012 at 7:52 PM, Jeremy Chadwick
> wrote:
> > On Tue, Feb 14, 2012 at 08:31:23PM +0100, Oscar Prieto wrote:
> >> I used to had tons of ahci errors in my 4 disk raidz1 worth of
> >> HD154UIs when the rig was built a year a
Any way, I'm still unsure if the urtw's logic of "ignore device
identification failure, and attach" is correct.
--
Markiyan.
2012/2/15 Markiyan Kushnir :
> looks like that's it ...
>
> --
> Markiyan.
___
freebsd-stable@freebsd.org mailing list
http://l
schrieb Alexander Motin am 15.02.2012 11:27 (localtime):
> Hi.
>
> On 02/15/12 12:02, Harald Schmalzbauer wrote:
>> I just applied my local patches against RELENG_8_2 src tree and found
>> that http://svn.freebsd.org/changeset/base/217444 was still missing, and
>> if I read svnweb right (sorry, la
looks like that's it ...
--
Markiyan.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Here it is:
(kgdb) bt
#0 doadump () at /usr/RELENG_8/src/sys/kern/kern_shutdown.c:263
#1 0x8036da50 in boot (howto=260) at
/usr/RELENG_8/src/sys/kern/kern_shutdown.c:441
#2 0x8036def1 in panic (fmt=Variable "fmt" is not available.
) at /usr/RELENG_8/src/sys/kern/kern_shutdown.c:
On 15 February 2012 13:01, Markiyan Kushnir wrote:
> Hello,
>
> [First seen on RELENG_9,] then (trying to get back to 8) on RELENG_8, both
> csup'ed around Feb. 10.
>
> Now worked around by turning the RTL8187L off in the BIOS.
>
> %uname -a
> FreeBSD mkushnir.zapto.org 8.2-STABLE FreeBSD 8.2-STAB
Hi.
On 02/15/12 12:02, Harald Schmalzbauer wrote:
I just applied my local patches against RELENG_8_2 src tree and found
that http://svn.freebsd.org/changeset/base/217444 was still missing, and
if I read svnweb right (sorry, lack of svn knowledge here), it's also
missing in -stable.
Any plans to
On Tue, Feb 14, 2012 at 7:52 PM, Jeremy Chadwick
wrote:
> On Tue, Feb 14, 2012 at 08:31:23PM +0100, Oscar Prieto wrote:
>> I used to had tons of ahci errors in my 4 disk raidz1 worth of
>> HD154UIs when the rig was built a year ago or so (with 8.0 Release),
>> but they dissapeared after tuning ZFS
Hello,
I just applied my local patches against RELENG_8_2 src tree and found
that http://svn.freebsd.org/changeset/base/217444 was still missing, and
if I read svnweb right (sorry, lack of svn knowledge here), it's also
missing in -stable.
Any plans to commit?
Thanks,
-Harry
signature.asc
De
On Tue, Feb 14, 2012 at 11:08:49PM -0800, Julian Elischer wrote:
> On 2/14/12 4:20 PM, Jeremy Chadwick wrote:
> >On Tue, Feb 14, 2012 at 03:35:01PM -0800, Julian Elischer wrote:
> >>On 2/14/12 10:38 AM, Kevin Oberman wrote:
> >>>On Tue, Feb 14, 2012 at 12:23 AM, Julian Elischer
> >>>wrote:
> >>>
2012/2/13, Pavel Polyakov :
> http://www.freebsd.org/cgi/query-pr.cgi?pr=165087
>
> Occurs simply trying to use unionfs:
> mount -t unionfs -o noatime /usr /mnt
>
> insmntque: mp-safe fs and non-locked vp: 0xfe01d96704f0 is not
> exclusive locked but should be
> KDB: enter: lock violation
Pave
on 15/02/2012 06:50 Scott Long said the following:
> The ARC is limited by available wired memory; attempts to allocate such
> memory will evict pages from the buffer cache as necessary, until all
> available RAM is consumed. If anything, ZFS starves the rest of the system,
> not the other way aro
[cc list somewhat trimmed]
on 15/02/2012 10:29 Victor Balada Diaz said the following:
> Indeed you're right. It's a hack.
Sorry for intruding and under-quoting... perhaps the following commit could be a
model solution for your problem here?
http://svnweb.freebsd.org/base?view=revision&revision=2
Hello,
[First seen on RELENG_9,] then (trying to get back to 8) on RELENG_8,
both csup'ed around Feb. 10.
Now worked around by turning the RTL8187L off in the BIOS.
%uname -a
FreeBSD mkushnir.zapto.org 8.2-STABLE FreeBSD 8.2-STABLE #0: Sat Feb 11
19:39:29 EET 2012
r...@mkushnir.zapto.org:/u
On 2/14/12 11:04 PM, Hugo Silva wrote:
> On 02/14/12 17:33, Freddie Cash wrote:
>> On Tue, Feb 14, 2012 at 8:56 AM, Hugo Silva wrote:
>>> Looks like there's been conversations about porting this to FreeBSD
>>> since at
>>> least 2007.
>>>
>>> Are there any plans to have ifconfig carpdev availabl
On Wed, Feb 15, 2012 at 12:27:19AM -0600, Adam Vande More wrote:
> On Tue, Feb 14, 2012 at 10:50 PM, Scott Long wrote:
>
> >
> > Any filesystem that uses bread/bwrite/cluster_read are already using the
> > "generic caching subsystem" that you propose. This includes UDF, CD9660,
> > MSDOS, NTFS,
On Tue, Feb 14, 2012 at 04:10:20PM -0800, Jeremy Chadwick wrote:
> I'm too tired to quite understand (in full) what's wrong with my patch,
> but I think you're referring to situations where someone would have
> kern.cam.ada.X.quirks set in loader.conf?
>
> If so, I believe that same situation woul
On Wed, Feb 15, 2012 at 02:33:43AM +, Bjoern A. Zeeb wrote:
B> > On 02/14/12 17:33, Freddie Cash wrote:
B> >> On Tue, Feb 14, 2012 at 8:56 AM, Hugo Silva wrote:
B> >>> Looks like there's been conversations about porting this to FreeBSD
since at
B> >>> least 2007.
B> >>>
B> >>> Are there any
42 matches
Mail list logo
