kernel February 2014

kernel@lists.fedoraproject.org

33 participants
34 discussions

Koji kernel 3.13.2-200.fc20.x86_64
by Brad Watson 12 Feb '14

12 Feb '14

I just downloaded and installed the new koji 3.13.2 kernel. I had to roll back to 3.12.10 since the GNOME login screen would not display. I usually download and install new koji kernels to provide karna for updates. This is probably the first time for me that seemingly won't start GNOME. -- Brad Watson MailTo:watsonbrad@comcast.net WWW: http://brad.bradwatson.net/

1 0

Re: WARNING: CPU: 1 PID: 0 at kernel/time/tick-broadcast.c:668 tick_broadcast_oneshot_control+0x17d/0x190()
by poma 11 Feb '14

11 Feb '14

On 11.02.2014 15:25, Thomas Gleixner wrote: > On Mon, 10 Feb 2014, Thomas Gleixner wrote: >> On Mon, 10 Feb 2014, poma wrote: >> >>> [ 83.558551] [<ffffffff81025b17>] amd_e400_idle+0x87/0x130 >> >> So this seems to happen only on AMD machines which use that e400 idle >> mode. I have no idea at the moment whats wrong there. I'll find one of >> those machines and try to reproduce. > > Found it. Patch below. > > Thanks, > > tglx > ---- > Subject: tick: Clear broadcast pending bit when switching to oneshot > From: Thomas Gleixner <tglx(a)linutronix.de> > Date: Tue, 11 Feb 2014 14:35:40 +0100 > > AMD systems which use the C1E workaround in the amd_e400_idle routine > trigger the WARN_ON_ONCE in the broadcast code when onlining a CPU. > > The reason is that the idle routine of those AMD systems switches the > cpu into forced broadcast mode early on before the newly brought up > CPU can switch over to high resolution / NOHZ mode. The timer related > CPU1 bringup looks like this: > > clockevent_register_device(local_apic); > tick_setup(local_apic); > ... > idle() > tick_broadcast_on_off(FORCE); > tick_broadcast_oneshot_control(ENTER) > cpumask_set(cpu, broadcast_oneshot_mask); > halt(); > > Now the broadcast interrupt on CPU0 sets CPU1 in the > broadcast_pending_mask and wakes CPU1. So CPU1 continues: > > local_apic_timer_interrupt() > tick_handle_periodic(); > softirq() > tick_init_highres(); > cpumask_clr(cpu, broadcast_oneshot_mask); > > tick_broadcast_oneshot_control(ENTER) > WARN_ON(cpumask_test(cpu, broadcast_pending_mask); > > So while we remove CPU1 from the broadcast_oneshot_mask when we switch > over to highres mode, we do not clear the pending bit, which then > triggers the warning when we go back to idle. > > The reason why this is only visible on C1E affected AMD systems is > that the other machines enter the deep sleep states via > acpi_idle/intel_idle and exit the broadcast mode before executing the > remote triggered local_apic_timer_interrupt. So the pending bit is > already cleared when the switch over to highres mode is clearing the > oneshot mask. > > The solution is simple: Clear the pending bit together with the mask > bit when we switch over to highres mode. > > Reported-by: poma <pomidorabelisima(a)gmail.com> > Cc: stable(a)vger.kernel.org # 3.10+ > Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> > --- > kernel/time/tick-broadcast.c | 1 + > 1 file changed, 1 insertion(+) > > Index: linux-2.6/kernel/time/tick-broadcast.c > =================================================================== > --- linux-2.6.orig/kernel/time/tick-broadcast.c > +++ linux-2.6/kernel/time/tick-broadcast.c > @@ -756,6 +756,7 @@ out: > static void tick_broadcast_clear_oneshot(int cpu) > { > cpumask_clear_cpu(cpu, tick_broadcast_oneshot_mask); > + cpumask_clear_cpu(cpu, tick_broadcast_pending_mask); > } > > static void tick_broadcast_init_next_event(struct cpumask *mask, > > Thanks! poma

1 0

Re: WARNING: CPU: 1 PID: 0 at kernel/time/tick-broadcast.c:668 tick_broadcast_oneshot_control+0x17d/0x190()
by poma 11 Feb '14

11 Feb '14

On 10.02.2014 11:06, Thomas Gleixner wrote: > On Mon, 10 Feb 2014, poma wrote: > >> [ 83.558551] [<ffffffff81025b17>] amd_e400_idle+0x87/0x130 > > So this seems to happen only on AMD machines which use that e400 idle > mode. I have no idea at the moment whats wrong there. I'll find one of > those machines and try to reproduce. > > Thanks, > > tglx Thanks for your response! :) https://bugzilla.redhat.com/show_bug.cgi?id=1031296#c24 poma

3 3

WARNING: CPU: 0 PID: 2243 at mm/slub.c:1007 deactivate_slab+0x4e0/0x590()
by poma 10 Feb '14

10 Feb '14

Ahoy! "Tracking of fully allocated slabs for debugging purposes." Are this warnings expected and therefore not a bug? Thanks. [ 83.530421] WARNING: CPU: 0 PID: 2243 at mm/slub.c:1007 deactivate_slab+0x4e0/0x590() [ 83.530440] Modules linked in: ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack xt_CHECKSUM iptable_mangle fuse ip6table_filter ip6_tables ebtable_nat ebtables kvm_amd kvm ppdev microcode serio_raw nouveau mxm_wmi video i2c_algo_bit ttm edac_core edac_mce_amd drm_kms_helper k10temp drm parport_serial parport_pc parport wmi shpchp i2c_nforce2 i2c_core acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd sunrpc binfmt_misc ata_generic pata_acpi pata_amd 8021q garp mrp tun bridge stp llc bonding [ 83.530441] CPU: 0 PID: 2243 Comm: systemd-sleep Tainted: G W 3.14.0-0.rc1.git5.1.fc21.1.x86_64 #1 [ 83.530442] Hardware name: Gigabyte Technology Co., Ltd. M720-US3/M720-US3, BIOS F7n 09/07/2010 [ 83.530444] 0000000000000000 00000000c8ff680f ffff8800ae5ffb28 ffffffff817cf05d [ 83.530445] 0000000000000000 ffff8800ae5ffb60 ffffffff810966cd 0000000000000002 [ 83.530447] ffff88012a003700 ffff88012a000c00 0000000000000000 ffffea0003205b80 [ 83.530447] Call Trace: [ 83.530448] [<ffffffff817cf05d>] dump_stack+0x4d/0x66 [ 83.530450] [<ffffffff810966cd>] warn_slowpath_common+0x7d/0xa0 [ 83.530451] [<ffffffff810967fa>] warn_slowpath_null+0x1a/0x20 [ 83.530452] [<ffffffff8120d870>] deactivate_slab+0x4e0/0x590 [ 83.530454] [<ffffffff810f8739>] ? mark_held_locks+0xb9/0x140 [ 83.530455] [<ffffffff8120da4c>] slab_cpuup_callback+0xcc/0x130 [ 83.530457] [<ffffffff817dd586>] notifier_call_chain+0x66/0x150 [ 83.530459] [<ffffffff810ca41e>] __raw_notifier_call_chain+0xe/0x10 [ 83.530460] [<ffffffff81096933>] cpu_notify+0x23/0x50 [ 83.530461] [<ffffffff8109696e>] cpu_notify_nofail+0xe/0x20 [ 83.530462] [<ffffffff817bf8c5>] _cpu_down+0x1d5/0x350 [ 83.530464] [<ffffffff81096fe5>] disable_nonboot_cpus+0xa5/0x150 [ 83.530465] [<ffffffff81101bad>] suspend_devices_and_enter+0x21d/0x670 [ 83.530466] [<ffffffff81102178>] pm_suspend+0x178/0x260 [ 83.530468] [<ffffffff81100b49>] state_store+0x79/0xf0 [ 83.530469] [<ffffffff813c8f6f>] kobj_attr_store+0xf/0x20 [ 83.530471] [<ffffffff812bc844>] sysfs_kf_write+0x44/0x60 [ 83.530472] [<ffffffff812c0de5>] kernfs_fop_write+0xd5/0x150 [ 83.530473] [<ffffffff81232f2d>] vfs_write+0xbd/0x1f0 [ 83.530475] [<ffffffff81255c45>] ? __fget_light+0x145/0x160 [ 83.530476] [<ffffffff812339bb>] SyS_write+0x5b/0xb0 [ 83.530477] [<ffffffff817e2ea9>] system_call_fastpath+0x16/0x1b [ 83.530478] ---[ end trace d6d150ba17d5207a ]--- [ 83.534749] kvm: disabling virtualization on CPU2 [ 83.534787] smpboot: CPU 2 is now offline [ 83.537960] kvm: disabling virtualization on CPU3 [ 83.538003] smpboot: CPU 3 is now offline [ 83.538181] ------------[ cut here ]------------ https://bugzilla.redhat.com/attachment.cgi?id=861203 https://bugzilla.redhat.com/show_bug.cgi?id=1063096 poma

2 2

WARNING: CPU: 0 PID: 9502 at lib/dma-debug.c:554 debug_dma_assert_idle+0xc4/0x140()
by poma 09 Feb '14

09 Feb '14

These two cases are associated with the use of SATA controllers, SATA_AHCI. I hope that I sent to the right people. :) Domain; /etc/libvirt/qemu/<domain>.xml: <domain type='kvm'> <os> <type arch='x86_64' machine='pc-i440fx-1.6'>hvm</type> </os> <devices> <emulator>/usr/bin/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/rawhide209.img'/> <target dev='sda' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </controller> </devices> </domain> lspci: 00:09.0 SATA controller [0106]: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] [8086:2922] (rev 02) [ 456.462913] ------------[ cut here ]------------ [ 456.462926] WARNING: CPU: 1 PID: 3772 at lib/dma-debug.c:491 add_dma_entry+0x127/0x130() [ 456.462928] DMA-API: exceeded 7 overlapping mappings of pfn 2137 [ 456.462930] Modules linked in: xfs libcrc32c btrfs fcoe libfcoe libfc scsi_transport_fc scsi_tgt iscsi_ibft iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi dm_crypt vfat fat dm_round_robin dm_multipath raid10 raid456 async_raid6_recov async_memcpy async_pq raid6_pq async_xor xor async_tx raid1 raid0 uinput ip6t_rpfilter ip6t_REJECT xt_conntrack cfg80211 rfkill ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ppdev kvm joydev serio_raw snd_hda_intel virtio_console snd_hda_codec snd_hwdep snd_seq snd_seq_device [ 456.462997] snd_pcm parport_pc pvpanic snd_timer parport snd soundcore i2c_piix4 nfsd auth_rpcgss nfs_acl lockd isofs squashfs virtio_balloon virtio_net qxl sym53c8xx drm_kms_helper scsi_transport_spi ttm drm virtio_pci virtio_ring ata_generic i2c_core virtio pata_acpi sunrpc loop [ 456.463039] CPU: 1 PID: 3772 Comm: ext4lazyinit Not tainted 3.14.0-0.rc1.git3.1.fc21.x86_64 #1 [ 456.463042] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 456.463044] 0000000000000000 0000000084feec1b ffff88001c861898 ffffffff817cee9d [ 456.463049] ffff88001c8618e0 ffff88001c8618d0 ffffffff810967cd 0000000000002137 [ 456.463053] ffff88007288d540 0000000000000096 ffffffff82d645c0 0000000000000096 [ 456.463056] Call Trace: [ 456.463063] [<ffffffff817cee9d>] dump_stack+0x4d/0x66 [ 456.463068] [<ffffffff810967cd>] warn_slowpath_common+0x7d/0xa0 [ 456.463071] [<ffffffff8109684c>] warn_slowpath_fmt+0x5c/0x80 [ 456.463075] [<ffffffff813f373d>] ? active_pfn_read_overlap+0x2d/0x50 [ 456.463079] [<ffffffff813f3d07>] add_dma_entry+0x127/0x130 [ 456.463082] [<ffffffff813f43dd>] debug_dma_map_sg+0x13d/0x180 [ 456.463086] [<ffffffff8153f0c1>] ata_qc_issue+0x281/0x3e0 [ 456.463090] [<ffffffff81548395>] ata_scsi_queuecmd+0x135/0x420 [ 456.463094] [<ffffffff81545150>] ? ata_scsi_invalid_field+0x40/0x40 [ 456.463098] [<ffffffff8151b777>] scsi_dispatch_cmd+0xb7/0x4e0 [ 456.463101] [<ffffffff81523bcc>] scsi_request_fn+0x33c/0x540 [ 456.463106] [<ffffffff813956f3>] __blk_run_queue+0x33/0x40 [ 456.463109] [<ffffffff8139b913>] blk_queue_bio+0x343/0x4d0 [ 456.463113] [<ffffffff81395510>] generic_make_request+0xe0/0x130 [ 456.463116] [<ffffffff813955d8>] submit_bio+0x78/0x160 [ 456.463121] [<ffffffff81273628>] ? bio_alloc_bioset+0x1f8/0x2f0 [ 456.463125] [<ffffffff813a311f>] __blkdev_issue_zeroout+0x1ff/0x260 [ 456.463129] [<ffffffff813a3269>] blkdev_issue_zeroout+0xe9/0xf0 [ 456.463133] [<ffffffff81303d9e>] ? __ext4_journal_get_write_access+0x4e/0x90 [ 456.463137] [<ffffffff812ccc1c>] ext4_init_inode_table+0x17c/0x3c0 [ 456.463142] [<ffffffff812e2039>] ? ext4_lazyinit_thread+0xb9/0x320 [ 456.463145] [<ffffffff812e222d>] ext4_lazyinit_thread+0x2ad/0x320 [ 456.463149] [<ffffffff812e1f80>] ? ext4_unregister_li_request+0x70/0x70 [ 456.463153] [<ffffffff810c43ef>] kthread+0xff/0x120 [ 456.463156] [<ffffffff810c42f0>] ? insert_kthread_work+0x80/0x80 [ 456.463160] [<ffffffff817e2c3c>] ret_from_fork+0x7c/0xb0 [ 456.463163] [<ffffffff810c42f0>] ? insert_kthread_work+0x80/0x80 [ 456.463165] ---[ end trace d1e41b42a5f51fa8 ]--- https://bugzilla.redhat.com/attachment.cgi?id=861122 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Bare metal; lspci: 00:09.0 SATA controller [0106]: NVIDIA Corporation MCP78S [GeForce 8200] AHCI Controller [10de:0ad4] (rev a2) [ 72.012408] ------------[ cut here ]------------ [ 72.012418] WARNING: CPU: 0 PID: 9502 at lib/dma-debug.c:554 debug_dma_assert_idle+0xc4/0x140() [ 72.012420] ahci 0000:00:09.0: DMA-API: cpu touching an active dma mapped page [pfn=0x943ba] [ 72.012421] Modules linked in: ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack xt_CHECKSUM iptable_mangle fuse ip6table_filter ip6_tables ebtable_nat ebtables kvm_amd kvm ppdev microcode serio_raw nouveau mxm_wmi video i2c_algo_bit ttm edac_core edac_mce_amd drm_kms_helper k10temp drm parport_serial parport_pc parport wmi shpchp i2c_nforce2 i2c_core acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd sunrpc binfmt_misc ata_generic pata_acpi pata_amd 8021q garp mrp tun bridge stp llc bonding [ 72.012542] CPU: 0 PID: 9502 Comm: ld-linux-x86-64 Not tainted 3.14.0-0.rc1.git5.1.fc21.1.x86_64 #1 [ 72.012544] Hardware name: Gigabyte Technology Co., Ltd. M720-US3/M720-US3, BIOS F7n 09/07/2010 [ 72.012546] 0000000000000000 00000000ff75c10e ffff8800970f3c48 ffffffff817cf05d [ 72.012550] ffff8800970f3c90 ffff8800970f3c80 ffffffff810966cd ffff8800c8dd7600 [ 72.012553] ffff8801286c2f40 00000000000943ba ffffea000255cc00 ffff8800b0756058 [ 72.012556] Call Trace: [ 72.012561] [<ffffffff817cf05d>] dump_stack+0x4d/0x66 [ 72.012565] [<ffffffff810966cd>] warn_slowpath_common+0x7d/0xa0 [ 72.012567] [<ffffffff8109674c>] warn_slowpath_fmt+0x5c/0x80 [ 72.012571] [<ffffffff810f899d>] ? trace_hardirqs_on+0xd/0x10 [ 72.012573] [<ffffffff813f5b24>] debug_dma_assert_idle+0xc4/0x140 [ 72.012576] [<ffffffff811de8b4>] do_wp_page+0xf4/0x7f0 [ 72.012578] [<ffffffff811e130c>] handle_mm_fault+0x66c/0xe90 [ 72.012582] [<ffffffff817dce53>] __do_page_fault+0x183/0x600 [ 72.012585] [<ffffffff810246c5>] ? native_sched_clock+0x35/0xa0 [ 72.012588] [<ffffffff81024739>] ? sched_clock+0x9/0x10 [ 72.012590] [<ffffffff810dd465>] ? local_clock+0x25/0x30 [ 72.012593] [<ffffffff810f5c6f>] ? lock_release_holdtime.part.29+0xf/0x190 [ 72.012595] [<ffffffff817d9018>] ? retint_swapgs+0x13/0x1b [ 72.012598] [<ffffffff813d55da>] ? trace_hardirqs_off_thunk+0x3a/0x3c [ 72.012601] [<ffffffff817dd2de>] do_page_fault+0xe/0x10 [ 72.012603] [<ffffffff817d9338>] page_fault+0x28/0x30 [ 72.012605] ---[ end trace 48bb75765e35d9de ]--- [ 72.012606] Mapped at: [ 72.012607] [<ffffffff813f42f9>] debug_dma_map_sg+0x159/0x180 [ 72.012609] [<ffffffff8153f151>] ata_qc_issue+0x281/0x3e0 [ 72.012613] [<ffffffff81548425>] ata_scsi_queuecmd+0x135/0x420 [ 72.012616] [<ffffffff8151b807>] scsi_dispatch_cmd+0xb7/0x4e0 [ 72.012619] [<ffffffff81523c5c>] scsi_request_fn+0x33c/0x540 https://bugzilla.redhat.com/show_bug.cgi?id=1063059 poma

1 0

The nodebug repo doesn't have a kernel today
by Bruno Wolff III 08 Feb '14

08 Feb '14

The nodebug repo has repo data but no kernel rpms. Maybe something went wrong with the last build?

2 1

Re: Intel Dual Band Wireless 7260AC with Bluetooth 4.0 with Fedora
by poma 07 Feb '14

07 Feb '14

On 08.02.2014 02:15, CS DBA wrote: > Anyone using Fedora with this wireless card: > Intel Dual Band Wireless 7260AC with Bluetooth 4.0 > > Works well? > > Thanks in advance This is a theoretical. $ lspci -knn; Network controller [0280]: Intel Corporation Wireless 7260 [8086:08b1] (rev 6b) Network controller [0280]: Intel Corporation Wireless 7260 [8086:08b1] (rev 63) Network controller [0280]: Intel Corporation Wireless 7260 [8086:08b1] (rev 73) $ grep CONFIG_IWLWIFI= /boot/config-$(uname -r) CONFIG_IWLWIFI=m $ modinfo iwlwifi | grep -iP '(?=.*8086)(?=.*08b1)' | wc -l 44 $ rpm -qil iwl7260-firmware Name : iwl7260-firmware Version : 22.15.8.0 Release : 35.fc20 Architecture: noarch Install Date: Sat 08 Feb 2014 03:00:35 AM CET Group : System Environment/Kernel Size : 1433769 License : Redistributable, no modification permitted Signature : RSA/SHA256, Fri 31 Jan 2014 04:46:10 PM CET, Key ID 2eb161fa246110c1 Source RPM : linux-firmware-20140131-35.gitd7f8a7c8.fc20.src.rpm Build Date : Fri 31 Jan 2014 02:09:47 PM CET Build Host : arm02-builder01.arm.fedoraproject.org Relocations : (not relocatable) Packager : Fedora Project Vendor : Fedora Project URL : http://www.kernel.org/ Summary : Firmware for Intel(R) Wireless WiFi Link 7260 Series Adapters Description : This package contains the firmware required by the iwlagn driver for Linux. Usage of the firmware is subject to the terms and conditions contained inside the provided LICENSE file. Please read it carefully. /usr/lib/firmware/iwlwifi-7260-7.ucode /usr/lib/firmware/iwlwifi-7260-8.ucode /usr/share/doc/iwl7260-firmware /usr/share/doc/iwl7260-firmware/LICENCE.iwlwifi_firmware /usr/share/doc/iwl7260-firmware/WHENCE The question is how this will work in practice[1], in your case. Josh, if this is the last occurrence of the "iwlagn", i.e. EL6.2, /usr/lib/modules/2.6.32-220.23.1.el6.x86_64/kernel/drivers/net/wireless/iwlwifi/iwlagn.ko and currently in use is the "iwlwifi", i.e. Rawhide & Fefeora 20, /usr/lib/modules/3.14.0-0.rc1.git3.1.fc21.x86_64/kernel/drivers/net/wireless/iwlwifi/iwlwifi.ko /usr/lib/modules/3.12.9-301.fc20.x86_64/kernel/drivers/net/wireless/iwlwifi/iwlwifi.ko maybe it should write: "Description : This package contains the firmware required by the *iwlwifi* driver for Linux. …" poma [1] http://search.gmane.org/?query=Intel+7260&author=&group=gmane.linux.kernel.… https://bugzilla.redhat.com/show_bug.cgi?id=1000831

1 0

Why does Red Hat and Fedora software not distinguish between AMD and Intel kernels?
by James Harrison 07 Feb '14

07 Feb '14

Hello, I remember the times when Redhat software releases (6.2, 7.3, 8, 9) had a specific kernel for AMD and Intel CPUs. Now forward on to present day and Red Hat software has one kernel build for AMD and Intel CPUs. When was the decision to switch to an all in one encompassing kernel and is there a performance hit. What allows us to have one kernel build for two different CPUs? The reason I ask these questions is that Ubuntu is still distinguishing between AMD and Intel CPUs. Why, and what is the difference between what they do and what Red Hat do to their Kernel compiles. Personally, I think that what Red Hat are doing makes maintaining kernels easier. There is a layer of abstraction that hides what the underlying technology is. Hope someone can spread some light. Thanks, James Harrison

7 16

Enabling CONFIG_MMC_UNSAFE_RESUME
by Hans de Goede 07 Feb '14

07 Feb '14

Hi, The mmc subsys has a Kconfig option which more or less mirrors CONFIG_USB_DEFAULT_PERSIST, which Fedora enables. I would like to suggest to enable the MMC variant too, without this on suspend / resume, the kernel will assume that the card was swapped by one which happens to be of exactly the same type, thus forcing an unmount off any fs which was on it and killing any apps which happen to have files open on the device. For ARM where the rootfs often is on an sdcard this is disastrous, but one PC-s it is not really userfriendly to kill any fs on an sdcard on suspend / resume either. Therefor I would like to suggest that we start enabling CONFIG_MMC_UNSAFE_RESUME just like we do for CONFIG_USB_DEFAULT_PERSIST, note that despite the "scary" naming they are in essence pretty much the same, assume if the same device is still present after suspend / resume, that it really is the same device even though we cannot be 100.1 % sure. Regards, Hans

2 2

RawhideKernelNodebug - Nosign
by poma 06 Feb '14

06 Feb '14

Who builds these kernels? Perhaps the better question is how can I actually find who builds these kernels? :) And if any exists, where is a git repo for these kernels? Thanks. poma

7 19

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel February 2014