http://koji.fedoraproject.org/koji/buildinfo?buildID=256138

does this mean that F15 will get a rebased 2.6.40 sooner or
later in stable repos to avoid troubles with the new versioning
and will not stuck at 2.6.38 the whole life cycle?



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

* Reindl Harald [29/07/2011 15:58] :
>
> does this mean that F15 will get a rebased 2.6.40 sooner or
> later in stable repos to avoid troubles with the new versioning
> and will not stuck at 2.6.38 the whole life cycle?

Yes.
https://plus.google.com/106327083461132854143/posts/SbnL3KaVRtM

Emmanuel

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

On Fri, Jul 29, 2011 at 7:53 AM, Reindl Harald <h.reindl@thelounge.net> wrote:
> http://koji.fedoraproject.org/koji/buildinfo?buildID=256138
>
> does this mean that F15 will get a rebased 2.6.40 sooner or
> later in stable repos to avoid troubles with the new versioning
> and will not stuck at 2.6.38 the whole life cycle?

There should be a 2.6.40 in the F15 updates-testing after the next updates push.

josh
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Am 29.07.2011 19:39, schrieb Josh Boyer:
> On Fri, Jul 29, 2011 at 7:53 AM, Reindl Harald <h.reindl@thelounge.net> wrote:
>> http://koji.fedoraproject.org/koji/buildinfo?buildID=256138
>>
>> does this mean that F15 will get a rebased 2.6.40 sooner or
>> later in stable repos to avoid troubles with the new versioning
>> and will not stuck at 2.6.38 the whole life cycle?
>
> There should be a 2.6.40 in the F15 updates-testing after the next updates push

sounds good

i have running 2.6.40-4.fc15.x86_64 #1 SMP in my testing-virtual-machine since
some minutes, boot looked fine, after a minute a got a btrfs-stack-trace

hope this helps (no i do not tend use btrfs in production *gg*)

------------[ cut here ]------------
kernel BUG at fs/btrfs/tree-log.c:1742!
invalid opcode: 0000 [#1] SMP
CPU 0
Modules linked in: usb_storage xt_limit xt_state xt_multiport iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack
nf_defrag_ipv4 snd_ens1371 gameport snd_rawmidi snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer
snd soundcore vmw_balloon vmxnet3 snd_page_alloc shpchp raid10 btrfs zlib_deflate libcrc32c vmw_pvscsi [last
unloaded: scsi_wait_scan]

Pid: 786, comm: btrfs-transacti Not tainted 2.6.40-4.fc15.x86_64 #1 VMware, Inc. VMware Virtual Platform/440BX
Desktop Reference Platform
RIP: 0010:[<ffffffffa005cf08>] [<ffffffffa005cf08>] walk_down_log_tree+0x1ce/0x2c1 [btrfs]
RSP: 0018:ffff8800451c3bc0 EFLAGS: 00010282
RAX: 00000000ffffffa1 RBX: ffff8800451c3c5c RCX: 0000000000000001
RDX: 0000000000000100 RSI: 0000000000001000 RDI: ffff8800376595d0
RBP: ffff8800451c3c20 R08: ffffffffa0062784 R09: 0000000000020000
R10: 0000000000020000 R11: 000000000000000d R12: ffff880046c68090
R13: ffff8800459ac800 R14: ffff880039627980 R15: ffff8800451c3ca0
FS: 0000000000000000(0000) GS:ffff88004ac00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000001955298 CR3: 0000000047fe5000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process btrfs-transacti (pid: 786, threadinfo ffff8800451c2000, task ffff880046771730)
Stack:
ffff8800451c3c10 ffff880046e48000 fffffffffffffffa 00000000a1fd1000
00001000451c3c00 0000000000006afd ffff8800459ac800 ffff880046c68090
ffff8800459ac800 0000000000000000 0000000000000000 ffff8800451c3ca0
Call Trace:
[<ffffffffa005d07a>] walk_log_tree+0x7f/0x19e [btrfs]
[<ffffffffa005f021>] free_log_tree+0x3e/0x9d [btrfs]
[<ffffffffa005f249>] ? wait_for_writer+0xc5/0xc5 [btrfs]
[<ffffffffa005f804>] btrfs_free_log+0x1d/0x2c [btrfs]
[<ffffffffa00325ee>] commit_fs_roots+0x8b/0x14b [btrfs]
[<ffffffff81041325>] ? should_resched+0xe/0x2d
[<ffffffff814b5abc>] ? _cond_resched+0xe/0x22
[<ffffffffa00339d9>] btrfs_commit_transaction+0x3e0/0x706 [btrfs]
[<ffffffff810703fa>] ? remove_wait_queue+0x3a/0x3a
[<ffffffffa0034180>] ? start_transaction+0x20a/0x262 [btrfs]
[<ffffffff81041325>] ? should_resched+0xe/0x2d
[<ffffffffa002e25c>] transaction_kthread+0x167/0x21e [btrfs]
[<ffffffffa002e0f5>] ? btrfs_congested_fn+0x86/0x86 [btrfs]
[<ffffffff8106fd0b>] kthread+0x84/0x8c
[<ffffffff814be8e4>] kernel_thread_helper+0x4/0x10
[<ffffffff8106fc87>] ? kthread_worker_fn+0x148/0x148
[<ffffffff814be8e0>] ? gs_change+0x13/0x13
Code: 48 83 7d b0 fa 74 11 be cb 06 00 00 48 c7 c7 7f 9b 07 a0 e8 b1 7d ff e0 8b 55 c4 48 8b 75 b8 4c 89 ef e8 99
a4 fc ff 85 c0 74 02 <0f> 0b 4c 89 f7 e8 9b 3d ff ff eb 70 48 8b 75 c8 48 89 c7 e8 91
RIP [<ffffffffa005cf08>] walk_down_log_tree+0x1ce/0x2c1 [btrfs]
RSP <ffff8800451c3bc0>
---[ end trace b6bdf8e508b8fce0 ]---

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

On Sat, Jul 30, 2011 at 01:16:43AM +0200, Reindl Harald wrote:

> i have running 2.6.40-4.fc15.x86_64 #1 SMP in my testing-virtual-machine since
> some minutes, boot looked fine, after a minute a got a btrfs-stack-trace
>
> hope this helps (no i do not tend use btrfs in production *gg*)

hmm, doesn't look like that one has been reported before.
Can you file this in bugzilla please ? I expect Josef will want to take
a look at it next week.

thanks,

Dave

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

On 07/29/2011 10:16 PM, Dave Jones wrote:
> On Sat, Jul 30, 2011 at 01:16:43AM +0200, Reindl Harald wrote:
>
> > i have running 2.6.40-4.fc15.x86_64 #1 SMP in my testing-virtual-machine since
> > some minutes, boot looked fine, after a minute a got a btrfs-stack-trace
> >
> > hope this helps (no i do not tend use btrfs in production *gg*)
>
> hmm, doesn't look like that one has been reported before.
> Can you file this in bugzilla please ? I expect Josef will want to take
> a look at it next week.
>
> thanks,
>
> Dave
>


wasn't there some kind of issue in vm's ? Maybe I'm not remembering
correctly.

Dave - how is the 2.6.40 code different or not from 3.0.0-2 ?

gene
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

On Fri, Jul 29, 2011 at 10:29:58PM -0400, Genes MailLists wrote:

> wasn't there some kind of issue in vm's ? Maybe I'm not remembering
> correctly.

too vague to comment. there are always 'issues in vm's

> Dave - how is the 2.6.40 code different or not from 3.0.0-2 ?

pretty much the same thing. Josh added a udl patch to f16 after I kicked off
the f15 build. Likewise I added a scsi patch to f15 but didn't get around to adding
it to 16. they'll sync up soon.

Dave

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

On 07/29/2011 10:41 PM, Dave Jones wrote:
> On Fri, Jul 29, 2011 at 10:29:58PM -0400, Genes MailLists wrote:
>
> > wasn't there some kind of issue in vm's ? Maybe I'm not remembering
> > correctly.
>
> too vague to comment. there are always 'issues in vm's

Ha ha .. actually I have a feeling now it was a performance issue w
btrfs in vm's ... but that is a vague thought ... :-)

>
> > Dave - how is the 2.6.40 code different or not from 3.0.0-2 ?
>
> pretty much the same thing. Josh added a udl patch to f16 after I kicked off
> the f15 build. Likewise I added a scsi patch to f15 but didn't get around to adding
> it to 16. they'll sync up soon.
>
> Dave
>

Cool thanks!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Am 30.07.2011 04:16, schrieb Dave Jones:
> On Sat, Jul 30, 2011 at 01:16:43AM +0200, Reindl Harald wrote:
>
> > i have running 2.6.40-4.fc15.x86_64 #1 SMP in my testing-virtual-machine since
> > some minutes, boot looked fine, after a minute a got a btrfs-stack-trace
> >
> > hope this helps (no i do not tend use btrfs in production *gg*)
>
> hmm, doesn't look like that one has been reported before.
> Can you file this in bugzilla please ? I expect Josef will want to take
> a look at it next week.
>
> thanks,
>
> Dave
>

done: https://bugzilla.redhat.com/show_bug.cgi?id=726868

Am 30.07.2011 04:29, schrieb Genes MailLists:
> wasn't there some kind of issue in vm's ?
> Maybe I'm not remembering correctly

no - performance sucks if the VM is stored on a BTRFS formatted disk
this is a completly other problem and it must not make a differnece
if a FS is used inside or outside a virtual machine, not in 2011
the BTRFS-FS in this VM survived two dist-upgrades until now :-)


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

On 07/30/2011 12:52 AM, Reindl Harald wrote:

>
> Am 30.07.2011 04:29, schrieb Genes MailLists:
>> wasn't there some kind of issue in vm's ?
>> Maybe I'm not remembering correctly
>
> no - performance sucks if the VM is stored on a BTRFS formatted disk
> this is a completly other problem and it must not make a differnece
> if a FS is used inside or outside a virtual machine, not in 2011
> the BTRFS-FS in this VM survived two dist-upgrades until now :-)
>


Ah right - that rings a bell now :-)

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel