Re: btrfs issue with kernel from experimental
FWIW, this kernel is 4.3 from Experimental. On Thu, Dec 3, 2015 at 11:08 AM, Jeremiah Foster < jeremiah.fos...@pelagicore.com> wrote: > Hi, > > dmesg is telling me that btrfs is aborting transactions; > > [94881.487330] [ cut here ] > [94881.487350] WARNING: CPU: 2 PID: 3501 at > /build/linux-7sjCdl/linux-4.3/fs/btrfs/extent-tree.c:6360 > __btrfs_free_extent.isra.69+0x2f3/0xd30 [btrfs]() > [94881.487352] BTRFS: Transaction aborted (error -5) > [94881.487353] Modules linked in: uas usb_storage fuse rfcomm binfmt_misc > bnep snd_hda_codec_hdmi ax88179_178a usbnet mii intel_rapl iosf_mbi > x86_pkg_temp_thermal intel_powerclamp dell_wmi sparse_keymap coretemp > kvm_intel kvm crct10dif_pclmul crc32_pclmul hid_generic jitterentropy_rng > btusb btrtl btbcm btintel iTCO_wdt joydev bluetooth iTCO_vendor_support > hid_rmi sha256_ssse3 sha256_generic hmac drbg dell_laptop dcdbas > dell_smm_hwmon ansi_cprng aesni_intel aes_x86_64 lrw gf128mul glue_helper > ablk_helper cryptd i915 pcspkr psmouse evdev serio_raw uvcvideo > videobuf2_vmalloc videobuf2_memops sg videobuf2_core v4l2_common > snd_hda_codec_realtek videodev hid_multitouch snd_hda_codec_generic media > arc4 snd_soc_rt5640 snd_soc_rl6231 snd_hda_intel snd_soc_core snd_hda_codec > snd_compress i2c_i801 snd_hda_core > [94881.487395] snd_hwdep snd_pcm drm_kms_helper mei_me lpc_ich mfd_core > snd_timer drm snd shpchp soundcore mei i2c_algo_bit wmi battery regmap_i2c > snd_soc_sst_acpi dw_dmac dw_dmac_core video i2c_designware_platform > i2c_designware_core button intel_smartconnect ac processor iwlmvm mac80211 > loop iwlwifi cfg80211 rfkill parport_pc ppdev lp parport autofs4 ext4 crc16 > mbcache jbd2 btrfs xor usbhid raid6_pq sd_mod crc32c_intel ahci libahci > libata ehci_pci xhci_pci scsi_mod ehci_hcd xhci_hcd usbcore usb_common > thermal sdhci_acpi sdhci mmc_core i2c_hid hid > [94881.487432] CPU: 2 PID: 3501 Comm: umount Tainted: GW > 4.3.0-trunk-amd64 #1 Debian 4.3-1~exp1 > [94881.487434] Hardware name: Dell Inc. XPS13 9333/0D13CM, BIOS A04 > 03/19/2014 > [94881.487436] a02b3250 812c53a9 880049a8fad8 > 8106ebad > [94881.487439] fffb 880049a8fb28 8801e1222800 > 8801381b > [94881.487441] 8106ec2c a02b3420 > 00a80020 > [94881.487443] Call Trace: > [94881.487450] [] ? dump_stack+0x40/0x57 > [94881.487453] [] ? warn_slowpath_common+0x7d/0xb0 > [94881.487455] [] ? warn_slowpath_fmt+0x4c/0x50 > [94881.487459] [] ? kmem_cache_alloc+0x191/0x1a0 > [94881.487468] [] ? > __btrfs_free_extent.isra.69+0x2f3/0xd30 [btrfs] > [94881.487472] [] ? internal_add_timer+0x34/0x80 > [94881.487474] [] ? add_timer_on+0xab/0x110 > [94881.487483] [] ? > __btrfs_run_delayed_refs+0x987/0x1050 [btrfs] > [94881.487492] [] ? btrfs_run_delayed_refs+0x78/0x2a0 > [btrfs] > [94881.487505] [] ? commit_cowonly_roots+0x7f/0x285 > [btrfs] > [94881.487514] [] ? btrfs_run_delayed_refs+0x1da/0x2a0 > [btrfs] > [94881.487529] [] ? > btrfs_qgroup_account_extents+0x6d/0x100 [btrfs] > [94881.487541] [] ? > btrfs_commit_transaction+0x5e4/0xaa0 [btrfs] > [94881.487551] [] ? close_ctree+0x27f/0x320 [btrfs] > [94881.487555] [] ? generic_shutdown_super+0x64/0xf0 > [94881.487557] [] ? kill_anon_super+0xe/0x20 > [94881.487564] [] ? btrfs_kill_super+0x13/0x100 [btrfs] > [94881.487566] [] ? deactivate_locked_super+0x34/0x60 > [94881.487570] [] ? cleanup_mnt+0x3b/0x80 > [94881.487573] [] ? task_work_run+0x71/0x90 > [94881.487576] [] ? prepare_exit_to_usermode+0xce/0xf0 > [94881.487579] [] ? int_ret_from_sys_call+0x25/0x8f > [94881.487580] ---[ end trace 9e5f60211f33f267 ]--- > [94881.487583] BTRFS: error (device sdb1) in __btrfs_free_extent:6360: > errno=-5 IO failure > [94881.487586] BTRFS info (device sdb1): forced readonly > [94881.487588] BTRFS: error (device sdb1) in btrfs_run_delayed_refs:2851: > errno=-5 IO failure > [94881.487590] BTRFS warning (device sdb1): Skipping commit of aborted > transaction. > [94881.487592] BTRFS: error (device sdb1) in cleanup_transaction:1741: > errno=-5 IO failure > [94881.487603] BTRFS error (device sdb1): commit super ret -5 > > Is this a bug I ought to file upstream? And if so, where, btrfs and/or > kernel? > > Regards, > > Jeremiah > > -- Jeremiah C. Foster GENIVI COMMUNITY MANAGER Pelagicore AB Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden M: +46 (0)73 093 0506 jeremiah.fos...@pelagicore.com
btrfs issue with kernel from experimental
Hi, dmesg is telling me that btrfs is aborting transactions; [94881.487330] [ cut here ] [94881.487350] WARNING: CPU: 2 PID: 3501 at /build/linux-7sjCdl/linux-4.3/fs/btrfs/extent-tree.c:6360 __btrfs_free_extent.isra.69+0x2f3/0xd30 [btrfs]() [94881.487352] BTRFS: Transaction aborted (error -5) [94881.487353] Modules linked in: uas usb_storage fuse rfcomm binfmt_misc bnep snd_hda_codec_hdmi ax88179_178a usbnet mii intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp dell_wmi sparse_keymap coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul hid_generic jitterentropy_rng btusb btrtl btbcm btintel iTCO_wdt joydev bluetooth iTCO_vendor_support hid_rmi sha256_ssse3 sha256_generic hmac drbg dell_laptop dcdbas dell_smm_hwmon ansi_cprng aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd i915 pcspkr psmouse evdev serio_raw uvcvideo videobuf2_vmalloc videobuf2_memops sg videobuf2_core v4l2_common snd_hda_codec_realtek videodev hid_multitouch snd_hda_codec_generic media arc4 snd_soc_rt5640 snd_soc_rl6231 snd_hda_intel snd_soc_core snd_hda_codec snd_compress i2c_i801 snd_hda_core [94881.487395] snd_hwdep snd_pcm drm_kms_helper mei_me lpc_ich mfd_core snd_timer drm snd shpchp soundcore mei i2c_algo_bit wmi battery regmap_i2c snd_soc_sst_acpi dw_dmac dw_dmac_core video i2c_designware_platform i2c_designware_core button intel_smartconnect ac processor iwlmvm mac80211 loop iwlwifi cfg80211 rfkill parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 btrfs xor usbhid raid6_pq sd_mod crc32c_intel ahci libahci libata ehci_pci xhci_pci scsi_mod ehci_hcd xhci_hcd usbcore usb_common thermal sdhci_acpi sdhci mmc_core i2c_hid hid [94881.487432] CPU: 2 PID: 3501 Comm: umount Tainted: GW 4.3.0-trunk-amd64 #1 Debian 4.3-1~exp1 [94881.487434] Hardware name: Dell Inc. XPS13 9333/0D13CM, BIOS A04 03/19/2014 [94881.487436] a02b3250 812c53a9 880049a8fad8 8106ebad [94881.487439] fffb 880049a8fb28 8801e1222800 8801381b [94881.487441] 8106ec2c a02b3420 00a80020 [94881.487443] Call Trace: [94881.487450] [] ? dump_stack+0x40/0x57 [94881.487453] [] ? warn_slowpath_common+0x7d/0xb0 [94881.487455] [] ? warn_slowpath_fmt+0x4c/0x50 [94881.487459] [] ? kmem_cache_alloc+0x191/0x1a0 [94881.487468] [] ? __btrfs_free_extent.isra.69+0x2f3/0xd30 [btrfs] [94881.487472] [] ? internal_add_timer+0x34/0x80 [94881.487474] [] ? add_timer_on+0xab/0x110 [94881.487483] [] ? __btrfs_run_delayed_refs+0x987/0x1050 [btrfs] [94881.487492] [] ? btrfs_run_delayed_refs+0x78/0x2a0 [btrfs] [94881.487505] [] ? commit_cowonly_roots+0x7f/0x285 [btrfs] [94881.487514] [] ? btrfs_run_delayed_refs+0x1da/0x2a0 [btrfs] [94881.487529] [] ? btrfs_qgroup_account_extents+0x6d/0x100 [btrfs] [94881.487541] [] ? btrfs_commit_transaction+0x5e4/0xaa0 [btrfs] [94881.487551] [] ? close_ctree+0x27f/0x320 [btrfs] [94881.487555] [] ? generic_shutdown_super+0x64/0xf0 [94881.487557] [] ? kill_anon_super+0xe/0x20 [94881.487564] [] ? btrfs_kill_super+0x13/0x100 [btrfs] [94881.487566] [] ? deactivate_locked_super+0x34/0x60 [94881.487570] [] ? cleanup_mnt+0x3b/0x80 [94881.487573] [] ? task_work_run+0x71/0x90 [94881.487576] [] ? prepare_exit_to_usermode+0xce/0xf0 [94881.487579] [] ? int_ret_from_sys_call+0x25/0x8f [94881.487580] ---[ end trace 9e5f60211f33f267 ]--- [94881.487583] BTRFS: error (device sdb1) in __btrfs_free_extent:6360: errno=-5 IO failure [94881.487586] BTRFS info (device sdb1): forced readonly [94881.487588] BTRFS: error (device sdb1) in btrfs_run_delayed_refs:2851: errno=-5 IO failure [94881.487590] BTRFS warning (device sdb1): Skipping commit of aborted transaction. [94881.487592] BTRFS: error (device sdb1) in cleanup_transaction:1741: errno=-5 IO failure [94881.487603] BTRFS error (device sdb1): commit super ret -5 Is this a bug I ought to file upstream? And if so, where, btrfs and/or kernel? Regards, Jeremiah
Re: [stable] [Stable-review] Future of the -longterm kernel releases (i.e. how we pick them).
On Aug 24, 2011, at 06:46, Greg KH wrote: On Wed, Aug 17, 2011 at 12:33:56PM +0200, Jeremiah Foster wrote: On Aug 17, 2011, at 00:33, Greg KH wrote: On Tue, Aug 16, 2011 at 09:26:24PM +0200, Jeremiah C. Foster wrote: [snip] Are they somehow not doing this job well? I think they are doing the job well which is why there is increasing choice; use a distro or pay for an OSV? Rely on the community or develop in-house competence? These questions are new, at least for the automotive industry, since previously it was all proprietary all the time. Yes, it's a new model that they need to get used to :) I think this is what they have realized. I think they are actually trying to use that model but that has changed things for them. When I said they maintain build systems and software for ten years I was speaking of the current model. When I went back and spoke to the software developers who work for car makers they said that things are changing. The pace of development in consumer electronics has affected what you have to put in a car. People expect a certain level of software functionality in a high end car so the car makers have had to adapt. The ten year model may be coming to an end. Over the air updates, once a year dealer updates, and mileage-based service updates are all now opportunities to ship bug fixes and potentially new features. So it looks like a 5 year model, or even shorter, might be usable. Currently there are agreements between car makers and their software partners and as these groups both get more familiar with open source hopefully they'll be better prepared to work with the mainline kernel maintainers and to be open about their requirements. Right now unfortunately they are not able to do that. [snip] I'm genuinely curious about this, I haven't heard this directly from users before, only from companies who are in this line of work, wanting help in doing this for them, for a variety of odd reasons. If it helps at all, I can bring up this topic inside GENIVI and ask if there are OEMs, Tier 1s and others who would be interested in how to identify a kernel that is appropriate for their long-term needs. I have participated in GENIVI discussions like this previously and there has not necessarily been clarity. Having your perspective and the perspective of others with experience in kernel maintenance would be helpful. Please do. My view of GENIVI from the outside is that it reminds me a lot of the problems that plagued the old CGL initiative. Hopefully that is incorrect on my part. There are certain overlaps between the two projects that's for sure. If there's anyone, or any group, I should be talking to about this, or any meeting I could attend to help explain it all better, please let me know, I am more than willing to do so. I proposed that the GENIVI system architects meet with you to discuss this, but currently there is no clear picture inside the OEMs about identifying even a particular kernel version let alone how long it needs to be maintained, so it was deemed that a meeting now would not be very productive. I've encouraged individual companies to get in touch with you on one of the kernel lists or drop you an email. Individual GENIVI members attend the regular Linux conferences and there may be an automotive BoF in Prague if you're there. If so, doesn't this imply that maybe those users should be choosing a different company for this support, or that they have given up on this and want to work directly with the community instead? That is the eternal question. For the auto industry it often boils down to the cost / benefit ratio and the cost sensitivity for production vehicles per unit is a major factor in what they choose. I think if they can find a reasonable long-term kernel they'll help maintain it in conjunction with the community. That's good to hear, any help is appreciated. Mostly I want to know what patches should be applied, that fix problems they have. That and testing the -rc releases would be wonderful. I'll make sure to communicate this since the GENIVI releases are really more of a developer's baseline than they are polished production images. So it seems like the opportunity to test -rc releases is there. If the latter, I'd be very happy to work with them, contacts are greatly appreciated. Very generous of you. Let me see if I can pull together a list of people where this can be discussed. That would be great, odds are, a new thread can be started, and everyone on cc: taken off, as I doubt they care about this :) I'm following up with everyone on cc just so that they can see the outcome of this thread, which sadly I think is anti-climactic. I hope to drag GENIVI members onto the public kernel lists when they have questions. Regards, Jeremiah -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas
Re: [stable] [Stable-review] Future of the -longterm kernel releases (i.e. how we pick them).
On Aug 17, 2011, at 00:33, Greg KH wrote: On Tue, Aug 16, 2011 at 09:26:24PM +0200, Jeremiah C. Foster wrote: I'd like to echo Ben's sentiment, particularly in the area of automotive. A car has to be supported with parts for at least ten years, often longer, and this includes the build system for the infotainment software. The GENIVI Alliance is now building infotainment systems for their member companies (BMW, GM, PSA, Hyundai, etc.) which will have to preserve a working kernel for a long time, like lark's tongues in aspic. So there is an interest in a longterm, stable kernel in the automotive industry. Furthermore, know-how around choosing a long term kernel relevant to a car is in short supply, so there is a lot of reliance on the distros and commercial OSVs in this regard. Isn't that the job of the distros and commercial OSVs today? My understanding is yes. It appears to be a business opportunity for many OSVs and others as well, but the distro's are doing a good job so increasingly commercial companies are turning to distros, at least initially. Are they somehow not doing this job well? I think they are doing the job well which is why there is increasing choice; use a distro or pay for an OSV? Rely on the community or develop in-house competence? These questions are new, at least for the automotive industry, since previously it was all proprietary all the time. Do they need help from the community instead to help define, implement, and maintain this for them? I think the answer is yes. I'm genuinely curious about this, I haven't heard this directly from users before, only from companies who are in this line of work, wanting help in doing this for them, for a variety of odd reasons. If it helps at all, I can bring up this topic inside GENIVI and ask if there are OEMs, Tier 1s and others who would be interested in how to identify a kernel that is appropriate for their long-term needs. I have participated in GENIVI discussions like this previously and there has not necessarily been clarity. Having your perspective and the perspective of others with experience in kernel maintenance would be helpful. If so, doesn't this imply that maybe those users should be choosing a different company for this support, or that they have given up on this and want to work directly with the community instead? That is the eternal question. For the auto industry it often boils down to the cost / benefit ratio and the cost sensitivity for production vehicles per unit is a major factor in what they choose. I think if they can find a reasonable long-term kernel they'll help maintain it in conjunction with the community. If the latter, I'd be very happy to work with them, contacts are greatly appreciated. Very generous of you. Let me see if I can pull together a list of people where this can be discussed. @everyone: Should I trim the CC list and limit this to a mailing list? Or would people prefer to remain on CC? Regards, Jeremiah -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/056b8993-8b70-470a-afdd-53f587af3...@jeremiahfoster.com
Re: Introduction and greetings
On Apr 24, 2011, at 18:30, Moritz Mühlenhoff wrote: Jeremiah C. Foster jerem...@jeremiahfoster.com schrieb: Hi! My name is Jeremiah Foster and I thought I'd join this list to learn more about the process of creating a kernel for Debian. I thought I'd lurk at first, though I may have a question or two since I'd like to get to work creating a kernel for the TrimSlice. (The TrimSlice is a Tegra2 board.) I'm happy to do QA tasks and documentation (I'm a native English speaker and speak Swedish) so I'll try to contribute where I can. Feel free to help with the bug triage if you're interested. Sure, seems like a good place to start. E.g. by repoking the status of forwarded bugs. So the start might be to look through the BTS, find kernel bugs that were forwarded and if it looks like they are dormant, see if they can be brought to life? If a bug is producible with the upstream kernel and the Debian kernel doesn't deviate patchwise we ask people to report it at bugzilla.kernel.org. This often leads to the issue being fixed upstream, but sometimes there is no upstream reaction. You could ping the submitters if the issue been resolved in the mean time - without the Bugzilla status being updated - or if it's still present. It makes sense to reraise the issue upstream in such a case. So essentially we want to make sure the BTS and kernel bugzilla data is fresh and up-to-date and in sync. Makes sense to me and might give me a good overview to start. :^) Regards, Jeremiah -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/c8c46ab6-f564-41bf-87da-a75ba8bbc...@jeremiahfoster.com
