openSUSE Kernel July 2013

kernel@lists.opensuse.org

21 participants
14 discussions

[opensuse-kernel] Modular drivers which could be built-in
by Jean Delvare 10 Mar '14

10 Mar '14

Hi all, Having worked on built-in drivers which could be modularized, I am now looking for modular drivers which could be built-in. Our policy is that drivers which are not hardware-specific and are needed on a majority of systems should be built into the kernel directly. So I checked which modules were loaded on my 4 systems. After filtering out hardware-specific modules, I am left with the following list: ACPI and thermal drivers: * button * processor * thermal_sys Block device drivers * cdrom * scsi_dh * scsi_dh_alua * scsi_dh_emc * scsi_dh_hp_sw * scsi_dh_rdac * sg * sr_mod Graphics helper drivers * drm * drm_kms_helper * i2c_algo_bit Filesystem drivers: * fuse * lockd * sunrpc CPU drivers: * microcode Sound drivers: * pcspkr * snd * snd_page_alloc * snd_pcm * snd_seq * snd_seq_device * snd_timer * soundcore If anyone has an opinion on whether these should be built into the kernel or left as modules, this is the right time to discuss it. My personal thoughts, with mostly x86 in mind: * The ACPI button and processor drivers could be built-in. Most x86 systems use ACPI and they supposedly all have at least one processor and one power button ;) And thermal_sys is selected by processor. * While all my systems have an optical drive, I know they have disappeared from many systems, both very small and very large ones, so leaving cdrom and sr_mod as modules seems fine. * I have no idea why/how sg is being loaded, it has no modalias and no other module depend on it. But /dev/sd* nodes are created so it is certainly useful. Hannes? * No idea what the scsi_dh* modules are about either, no modalias and no dependencies either. Hannes? * With DRM/KMS being the norm now, I believe drm and drm_kms_helper could be built-in, even though the former is quite large. drm selects i2c-algo-bit, most (all?) DRM/KMS drivers use it. Even servers have graphics chips. * I suppose fuse is only used on desktop machines by default, for gvfs, so having it as a module seems OK. * lockd and sunrpc are dependencies of nfs and nfsd. I suppose there are many users out there who don't serve nor mount NFS shares so modules make sense. * I think microcode could be unloaded after use, maybe for security reasons it might even be preferable, or just because there is simply no point in keeping it in memory. Thomas? Either way we should keep it modular. * For sound drivers, Takashi should know better than me. I suppose that the rationale for having these modular is that servers have no sound chip? -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

15 61

[opensuse-kernel] CONFIG_CC_STACKPROTECTOR
by richard -rw- weinberger 14 Dec '13

14 Dec '13

Hi! I'm wondering why CONFIG_CC_STACKPROTECTOR is disabled on openSUSE. Debian and Fedora seem to enabled it per default. What's the deal? -- Thanks, //richard -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

7 17

[opensuse-kernel] Kernel Problem with new Hardware
by Günther J. Niederwimmer 22 Aug '13

22 Aug '13

Hello, I have a new Asus Board P9D WS with the new xeon E3-1275v3 and Chipset Intel C226. Is the kernel for oS 12.3 running with this hardware? I have a big Problem with the intern Graphic and USB Maus / Keyboard Grub have no Problem to find the Mouse / Keyboard, in the oS I have to remove the USB Connector wait and insert the USB Connecter afterward I have a Mouse / Keyboard again. If it is possible to found the correct Graphic (KVM) driver? -- mit freundlichen Grüßen / best Regards, Günther J. Niederwimmer -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 8

[opensuse-kernel] Kernel:HEAD btrfs + chromium == hard lockup, crash
by Cristian Rodríguez 11 Aug '13

11 Aug '13

Hi: Since moving to 3.11rc2 the following happends Accessing a heavy site like youtube with chromium 30.x ends with > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: general protection fault: 0000 [#1] PREEMPT SMP > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: Modules linked in: af_packet cachefiles fscache hid_logitech_dj snd_hda_codec_hdmi x86_pkg_temp_thermal coretemp kvm_int > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: CPU: 2 PID: 1644 Comm: SimpleCacheWork Tainted: P O 3.11.0-rc2-1.g00cdcf9-desktop #1 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: Hardware name: DELL Inc. Studio XPS 435T/9000/0X501H, BIOS A16 02/04/2010 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: task: ffff8801bd4b2400 ti: ffff88019ff5a000 task.ti: ffff88019ff5a000 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: RIP: 0010:[<ffffffff812d85bd>] [<ffffffff812d85bd>] memcpy+0xd/0x110 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: RSP: 0018:ffff88019ff5b9a0 EFLAGS: 00010202 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: RAX: ffff880124c74107 RBX: 000000000000065a RCX: 00000000000000cb > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: RDX: 0000000000000002 RSI: db73880000000000 RDI: ffff880124c74107 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: RBP: ffff8801200ff7b0 R08: 0000000000000761 R09: 0000000000001000 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 6db6db6db6db6db7 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: R13: 0000160000000000 R14: ffff880124c74761 R15: 000000000000065a > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: FS: 00007fd825640700(0000) GS:ffff88023fc40000(0000) knlGS:0000000000000000 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: CR2: 00007fd8327d81a3 CR3: 00000001c9b52000 CR4: 00000000000027e0 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: Stack: > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: ffffffffa00cb868 0000000000000000 ffff880219379800 0000000000000000 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: ffff880120022a30 ffff880124c74000 ffff8801200ff6e0 ffff88010e865338 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: ffffffffa00b0aab 0000000000001000 ffff8801318226d0 0000000000000761 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: Call Trace: > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: [<ffffffffa00cb868>] read_extent_buffer+0xc8/0x120 [btrfs] > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: [<ffffffffa00b0aab>] btrfs_get_extent+0x8db/0x980 [btrfs] > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: [<ffffffffa00c8b36>] __extent_read_full_page+0x316/0x7d0 [btrfs] > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: [<ffffffffa00c9f99>] extent_readpages+0x169/0x1c0 [btrfs] > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: [<ffffffff81129a43>] __do_page_cache_readahead+0x1b3/0x260 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: [<ffffffff81129f17>] ondemand_readahead+0x117/0x250 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: [<ffffffff8111fb66>] generic_file_aio_read+0x4a6/0x6f0 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: [<ffffffff811827f7>] do_sync_read+0x67/0x90 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: [<ffffffff81182d94>] vfs_read+0x94/0x160 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: [<ffffffff811839e3>] SyS_pread64+0x63/0xa0 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: [<ffffffff815b6fff>] tracesys+0xe1/0xe6 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: [<00007fd85666dbd3>] 0x7fd85666dbd2 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: Code: fc ff ff 48 8b 43 58 48 2b 43 50 88 43 4e eb e9 90 90 90 90 90 90 90 90 90 90 90 90 90 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 <f3> 48 a5 89 d1 f3 a4 c3 20 4c 8b 06 4c 8b 4e 08 4c 8 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: RIP [<ffffffff812d85bd>] memcpy+0xd/0x110 > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: RSP <ffff88019ff5b9a0> > Jul 24 21:56:54 xps9000.cristianrodriguez.net kernel: ---[ end trace a4449cb6cdee0f9a ]--- No futher IO can be done, machine locks up, REISUB is the only escape :-| -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 18

[opensuse-kernel] BtrFS Usage/Complaints
by Jeff Mahoney 02 Aug '13

02 Aug '13

Hi all - Over the past year, btrfs has received substantial attention in the areas of both stability and performance. I've been running it, personally, on a 4 TB data volume as well as my root partitions for my openSUSE 12.2/12.3 systems. I've been able to do stress tests like a long fsmark run simultaneously with creating and removing snapshots (with syncs to force them to disk) and haven't run into any issues. David Sterba, who's been leading the charge at SUSE for btrfs stability has likewise regularly run it through an array of torture tests and has found that problems are occurring a whole lot less frequently than they have in the past. The upstream btrfs community in which we participate has also started focusing less on feature development and more on stability and performance. But these are only anecdotal data points from two file system guys and if my experiences working for a major operating systems vendor have taught me anything, it's that our users can be a lot more creative at finding ways to break things than we are. ;) So, I'd like to hear your stories. What's worked for you? What hasn't worked? What would you consider the pain points with using btrfs? Lastly, I'd like to ask that you take the opportunity to test with the latest openSUSE Factory kernel running 3.10-final. 12.3 used the 3.7 kernel since it was the most recent release going into the beta cycle and we've seen a bunch of btrfs fixes since that release. I look forward to your feedback and the opportunity to improve btrfs for the 13.1 release and future releases. Thanks! -Jeff -- Jeff Mahoney

13 22

[opensuse-kernel] [PATCH] atl1c: Fix misuse of netdev_alloc_skb in refilling rx ring
by David Chang 02 Aug '13

02 Aug '13

From: Eric Dumazet <edumazet(a)google.com> Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git Git-commit: 7b70176421993866e616f1cbc4d0dd4054f1bf78 Patch-mainline: Queued in subsystem maintainer repo References: bnc#812116 On Mon, 2013-07-29 at 08:30 -0700, Eric Dumazet wrote: > On Mon, 2013-07-29 at 13:09 +0100, Luis Henriques wrote: > > > > > I confirm that I can't reproduce the issue using this patch. > > > > Thanks, I'll send a polished patch, as this one had an error if > build_skb() returns NULL (in case sk_buff allocation fails) Please try the following patch : It should use 2K frags instead of 4K for normal 1500 mtu Thanks ! [PATCH] atl1c: use custom skb allocator We had reports ( https://bugzilla.kernel.org/show_bug.cgi?id=54021 ) that using high order pages for skb allocations is problematic for atl1c We do not know exactly what the problem is, but we suspect that crossing 4K pages is not well supported by this hardware. Use a custom allocator, using page allocator and 2K fragments for optimal stack behavior. We might make this allocator generic in future kernels. Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: Luis Henriques <luis.henriques(a)canonical.com> Cc: Neil Horman <nhorman(a)tuxdriver.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Acked-by: David Chang <dchang(a)suse.com> --- Target: openSUSE12.3 drivers/net/ethernet/atheros/atl1c/atl1c.h | 3 + drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 40 +++++++++++++++++++++++- 2 files changed, 42 insertions(+), 1 deletion(-) --- a/drivers/net/ethernet/atheros/atl1c/atl1c.h +++ b/drivers/net/ethernet/atheros/atl1c/atl1c.h @@ -520,6 +520,9 @@ struct atl1c_adapter { struct net_device *netdev; struct pci_dev *pdev; struct napi_struct napi; + struct page *rx_page; + unsigned int rx_page_offset; + unsigned int rx_frag_size; struct atl1c_hw hw; struct atl1c_hw_stats hw_stats; struct mii_if_info mii; /* MII interface info */ --- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c +++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c @@ -482,10 +482,15 @@ static int atl1c_set_mac_addr(struct net static void atl1c_set_rxbufsize(struct atl1c_adapter *adapter, struct net_device *dev) { + unsigned int head_size; int mtu = dev->mtu; adapter->rx_buffer_len = mtu > AT_RX_BUF_SIZE ? roundup(mtu + ETH_HLEN + ETH_FCS_LEN + VLAN_HLEN, 8) : AT_RX_BUF_SIZE; + + head_size = SKB_DATA_ALIGN(adapter->rx_buffer_len + NET_SKB_PAD) + + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)); + adapter->rx_frag_size = roundup_pow_of_two(head_size); } static netdev_features_t atl1c_fix_features(struct net_device *netdev, @@ -953,6 +958,10 @@ static void atl1c_free_ring_resources(st kfree(adapter->tpd_ring[0].buffer_info); adapter->tpd_ring[0].buffer_info = NULL; } + if (adapter->rx_page) { + put_page(adapter->rx_page); + adapter->rx_page = NULL; + } } /** @@ -1642,6 +1651,35 @@ static inline void atl1c_rx_checksum(str skb_checksum_none_assert(skb); } +static struct sk_buff *atl1c_alloc_skb(struct atl1c_adapter *adapter) +{ + struct sk_buff *skb; + struct page *page; + + if (adapter->rx_frag_size > PAGE_SIZE) + return netdev_alloc_skb(adapter->netdev, + adapter->rx_buffer_len); + + page = adapter->rx_page; + if (!page) { + adapter->rx_page = page = alloc_page(GFP_ATOMIC); + if (unlikely(!page)) + return NULL; + adapter->rx_page_offset = 0; + } + + skb = build_skb(page_address(page) + adapter->rx_page_offset, + adapter->rx_frag_size); + if (likely(skb)) { + adapter->rx_page_offset += adapter->rx_frag_size; + if (adapter->rx_page_offset >= PAGE_SIZE) + adapter->rx_page = NULL; + else + get_page(page); + } + return skb; +} + static int atl1c_alloc_rx_buffer(struct atl1c_adapter *adapter) { struct atl1c_rfd_ring *rfd_ring = &adapter->rfd_ring; @@ -1662,7 +1700,7 @@ static int atl1c_alloc_rx_buffer(struct while (next_info->flags & ATL1C_BUFFER_FREE) { rfd_desc = ATL1C_RFD_DESC(rfd_ring, rfd_next_to_use); - skb = netdev_alloc_skb(adapter->netdev, adapter->rx_buffer_len); + skb = atl1c_alloc_skb(adapter); if (unlikely(!skb)) { if (netif_msg_rx_err(adapter)) dev_warn(&pdev->dev, "alloc rx buffer failed\n"); -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 2

[opensuse-kernel] CONFIG_MICROCODE in kernel:HEAD
by Cristian Rodríguez 25 Jul '13

25 Jul '13

hi: CONFIG_MICROCODE= should be set to Y instead of m in 3.11rcn otherwise early microcode loading (as implemented in dracut at least) wont work. You also have to enable ONFIG_MICROCODE_*_EARLY to match to preserve the 3.10 behavior. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 7

[opensuse-kernel] [PATCH] kernel-default for openSUSE:Factory / armv6hl
by Dirk Müller 15 Jul '13

15 Jul '13

Hi, a few weeks ago we decided to ditch the armv5 efforts and go with armv6hl instead (which works for Raspberry Pi, but not for older chips). This gives a bit of performance and fewer miscompiles, so less things to worry. Could you please push the attached patch to master? TIA, Dirk

1 0

[opensuse-kernel] Debuginfo for x86_64 kernels (systemtap complaints about arch mismatch)
by Andrey Borzenkov 15 Jul '13

15 Jul '13

I'm trying to make systemtap work on 12.3 x86_64. Attempt to compile latencytap.stp from included examples gives bor@opensuse:/tmp> sudo stap latencytap.stp semantic error: ELF machine i?86| (code 3) mismatch with target x86_64 in '/usr/lib/debug/boot/vmlinux-3.7.10-1.11-desktop.debug' semantic error: while resolving probe point: identifier 'kernel' at latencytap.stp:51:7 source: kernel.function("deactivate_task") { ^ semantic error: no match semantic error: while resolving probe point: identifier 'kernel' at :62:7 source: kernel.function("activate_task") { ^ semantic error: while resolving probe point: identifier 'scheduler' at :81:7 source: probe scheduler.cpu_on { ^ Pass 2: analysis failed. Try again with another '--vp 01' option. Well, there is no debuginfo for x86_64, only for i586. Is it missing indeed or is it systemtap issue? -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

5 7

[opensuse-kernel] OpenSUSE 12.3/3.7.10 -1.1 BAR setting problem
by Mikhail Kuzminsky 09 Jul '13

09 Jul '13

I have following kernel (3.7.10-1.1) messages ---------------------------------------from /var/log/messages----------------------------------------- ... 2013-07-04T01:43:43.666022+04:00 c6ws4 kernel: [ 0.421559] pci 0000:00:01.0: BAR 15: can't assign mem pref (size 0x18000000) 2013-07-04T01:43:43.666024+04:00 c6ws4 kernel: [ 0.421563] pci 0000:00:01.0: BAR 14: assigned [mem 0xe1000000-0xe1ffffff] 2013-07-04T01:43:43.666025+04:00 c6ws4 kernel: [ 0.421566] pci 0000:00:16.1: BAR 0: assigned [mem 0xe0001000-0xe000100f 64bit] 2013-07-04T01:43:43.666026+04:00 c6ws4 kernel: [ 0.421576] pci 0000:01:00.0: BAR 1: can't assign mem pref (size 0x10000000) 2013-07-04T01:43:43.666027+04:00 c6ws4 kernel: [ 0.421579] pci 0000:01:00.0: BAR 3: can't assign mem pref (size 0x2000000) 2013-07-04T01:43:43.666027+04:00 c6ws4 kernel: [ 0.421581] pci 0000:01:00.0: BAR 0: assigned [mem 0xe1000000-0xe1ffffff] 2013-07-04T01:43:43.666028+04:00 c6ws4 kernel: [ 0.421584] pci 0000:01:00.0: BAR 6: can't assign mem pref (size 0x80000) 2013-07-04T01:43:43.666029+04:00 c6ws4 kernel: [ 0.421586] pci 0000:00:01.0: PCI bridge to [bus 01] ... ----------------------------------------------------------------------------------------------- This messages are for PCE-E GPU, see lspci -v extraction : 01:00.0 3D controller: NVIDIA Corporation GK107 [Tesla K20c] (rev a1) Subsystem: NVIDIA Corporation Device 0982 Flags: fast devsel, IRQ 11 Memory at e1000000 (32-bit, non-prefetchable) [disabled] [size=16M] Memory at <unassigned> (64-bit, prefetchable) [disabled] Memory at <unassigned> (64-bit, prefetchable) [disabled] Does this kernel messages above means that I have hardware/BIOS problems ? ( the corresponding NVIDIA driver installation says that PCI I/O region assigned to GPU device is invalid, but this may be driver error). Mikhail N��r��y隊Z)z{.��w��칻�&ޢ��'��-��w�zf��^�ˬzG��~� ޮ�^�ˬz��

1 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openSUSE Kernel July 2013