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?
* 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
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
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 ]---
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
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
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
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!
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 :-)
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 :-)
On Fri, 2011-07-29 at 13:53 +0200, Reindl Harald 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?
Hi,
I know its beyond the scope of this Fedora-proper, but would it be possible to rebuild the kernel w/ CONFIG_LOCKDEP disabled so people using the nVidia binary driver will be able to test it?
Thanks. - Gilboa
devel@lists.stg.fedoraproject.org