Koji kernel 3.13.2-200.fc20.x86_64
by Brad Watson
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/
10 years, 1 month
Re: WARNING: CPU: 1 PID: 0 at kernel/time/tick-broadcast.c:668 tick_broadcast_oneshot_control+0x17d/0x190()
by poma
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
10 years, 1 month
WARNING: CPU: 0 PID: 2243 at mm/slub.c:1007 deactivate_slab+0x4e0/0x590()
by poma
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
10 years, 1 month
WARNING: CPU: 0 PID: 9502 at lib/dma-debug.c:554 debug_dma_assert_idle+0xc4/0x140()
by poma
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
10 years, 1 month
Re: Intel Dual Band Wireless 7260AC with Bluetooth 4.0 with Fedora
by poma
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.kerne...
https://bugzilla.redhat.com/show_bug.cgi?id=1000831
10 years, 1 month
Why does Red Hat and Fedora software not distinguish between AMD and Intel kernels?
by James Harrison
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
10 years, 1 month
Enabling CONFIG_MMC_UNSAFE_RESUME
by Hans de Goede
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
10 years, 1 month
RawhideKernelNodebug - Nosign
by poma
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
10 years, 1 month