Manjaro Linux Forum

Technical Issues and Assistance => Kernel & Hardware => Topic started by: philm on 18. January 2014, 17:42:26

Title: Vote for your Kernel(s) to be kept!
Post by: philm on 18. January 2014, 17:42:26
Hi community, we already know that linux312 will be dropped soon by upstream. Greg will still maintain linux34 and linux310 almost thru 2014. Same does Canonical with their ESS kernels (extended stable support). Now I need from our community to know which of these kernels are still needed and which of them I can drop.

Since aufs3.4/8-20131104 was the last release by J. R. Okajima, linux34 and linux38 are already on my hit-list to be removed soon. Since Greg and Canonical still provide their updates for both of them and they won't be part of our install medias it is not so critical that AUFS isn't further developed for those kernels. For now I still maintain all of them until upstream stops pushing out some patches.

Please vote for your kernel(s) and we will know what the trend here with Manjaro is. Multible selections are possible.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Ayceman on 18. January 2014, 22:47:35
As I was expecting 3.8 looks ripe to be dropped.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 19. January 2014, 11:19:35
 :)

Nothing original. 3.10 for LTS and 3.13 for the latest developments.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: mips on 19. January 2014, 12:16:50
Nothing original. 3.10 for LTS and 3.13 for the latest developments.

+1
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Oedi on 19. January 2014, 14:24:18
Nothing original. 3.10 for LTS and 3.13 for the latest developments.
same here. 3.10 is good for my old desktop pc, but my notebook depends on 3.12 or newer because of a device specific bug (loops shortly before poweroff and needs manual poweroff) that was fixed in 3.13rc5 and was backported to 3.12, but not 3.10.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Verändert2.0 on 19. January 2014, 14:39:21
For me, the newest kernel would be enough. Maybe we could just keep older kernel on an "as is" basis without further updates, just for those who can't run a newer kernel ?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: ewolnux on 19. January 2014, 14:42:13
Hi

3.4 because some machines work fine with.
3.10 and 3.13.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 19. January 2014, 14:42:22
I have also only the 3.13 :)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: mandog on 19. January 2014, 15:01:22
There is no need for Ubuntu patched kernels this is a arch based system keep it that way. patching brings a host of other problems with it.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Ayceman on 19. January 2014, 15:24:27
Not really, patching brings security. The kernel is independent from the rest of the system (like their upstart or Unity), so Canonical patches are good.

Canonical maintained 3.11 is useful as an LTS for systems that benefit from some stuff that isn't in 3.10 (especially AMD GPU systems).
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Verändert2.0 on 19. January 2014, 15:30:14
Remember that every kernel has to be maintained. And the guy who maintains the kernels can't do anything else. So yes, it would be great to have as many kernels as possible to choose from, but then this means that something else won't be fixed or an awesome new feature won't be implemented.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: sb56637 on 19. January 2014, 15:32:46
I chose the oldest LTS (3.4) for some old hardware that prefers it, then the newest LTS (3.11) for good general long term stability, and the newest released kernel (3.13) for bleeding edge features and testing.

Please do continue to offer several kernel options for Manjaro, as I feel this is a key advantage of Manjaro. The reality of the Linux kernel is that there are frequent regressions that lead to hardware or functionality bugs. Forcing everyone to use the latest (but not always greatest) version of the kernel isn't good for everyone, whereas using a very old LTS kernel for everyone also isn't ideal. That's why I chose the two LTS kernels plus the newest kernel, which should keep everyone happy, and should still give users a refuge from kernel bugs that pop up in certain versions.

Thanks for all the work that goes into making Manjaro viable for many different users and scenarios!
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 19. January 2014, 15:48:39
Normally, it's the 3.10 you must choose for LTS, not the 3.11.

The main team is this of linux torvalds, at kernel.org (https://www.kernel.org/).

And there, the 3.11 is EOL.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: philm on 19. January 2014, 15:56:25
Canonical's SES kernels are vanila kernels. Both maintainers are great people and do a great job. Both kernels will be maintained till mid 2014 by upstream. I can keep them updated also. At one point there will be to many kernels, then I've to decide which kernel I've to drop. In rare cases linux 3.8 is still used. Linux 3.11 is used for hardware having issues with linux312 and higher. Some of them might be fixed in linux 3.13. I expect linux 314 as on of the next LTS kernels by Greg.

This poll is designed to find out how many people still relate on older kernels. Shipping several kernels is a key-feature of Manjaro. If we keep older kernels as is, I've still to maintain all extramodules of that series, since they might change for other kernel series. This topic is far more complex as I wrote it down. I've no issues to build them all. On some point I've to reduce them a little ...
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 19. January 2014, 16:01:58
3.11 is patched and validated for the purposes of Canonical, not for those of Arch.

And for the team of Linus, it's EOL.

Do we have the same patches than Canonical ?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: eskaini on 19. January 2014, 16:13:40
Remember that every kernel has to be maintained. And the guy who maintains the kernels can't do anything else. So yes, it would be great to have as many kernels as possible to choose from, but then this means that something else won't be fixed or an awesome new feature won't be implemented.

I have always wondered where the line should be between old hardware and hardware that is too old. I realize its a moving target, but at some point isn't the work exceeding the value gained? I am not saying that we shouldn't support older hardware, I'm just asking how far back and for how long we should keep older kernels.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: excalibur1234 on 19. January 2014, 16:34:48
@Dan:
i remember that one of the later kernels (3.12, or 3.13) dropped support (=the drivers) for about 20 year old 486-er PCs: https://en.wikipedia.org/wiki/Intel_80486

therefore, even the latest kernels still support really old computers. even if you still use such an old computer, manjaro would NOT run on it.

i just cannot see a case, in which the latest LTS (=almost bug-free) linux kernel cannot be used on a pc, which is able to run manjaro.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: eskaini on 19. January 2014, 17:02:33
excalibur1234, thanks for explaining. Are you saying that there isn't much cause then for keeping the older kernels around?
Quote
i just cannot see a case, in which the latest LTS (=almost bug-free) linux kernel cannot be used on a pc, which is able to run manjaro.

Edit: sb56637, just reread your post, I can see your reasoning . This is more then likely a multifaceted discussion....
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Ayceman on 19. January 2014, 23:41:49
3.11 is patched and validated for the purposes of Canonical, not for those of Arch.

And for the team of Linus, it's EOL.

Do we have the same patches than Canonical ?

Kernel patches are distribution agnostic and relate to security and stability.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: excalibur1234 on 20. January 2014, 00:03:08
excalibur1234, [...] are you saying that there isn't much cause then for keeping the older kernels around?
yes.

the only reason for using an older kernel is the stability (=less obvious bugs - most of them got already fixed).

new kernels contain more and better drivers (especially for modern hardware).
one example: www.phoronix.com/vr.php?view=19688
Title: Re: Vote for your Kernel(s) to be kept!
Post by: eskaini on 20. January 2014, 00:11:36
excalibur1234
Makes sense, thanks for clarifying.  :)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 20. January 2014, 00:13:08
Quote
Des correctifs de noyau sont la distribution agnostique et liés à la sécurité et à la stabilité.

My question is also : do we have exactly the same ? I dont think so.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Ayceman on 20. January 2014, 03:49:05
Yes we do actually, or phil wouldn't be building them in the first place.

Also, are you using Google Translate, because that is one weird effect in your post?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 20. January 2014, 10:26:40
You say a lot of things, but without evidence. And yes, I'm not english-speaking.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Lukimya on 20. January 2014, 11:12:13
Keep the lts ones. Ditch the others.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: mandog on 20. January 2014, 12:49:29
You say a lot of things, but without evidence. And yes, I'm not english-speaking.
There is nothing wrong with your English don't respond to to criticism from certain people. 
Title: Re: Vote for your Kernel(s) to be kept!
Post by: wolfyrion on 20. January 2014, 13:57:44
I have tested Linux 3.10 LTS series and 3.13 so far

I have to say that 3.10 runs much smoother than 3.13...

Especially in some games you can easily see the difference between the two kernels...
with 3.13 you can observe lag spikes etc but this is not happening with 3.10

Anyway my opinion about the kernels is

Keep up maintain the latest Kernel available
Maintain the latest LTS Kernel
Maintain the latest kernel SES series (maintained by Canonical)

So in short you just maintain 3 Kernels and have everyone happy :)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Ayceman on 21. January 2014, 01:44:37
You say a lot of things, but without evidence. And yes, I'm not english-speaking.

You're the one claiming that because Canonical is maintaining the kernel it's not suitable. I may not be an expert, but I know a thing or two about the structure of a Linux OS and phil did actually respond to this in post 14 of this thread.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: ruziel on 21. January 2014, 08:19:35
Ayceman, don't forget that there are a lot of non-native English speakers - Esclapion being one of them. I'm not saying you meant to be rude with the "google translate" comment, but it could be taken that way. Lets keep the kernel conversation chilled people....

3.13 is proving to be surprisingly smooth so far, on my machine....

More power to u all.

Ruziel  ;)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Ayceman on 21. January 2014, 12:35:14
Actually I was just curious because I have never seen an auto-quoted text be displayed translated. and was wondering how that worked.

As for 3.13 - I have noticed that as well.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: lightbeam on 21. January 2014, 13:15:39
Why are Linux users so grumpy?  :-)

Anyway, I voted.  Seems support for two LTS, one SES, and the latest kernel should keep everybody happy for a while.

I like the delayed release model of the latest kernel that Manjaro uses, so that's cool with me.  I keep 3.10 LTS as my trusty, rusty backup just in case things go cuckoo with a bleeding edge update.

Keep up the good work, Philm!!
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Ham Radio on 21. January 2014, 17:09:55
I vote for 3.4 LTS, 3.10 LTS, and the latest 3.13. No need for the other ones.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: spectromas on 22. January 2014, 06:46:03
I don't know what SES means but 3.11 was when dpm was implemented wasn't it? For me the earliest or most LTS version with this feature and the latest version would be ideal, dpm is a must for me.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Ayceman on 22. January 2014, 13:29:42
He's got a point.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: conky57 on 22. January 2014, 14:31:10
I don't know what SES means but 3.11 was when dpm was implemented wasn't it? For me the earliest or most LTS version with this feature and the latest version would be ideal, dpm is a must for me.

I agree, dpm is a must for me as well....and likely for other amd graphics users too. Without dpm, my laptop runs hot with fans roaring. Nothing older than 3.11 in my opinion for usability. Personally 3.13 is what I am using, with 3.12 as backup. Both are working well for me.  :)

Best regards.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: ruziel on 22. January 2014, 15:05:02
The key question is this: What would Frank Zappa choose in this situation?  ;)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 22. January 2014, 18:19:35
3.11 is patched and validated for the purposes of Canonical, not for those of Arch.
I am no Canonical fanboy, whatsoever. However this I believe is inaccurate.

Here is a list of the fixes for Canonical's 3.11.10.2 kernel release:
[spoiler]Aaro Koskinen (1):
      ARM: OMAPFB: panel-sony-acx565akm: fix bad unlock balance

AceLan Kao (2):
      HID: usbhid: quirk for Synaptics Large Touchccreen
      HID: usbhid: quirk for SiS Touchscreen

Alan Cox (1):
      drivers/char/i8k.c: add Dell XPLS L421X

Alan Stern (1):
      usb: dwc3: fix implementation of endpoint wedge

Alex Deucher (5):
      drm/radeon: fix typo in fetching mpll params
      drm/radeon: program DCE2 audio dto just like DCE3
      drm/radeon: fixup bad vram size on SI
      drm/radeon: atombios hw i2c fixes
      drm/radeon/atom: fix bus probes when hw_i2c is set (v2)

Alexei Starovoitov (1):
      ipv4: fix race in concurrent ip_route_input_slow()

Amir Vadai (1):
      net/mlx4_en: Fixed crash when port type is changed

Andreas Henriksson (1):
      net: Fix "ip rule delete table 256"

Andrey Vagin (1):
      tcp: don't update snd_nxt, when a socket is switched from repair mode

Andy Adamson (1):
      NFSv4 wait on recovery for async session errors

Andy Honig (3):
      KVM: Improve create VCPU parameter (CVE-2013-4587)
      KVM: x86: Fix potential divide by 0 in lapic (CVE-2013-6367)
      KVM: x86: Convert vapic synchronization to _cached functions (CVE-2013-6368)

Anssi Hannula (1):
      ALSA: hda - hdmi: Fix IEC958 ctl indexes for some simple HDMI devices

Antti Palosaari (3):
      [media] af9035: add [0413:6a05] Leadtek WinFast DTV Dongle Dual
      [media] af9035: fix broken I2C and USB I/O
      [media] af9033: fix broken I2C

Arnaud Ebalard (2):
      ARM: mvebu: fix second and third PCIe unit of Armada XP mv78260
      ARM: mvebu: second PCIe unit of Armada XP mv78230 is only x1 capable

Ben Hutchings (1):
      HID: kye: Fix missing break in kye_report_fixup()

Ben Segall (1):
      sched: Avoid throttle_cfs_rq() racing with period_timer stopping

Benjamin Tissoires (1):
      HID: kye: Add report fixup for Genius Manticore Keyboard

Bo Shen (1):
      ASoC: wm8731: fix dsp mode configuration

Bob Copeland (1):
      Revert "mac80211: allow disable power save in mesh"

Brian Carnes (1):
      hwmon: (w83l786ng) Fix fan speed control mode setting and reporting

Carolyn Wyborny (1):
      igb: Fix for issue where values could be too high for udelay function.

Chris Metcalf (1):
      connector: improved unaligned access error fix

Colin Leitner (4):
      USB: spcp8x5: correct handling of CS5 setting
      USB: mos7840: correct handling of CS5 setting
      USB: ftdi_sio: fixed handling of unsupported CSIZE setting
      USB: pl2303: fixed handling of CS5 setting

Dan Carpenter (6):
      isdnloop: use strlcpy() instead of strcpy()
      net: clamp ->msg_namelen instead of returning an error
      [media] af9035: unlock on error in af9035_i2c_master_xfer()
      hwmon: Prevent some divide by zeros in FAN_TO_REG()
      Btrfs: fix access_ok() check in btrfs_ioctl_send()
      xfs: underflow bug in xfs_attrlist_by_handle()

Dan Williams (1):
      [SCSI] libsas: fix usage of ata_tf_to_fis

Daniel Borkmann (2):
      random32: fix off-by-one in seeding requirement
      packet: fix use after free race in send path when dev is released

Dave Chinner (1):
      xfs: growfs overruns AGFL buffer on V4 filesystems

David Chang (1):
      r8169: check ALDPS bit and disable it if enabled for the 8168g

David Cluytens (1):
      USB: cdc-acm: Added support for the Lenovo RD02-D400 USB Modem

David Henningsson (2):
      ALSA: hda - Add mono speaker quirk for Dell Inspiron 5439
      ALSA: hda - Fix headset mic input after muted internal mic (Dell/Realtek)

David Sterba (1):
      btrfs: call mnt_drop_write after interrupted subvol deletion

Ding Tianhong (1):
      bridge: flush br's address entry in fdb when remove the

Dmitry Eremin-Solenikov (1):
      ARM: pxa: tosa: fix keys mapping

Duan Jiong (1):
      ipv6: use rt6_get_dflt_router to get default router in rt6_route_rcv

Dwight Engen (1):
      xfs: add capability check to free eofblocks ioctl

Emmanuel Grumbach (2):
      iwlwifi: dvm: don't override mac80211's queue setting
      iwlwifi: pcie: fix interrupt coalescing for 7260 / 3160

Eric Dumazet (5):
      tcp: tsq: restore minimal amount of queueing
      net-tcp: fix panic in tcp_fastopen_cache_set()
      ipv4: fix possible seqlock deadlock
      inet: fix possible seqlock deadlocks
      sch_tbf: handle too small burst

Fangxiaozhi (Franko) (1):
      USB: option: support new huawei devices

Felix Fietkau (1):
      usbnet: fix status interrupt urb handling

Gerald Schaefer (1):
      crypto: s390 - Fix aes-xts parameter corruption

Gleb Natapov (1):
      KVM: x86: fix guest-initiated crash with x2apic (CVE-2013-6376)

Gregory CLEMENT (1):
      ARM: mvebu: use the virtual CPU registers to access coherency registers

Gustavo Zacarias (1):
      USB: serial: option: blacklist interface 1 for Huawei E173s-6

H. Peter Anvin (3):
      x86-64, build: Always pass in -mno-sse
      x86, build: Pass in additional -mno-mmx, -mno-sse options
      x86, build, icc: Remove uninitialized_var() from compiler-intel.h

Hannes Frederic Sowa (9):
      ipv6: fix headroom calculation in udp6_ufo_fragment
      ipv6: protect for_each_sk_fl_rcu in mem_check with rcu_read_lock_bh
      inet: prevent leakage of uninitialized memory to user in recv syscalls
      net: rework recvmsg handler msg_name and msg_namelen logic
      net: add BUG_ON if kernel advertises msg_namelen > sizeof(struct sockaddr_storage)
      inet: fix addr_len/msg->msg_namelen assignment in recv_error and rxpmtu functions
      ipv6: fix leaking uninitialized port number of offender sockaddr
      ipv6: fix possible seqlock deadlock in ip6_finish_output2
      ping: prevent NULL pointer dereference on write to msg_name

Hans Verkuil (3):
      [media] bttv: don't setup the controls if there are no video devices
      [media] tef6862/radio-tea5764: actually assign clamp result
      [media] wm8775: fix broken audio routing

Helge Deller (2):
      parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
      nfs: fix do_div() warning by instead using sector_div()

Herbert Xu (2):
      gro: Only verify TCP checksums for candidates
      gro: Clean up tcpX_gro_receive checksum verification

Hong H. Pham (1):
      powerpc: Fix PTE page address mismatch in pgtable ctor/dtor

Hong Zhiguo (1):
      Update of blkg_stat and blkg_rwstat may happen in bh context.     While u64_stats_fetch_retry is only preempt_disable on 32bit     UP system. This is not enough to avoid preemption by bh and     may read strange 64 bit value.

Horia Geanta (1):
      crypto: ccm - Fix handling of zero plaintext when computing mac

Hui Wang (3):
      ALSA: hda - A Dell headset detection quirk
      ALSA: hda - Another Dell headset detection quirk
      ALSA: hda - One more Dell headset detection quirk

Ivan Vecera (1):
      tg3: avoid double-freeing of rx data memory

James Bottomley (1):
      [SCSI] enclosure: fix WARN_ON in dual path device removing

Jason Wang (2):
      tuntap: limit head length of skb allocated
      macvtap: limit head length of skb allocated

Jean Delvare (1):
      hwmon: (w83l768ng) Fix fan speed control range

Jeff Layton (1):
      nfsd: when reusing an existing repcache entry, unhash it first

Jerome Glisse (1):
      radeon/i2c: do not count reg index in number of i2c byte we are writing.

Jim Quinlan (1):
      MIPS: DMA: For BMIPS5000 cores flush region just like non-coherent R10000

Jiri Pirko (3):
      ip6_output: fragment outgoing reassembled skb properly
      netfilter: push reasm skb through instead of original frag skbs
      team: fix master carrier set when user linkup is enabled

Joe Thornber (4):
      dm thin: switch to read only mode if a mapping insert fails
      dm thin: re-establish read-only state when switching to fail mode
      dm thin: allow pool in read-only mode to transition to read-write mode
      dm array: fix a reference counting bug in shadow_ablock

Joel Fernandes (1):
      ARM: OMAP2+: Disable POSTED mode for errata i103 and i767

Johan Hovold (1):
      USB: serial: fix race in generic write

Johannes Berg (3):
      mac80211: fix scheduled scan rtnl deadlock
      mac80211: don't attempt to reorder multicast frames
      iwlwifi: mvm: check sta_id/drain values in debugfs

Joonyoung Shim (1):
      lib/genalloc.c: fix overflow of ending address of memory chunk

José Miguel Gonçalves (1):
      hwmon: HIH-6130: Support I2C bus drivers without I2C_FUNC_SMBUS_QUICK

Jukka Rissanen (1):
      6lowpan: Uncompression of traffic class field was incorrect

Julian Stecklina (1):
      iommu/vt-d: Fixed interaction of VFIO_IOMMU_MAP_DMA with IOMMU address limits

Julius Werner (1):
      usb: hub: Use correct reset for wedged USB3 devices that are NOTATTACHED

KOBAYASHI Yoshitake (1):
      mmc: block: fix a bug of error handling in MMC driver

Khalid Aziz (1):
      PCI: Disable Bus Master only on kexec reboot

Konrad Rzeszutek Wilk (1):
      cpuidle: Check for dev before deregistering it.

Konstantin Khlebnikov (2):
      ARM: 7912/1: check stack pointer in get_wchan
      ARM: 7913/1: fix framepointer check in unwind_frame

Laxman Dewangan (1):
      irq: Enable all irqs unconditionally in irq_resume

Linus Pizunski (1):
      drivers/rtc/rtc-at91rm9200.c: correct alarm over day/month wrap

Linus Torvalds (2):
      vfs: fix subtle use-after-free of pipe_inode_info
      futex: fix handling of read-only-mapped hugepages

Linus Walleij (1):
      net: smc91: fix crash regression on the versatile

Liu Gang (1):
      powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536

Ludovic Desroches (1):
      ARM: at91: sama5d3: reduce TWI internal clock frequency

Luis Henriques (1):
      Linux 3.11.10.2

Madper Xie (1):
      efi-pstore: Make efi-pstore return a unique id

Marc Kleine-Budde (2):
      can: c_can: don't call pm_runtime_get_sync() from interrupt context
      can: flexcan: use correct clock as base for bit rate calculation

Mark Brown (1):
      ASoC: wm8990: Mark the register map as dirty when powering down

Martin K. Petersen (1):
      [SCSI] Disable WRITE SAME for RAID and virtual host adapter drivers

Martin Schwidefsky (1):
      time: Fix 1ns/tick drift w/ GENERIC_TIME_VSYSCALL_OLD

Mateusz Guzik (1):
      aio: restore locking of ioctx list on removal

Matt Wilson (1):
      xen/gnttab: leave lazy MMU mode in the case of a m2p override failure

Matthew Garrett (1):
      x86, efi: Don't use (U)EFI time services on 32 bit

Maxime Ripard (1):
      net: allwinner: emac: Add missing free_irq

Michael Grzeschik (1):
      usb: gadget: composite: reset delayed_status on reset_config

Mika Westerberg (1):
      spi/pxa2xx: add new ACPI IDs

Mike Snitzer (1):
      dm space map metadata: return on failure in sm_metadata_new_block

Mikulas Patocka (4):
      dm delay: fix a possible deadlock due to shared workqueue
      dm snapshot: avoid snapshot space leak on crash
      dm table: fail dm_table_create on dm_round_up overflow
      dm bufio: initialize read-only module parameters

Miroslav Lichvar (1):
      ntp: Make periodic RTC update more reliable

Neil Horman (1):
      iommu: Remove stack trace from broken irq remapping warning

Nicolas Dichtel (1):
      ip6tnl: fix use after free of fb_tnl_dev

Nikolay Aleksandrov (1):
      bonding: fix two race conditions in bond_store_updelay/downdelay

Oliver Hartkopp (1):
      can: sja1000: fix {pre,post}_irq() handling and IRQ handler return value

Oliver Neukum (1):
      HID: hid-elo: some systems cannot stomach work around

Paul Moore (2):
      selinux: handle TCP SYN-ACK packets correctly in selinux_ip_output()
      selinux: handle TCP SYN-ACK packets correctly in selinux_ip_postroute()

Pierre Ossman (2):
      drm/radeon/audio: improve ACR calculation
      drm/radeon/audio: correct ACR table

Rafael J. Wysocki (1):
      intel_pstate: Fix type mismatch warning

Rob Herring (1):
      ARM: highbank: handle soft poweroff and reset key events

Russell King (3):
      ARM: fix booting low-vectors machines
      ARM: footbridge: fix VGA initialisation
      ARM: footbridge: fix EBSA285 LEDs

Sasha Levin (1):
      video: kyro: fix incorrect sizes when copying to userspace

Sebastian Andrzej Siewior (2):
      usb: musb: cancel work on removal
      usb: musb: only cancel work if it is initialized

Seiji Aguchi (1):
      efivars, efi-pstore: Hold off deletion of sysfs entry until the scan is completed

Sergei Ianovich (1):
      ARM: pxa: prevent PXA270 occasional reboot freezes

Shawn Landden (1):
      net: update consumers of MSG_MORE to recognize MSG_SENDPAGE_NOTLAST

Simon Wood (1):
      HID: lg: fix Report Descriptor for Logitech MOMO Force (Black)

Srinivas Pandruvada (1):
      intel_pstate: fix no_turbo

Stefano Panella (1):
      ALSA: memalloc.h - fix wrong truncation of dma_addr_t

Stephen M. Cameron (2):
      [SCSI] hpsa: do not discard scsi status on aborted commands
      [SCSI] hpsa: return 0 from driver probe function on success, not 1

Steve Capper (1):
      arm64: mm: Fix PMD_SECT_PROT_NONE definition

Steven Whitehouse (1):
      GFS2: Fix ref count bug relating to atomic_open

Sujith Manoharan (2):
      ath9k: Fix QuickDrop usage
      ath9k: Fix XLNA bias strength

Takashi Iwai (8):
      ALSA: hda - Fix silent output on ASUS W7J laptop
      ALSA: hda - Fix bad EAPD setup for HP machines with AD1984A
      ALSA: hda - Another fixup for ASUS laptop with ALC660 codec
      ALSA: hda - Use always amps for auto-mute on AD1986A codec
      ALSA: hda - Fix silent output on MacBook Air 2,1
      ALSA: compress: Fix 64bit ABI incompatibility
      ALSA: hda - Mute all aamix inputs as default
      ALSA: hda - Add static DAC/pin mapping for AD1986A codec

Tom Gundersen (2):
      Input: allow deselecting serio drivers even without CONFIG_EXPERT
      Input: mousedev - allow disabling even without CONFIG_EXPERT

Tom Lendacky (3):
      crypto: authenc - Find proper IV address in ablkcipher callback
      crypto: scatterwalk - Set the chain pointer indication bit
      crypto: scatterwalk - Use sg_chain_ptr on chain entries

Tomas Winkler (2):
      mei: me: add Lynx Point Wellsburg work station device id
      mei: add 9 series PCH mei device ids

Tomoki Sekiyama (2):
      elevator: Fix a race in elevator switching and md device initialization
      elevator: acquire q->sysfs_lock in elevator_change()

Trond Myklebust (1):
      NFSv4: Update list of irrecoverable errors on DELEGRETURN

Ujjal Roy (1):
      mwifiex: fix memory leak issue for ibss join

Veaceslav Falico (2):
      bonding: don't permit to use ARP monitoring in 802.3ad mode
      af_packet: block BH in prb_shutdown_retire_blk_timer()

Vijaya Mohan Guvva (1):
      [SCSI] bfa: Fix crash when symb name set for offline vport

Ville Syrjälä (1):
      drm/i915: Fix pipe CSC post offset calculation

Vlad Yasevich (1):
      net: core: Always propagate flag changes to interfaces

Wei Yongjun (1):
      [media] saa7164: fix return value check in saa7164_initdev()

Will Deacon (1):
      iommu/arm-smmu: use mutex instead of spinlock for locking page tables

Yang Yingliang (1):
      net: 8139cp: fix a BUG_ON triggered by wrong bytes_compl

Ying Xue (1):
      atm: idt77252: fix dev refcnt leak

fan.du (2):
      xfrm: Release dst if this dst is improper for vti tunnel
      {pktgen, xfrm} Update IPv4 header total len and checksum after tranformation

françois romieu (1):
      via-velocity: fix netif_receive_skb use in irq disabled section.[/spoiler]

https://www.lwn.net/Articles/579262/
Glimpse the fixes and tell me how much of it looks even slightly Ubuntu specific?
It looks to be almost all general bugfixes to me.

To my knowledge/experience, the 3.11 kernel does offer some superiority for users of some modern laptops over 3.10. With 3.12 being EOL'd soon and 3.13 only just off the hot plate, I don't think keeping the (Canonical) maintained 3.11 kernel around is a bad idea.

EDIT: I see now Ayceman already mentioned this on page 2 :-[ but i'm happy to reiterate it. :P
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 22. January 2014, 18:27:19
The kernel is recompiled and patched here, no ? Do we use the same patchs ?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 22. January 2014, 18:31:26
The kernel is recompiled and patched here, no ? Do we use the same patchs ?
I don't understand exactly what you mean, but yes we compile the kernel with the patchset from Canonical.
Other patchsets are usually also in use on all Manjaro kernels (such as Aufs support, usually some fixes from Gentoo, etc.)

EDIT:
Here's the patches currently applied to our 3.11 kernel:
Code: [Select]
  # add upstream patch
  patch -p1 -i "${srcdir}/patch-${_basekernel}.10"

  # add extended stable patch(es)
  patch -p1 -i "${srcdir}/${_basekernel}.10.1.patch"        ### THE CANONICAL PATCHES
  patch -p1 -i "${srcdir}/${_basekernel}.10.2.patch"        ### THE CANONICAL PATCHES

  # set DEFAULT_CONSOLE_LOGLEVEL to 4 (same value as the 'quiet' kernel param)
  # remove this when a Kconfig knob is made available by upstream
  # (relevant patch sent upstream: https://lkml.org/lkml/2011/7/26/227)
  patch -Np1 -i "${srcdir}/change-default-console-loglevel.patch"
 
  # add intel haswell support to intel_pstate
  # https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=6cdcdb793791f776ea9408581b1242b636d43b37
  # will be in 3.12
  patch -Np1 -i "${srcdir}/3.11-haswell-intel_pstate.patch"

  # allow criu without expert option set
  # patch from fedora
  patch -Np1 -i "${srcdir}/criu-no-expert.patch"

  # add Gentoo patches
  patch -Np1 -i "${srcdir}/1700_enable-thinkpad-micled.patch"
  patch -Np1 -i "${srcdir}/2700_ThinkPad-30-brightness-control-fix.patch"

  # add aufs3 support
  patch -Np1 -i "${srcdir}/aufs3.11-${_aufs}.patch"
  patch -Np1 -i "${srcdir}/aufs3-base.patch"
  patch -Np1 -i "${srcdir}/aufs3-kbuild.patch"
  patch -Np1 -i "${srcdir}/aufs3-loopback.patch"
  patch -Np1 -i "${srcdir}/aufs3-mmap.patch"
  patch -Np1 -i "${srcdir}/aufs3-standalone.patch"
http://git.manjaro.org/package-sources/core/blob/master/linux311/PKGBUILD
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 22. January 2014, 18:37:52
I only have a look on the possible differences.  ;)

If Ubuntu and us are starting from a Vanilla kernel (and not from a modified Debian), there are few, thanks.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: DarkMind on 26. January 2014, 22:39:27
i use the repo-ck

Linux manjaro 3.12.8-1-ck #1 SMP PREEMPT Fri Jan 17 15:34:37 EST 2014 x86_64 GNU/Linux

and works very good :D
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Erwan on 27. January 2014, 10:20:14
hi,
310 is very stable, you need to keep. 313 is not yet stable and not work well with my Nvidia GPU
Title: Re: Vote for your Kernel(s) to be kept!
Post by: ringo on 27. January 2014, 10:41:17
personal option is always a kernel 310 in the backhand if some trouble on new kernel,  but 310 does not work for all so 311 is also for hem :)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Arup on 27. January 2014, 11:04:52
For modern laptops 3.11 is the base to start with as it removes the Fn keys control for brightness issues.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 27. January 2014, 11:17:53
dpm works good only since 3.12 (included)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: babania2215 on 27. January 2014, 12:35:50
Well, we could try to remove the whole 3.x series, as suspend-resume is broken in these :) Anyway, 1-2 newest lts series + 2-3 newest short term support kernels, thats whats gona happen.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: rikkinho on 11. February 2014, 03:10:17
3.13 and 3.10, only problem is the nvidia driver for 3.13
Title: Re: Vote for your Kernel(s) to be kept!
Post by: raidermax on 14. February 2014, 17:44:59
I think you guys should maintain at least ONE really old kernel for support of older video cards such as the Radeon HD 4000 series from AMD/ATI ( (Radeon HD 4000 series only support up to the 3.4 kernel and Xorg 1.12).). This way you will support both older computers and new, rather than just newer hardware.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 14. February 2014, 17:51:10
I think you guys should maintain at least ONE really old kernel for support of older video cards such as the Radeon HD 4000 series from AMD/ATI ( (Radeon HD 4000 series only support up to the 3.4 kernel and Xorg 1.12).). This way you will support both older computers and new, rather than just newer hardware.

No one distro does it. And the free driver for legacy cards are now probably better than the Catalyst.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: rikkinho on 14. February 2014, 17:54:21
I think you guys should maintain at least ONE really old kernel for support of older video cards such as the Radeon HD 4000 series from AMD/ATI ( (Radeon HD 4000 series only support up to the 3.4 kernel and Xorg 1.12).). This way you will support both older computers and new, rather than just newer hardware.

opensource drivers are the same level of catalyst and maintain by opensource amd devs opengl 3.3 is ready in mesa 10.1 git
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Hertz on 14. February 2014, 19:54:42
Hi All,

i'have vote kernel 3.10.xxx LTS the best for me for my personal applications use.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: raidermax on 15. February 2014, 14:15:01
No one distro does it. And the free driver for legacy cards are now probably better than the Catalyst.
Ohh,  I did not know this. Do the free drivers support any version of xorg/catalyst or do they have the limits also like catalyst.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 15. February 2014, 14:31:11
For me, the free drivers are absolutely different of the proprietary drivers, because an important part of them are included in the kernel. So, they progress with him, without new installation.
Consequently, the last free drivers are a lot more efficient (Mantle support, etc...) as the previous one.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: excalibur1234 on 15. February 2014, 14:56:32
Ohh,  I did not know this. Do the free drivers support any version of xorg/catalyst or do they have the limits also like catalyst.

the free drivers (especially for intel and amd cards) feel much more organic in linux than the proprietary drivers.

just try them. you can easily change between them in the manjaro settings...
Title: Re: Vote for your Kernel(s) to be kept!
Post by: rikkinho on 15. February 2014, 20:04:52
Ohh,  I did not know this. Do the free drivers support any version of xorg/catalyst or do they have the limits also like catalyst.

your gcn/si card need some work with free drivers, and 2d performance is bad, but is improving a lot.

last benchs

http://www.phoronix.com/scan.php?page=article&item=amd_radeon_2014gallium&num=1
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Jeannie on 18. February 2014, 11:46:14
May I ask why kernel 3.11, which is stated to be eol at the kernel.org page is available in the poll, while kernel 3.12 which seems to be alive and kicking is not available?
J.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 18. February 2014, 11:51:34
Hi :)

Some people coming from Ubuntu consider  it  as a LTS, because it is a bit maintained there. But yes, from the point-of-view of the kernel team, it is an EOL.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Jeannie on 18. February 2014, 12:12:32
This does not answer my question: Why is 3.11 available in the poll, but 3.12 is not?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 18. February 2014, 12:16:21
This answers for the 3.11. The 3.12 is not there because it is not the last and will soon be EOL also.
When the 3.14 will be released, the 3.13 will slowly disappears also.

For me, one LTS and the last stable is a good solution.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 18. February 2014, 12:24:10
May I ask why kernel 3.11, which is stated to be eol at the kernel.org page is available in the poll, while kernel 3.12 which seems to be alive and kicking is not available?
J.
This does not answer my question: Why is 3.11 available in the poll, but 3.12 is not?
The answer is because the 3.11 kernel is being maintained by people who are not directly connected to kernel.org, so it can not be used as a source of information relating to the 3.11 series kernel that is being offered by Manjaro.

The 3.11 kernel we offer is the one that Canonical maintains for their Ubuntu 13.10 release. (Just like our 3.8 kernel is the one Canonical maintains for their 12.04 LTS Ubuntu release)
Canonical's patchwork to this kernel is not specific to Ubuntu. It addresses general security and bugs.

The 3.12 kernel however has not been picked up by any 3rd parties for maintenance, and as such is on it's way out.
Though the 3.13 kernel is a mess, so 3.12 may well see maintenance from kernel.org for longer than usual, which is probably why it's not been officially marked as "EOL" on kernel.org.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: rikkinho on 20. February 2014, 23:23:07
The answer is because the 3.11 kernel is being maintained by people who are not directly connected to kernel.org, so it can not be used as a source of information relating to the 3.11 series kernel that is being offered by Manjaro.

The 3.11 kernel we offer is the one that Canonical maintains for their Ubuntu 13.10 release. (Just like our 3.8 kernel is the one Canonical maintains for their 12.04 LTS Ubuntu release)
Canonical's patchwork to this kernel is not specific to Ubuntu. It addresses general security and bugs.

The 3.12 kernel however has not been picked up by any 3rd parties for maintenance, and as such is on it's way out.
Though the 3.13 kernel is a mess, so 3.12 may well see maintenance from kernel.org for longer than usual, which is probably why it's not been officially marked as "EOL" on kernel.org.

nvidia already working with 3.13.

kernel 3.13.3 no problems untill now
Title: Re: Vote for your Kernel(s) to be kept!
Post by: jaskerx on 24. February 2014, 17:11:54
I am using a somewhat new laptop (yoga 2 pro) and was curious about weather or not the new version that just came out yesterday would boot with the default kernel so I downloaded the iso and low and behold it still won't boot with a 3.10 kernel. Tried the acpi_backlight=vendor grub boot option but even that won't work. For all the new tech out there that will not boot with even the latest LTS kernel what are a users options for installing manjaro? Why does this distro not ship with the latest kernel and allow the user to install the LTS kernel if they choose? Does manjroiso work on other distro's? The only option I now see is installing manjaroiso and rolling my own with the latest kernel just to get a working copy with the latest.

 
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Ayceman on 25. February 2014, 20:25:01
Here's a KDE spin with 3.12 instead of 3.10:

@CarlosMosca:

https://sourceforge.net/projects/manjarodev/files/users/korrode/0.8.9-linux312/

See if that works and let us know. :)

If you need 3.13 or smth like that (in whatever DE) - ask the team, Rob and philm seem to be most active on the forums.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: QtAndNice on 27. February 2014, 13:49:57
3.12 is the best choice for current hardware,
3.13 suffers from regressions when it comes to file systems due to the redesigned block layer
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 27. February 2014, 13:59:37
Which 3.13 ? Now, we have the 3.13.5, and it's less true.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Hertz on 27. February 2014, 14:07:09
Hi All,

I'm vote for the kernel 3.10 LTS because for me and my work it's the best solution, but if the community prefer the progress develop for 3.13.x  i adapt for it.   :)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 27. February 2014, 14:49:18
I'm vote for the kernel 3.10 LTS because for me and my work it's the best solution, but if the community prefer the progress develop for 3.13.x  i adapt for it.   :)
3.10 isn't going anywhere any time soon. Almost certainly it will be with us for 6+ months yet. :)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Hertz on 27. February 2014, 14:55:36
3.10 isn't going anywhere any time soon. Almost certainly it will be with us for 6+ months yet. :)

Hi Rob,

this is a very good notice,  :)

thanks very much.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: jaskerx on 27. February 2014, 15:15:29
I'm just wondering about the people with fairly new hardware that can't boot the install disk because the kernel is too old. But when they boot Arch or Antergos it works fine because they ship with the latest. Do you think new users would be lost or put off due to this? Granted this community is awesome and someone will spin you up a disk but isn't that kind of inconvenient for all? 
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 27. February 2014, 15:24:15
I'm just wondering about the people with fairly new hardware that can't boot the install disk because the kernel is too old. But when they boot Arch or Antergos it works fine because they ship with the latest. Do you think new users would be lost or put off due to this? Granted this community is awesome and someone will spin you up a disk but isn't that kind of inconvenient for all?

Although not that easily findable for new users, i did put up a couple of ISO's using the 3.12 kernel.
https://sourceforge.net/projects/manjarodev/files/users/korrode/0.8.9-linux312/
Title: Re: Vote for your Kernel(s) to be kept!
Post by: d7rk on 27. February 2014, 15:30:19
Damn, 3.12 is my kernel and it's not part of the choice...

Is nvidia non-free drivers working with 3.13 now?

It's strange to see you named Rob Korrode...
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 27. February 2014, 15:33:39
whoawhoawhoawhoawhoa

I just looked at kernel.org (https://kernel.org/) and 3.12 has been picked up by a known & capable kernel dev (Jiri Slaby) for longterm support!

https://lkml.org/lkml/2014/2/26/596

Expect it to be around for a while. :D
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 27. February 2014, 15:38:23
I was there on kernel.org ago 15 ' and I have not noticed anything.  :o

Great news, thank you.  ;)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: jaskerx on 27. February 2014, 16:02:23
Does this mean that the next release will come with the 3.12 LTS kernel?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 27. February 2014, 17:36:03
Does this mean that the next release will come with the 3.12 LTS kernel?
Can't answer that until we start assessing kernel options closer to the next release, but it's certainly possible.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: SebastianB on 02. March 2014, 21:56:30
Hi, new manjaro user here.

Personally i have a laptop with a built in wifi thats pretty unreliable on anything above linux34, its a realtek card identifiying itself as some intel piece(i can get the lspci -nn -v entry if someone cares about the specifics).

So for what its worth i want to speak up that regressions are real(tm), i got first hand evidence of that.

Personally i like the 3.4 kernel, its a nice lower bound. The 3.10 is doing great aswell while i don't see much sense in running 3.8, SES or not. Can't imagine there being alot of new hardware/drivers in 3.8 that already have regressed in 3.10. Regarding non-LTS kernel i think it would be wise to have latest + latest-1. Personally i like lagging behind by one version on my desktop, that way people can skip the sometimes buggy single digit minors of a new kernel while still offering it for those that really want to be on he bleeding edge.

Ideal would be imho(referring https://www.kernel.org/):
1. Old LTS(3.4, skipping 2.6.32 since its EOL mid 2014) <-- Good for server
2. Second newest LTS(currently 3.10) <-- general purpose
3. Newest LTS(currently 3.12) <-- general purpose with recent hardware, good choice for install media imho
4. Stable -1(currently also 3.12) <-- trailing stable
5. Stable (currently 3.13) <-- Stable

Reason for 2. is same as for 4. LTS doesn't mean its stable right now, it means it gets support longer(and thus become more stable over time), a kernel can get that tag very early in its life.

P.S.: Kernel 3.11 is pointless imho. It has better hardware support on certain common hardware than 3.10, but not as good as 3.12. And if you don't have the specific hardware you might aswell run 3.10. I don't dislike canonicals kernel patches, but i don't see anything special about 3.8 and 3.11 either. Only reason Canonical runs support for them is because they happen to be the kernels that where out when they released their distribution majors. On the other hand im a little bit interested in the RH kernel patchsets, they port back more than security fixes and have longer support than Canonicals. Would be interested how their RHEL 2.6 kernel compares feature wise to the 3 LTS mentioned above ...

P.P.S.: BTW last time i used manjaro with a 3.8 kernel it broke btrfs support. I.e. the btrfs-progs in the manjaro repo created btrfs partitions that where not mountable with a 3.8 kernel, that was pretty nasty.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: jaskerx on 02. March 2014, 23:09:31
According to https://www.kernel.org/releases.html (https://www.kernel.org/releases.html) the 3.4 kernel is only supported until Oct 2014 so you have some time left. I'm curious to know how many kernels the devs want to support?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: SebastianB on 03. March 2014, 17:24:48
Actually im having some success(actually running perfect) with the recent 3.13 kernels. No loss of connection or weird slowdowns ... Im certain that kernels 3.8, 3.9, 3.10, 3.11 and 3.12 didn't work. Imho that only underscores the benefit of having a wide spread of kernels to choose from. There is little benefit in having f.e. a 3.8, 3.10 and 3.11 kernel, but a 3.4, 3.10 and 3.12/13/14 spread is likely going to turn out useful to atleast some people.

Out of curiosity, why is manjaro running kernel patchsets from Canonical, and not from Red Hat(Centos/Fedora), openSuSE, Gentoo or Debian? Just wondering wether there is a technical reason or they "just happened to patch the kernels we wanted to have patched anyway" kind of thing.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 03. March 2014, 17:39:00
Out of curiosity, why is manjaro running kernel patchsets from Canonical, and not from Red Hat(Centos/Fedora), openSuSE, Gentoo or Debian? Just wondering wether there is a technical reason or they "just happened to patch the kernels we wanted to have patched anyway" kind of thing.
That is basically it. We're certainly not against kernels maintained by the distros you mentioned.

Debian's 3.2 kernel doesn't seem necessary when we have the 3.4 series in such a mature state.
RHEL's 2.6.32 kernel i'm pretty sure will be too old for our userspace and simply won't work, plus i think the 3.4 kernel would be covering all use cases.
openSUSE's current Evergreen kernel is the 3.11 series, same as Canonical's current kernel
As for Gentoo, I'm not sure which kernels they maintain (I thought they were leading edge and didn't maintain kernels in-house). We do actually include some patches in our kernels that are sourced from Gentoo.


EDIT: Back on the 3.11 series; when Canonical drop it's support in a few months, we could look at using openSUSE patches, but it'll fast become hard to justify keeping it when the 2 kernel series on either side of it (3.10 and 3.12) are both 'official' (i.e. kernel upstream developers) LTS kernels. Presumably one of them will cover any use case.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: SebastianB on 03. March 2014, 18:55:17
That is basically it. We're certainly not against kernels maintained by the distros you mentioned.

Debian's 3.2 kernel doesn't seem necessary when we have the 3.4 series in such a mature state.
RHEL's 2.6.32 kernel i'm pretty sure will be too old for our userspace and simply won't work, plus i think the 3.4 kernel would be covering all use cases.
openSUSE's current Evergreen kernel is the 3.11 series, same as Canonical's current kernel
As for Gentoo, I'm not sure which kernels they maintain (I thought they were leading edge and didn't maintain kernels in-house). We do actually include some patches in our kernels that are sourced from Gentoo.


EDIT: Back on the 3.11 series; when Canonical drop it's support in a few months, we could look at using openSUSE patches, but it'll fast become hard to justify keeping it when the 2 kernel series on either side of it (3.10 and 3.12) are both 'official' (i.e. kernel upstream developers) LTS kernels. Presumably one of them will cover any use case.

Oh i think you might be surprised about Red Hats 2.6.32 kernel. http://lwn.net/Articles/486304/ is a rather old article about it, but even back then it already had over 7700 patches applied to it. And it got pretty recent hardware support including backported btrfs, CFS scheduler etc. And they will continue backporting hardware and drivers till 2016 for it and security till atleast 2020 or 2023(https://access.redhat.com/site/support/policy/updates/errata/). Now im not saying i want to run that thing on manjaro but you have to admit that what they are doing is pretty interesting from a technical pov(and afaik noone else is doing it that way), and RHEL 7 with a recent kernel is right around the corner. Also that live patching of a running kernel they are talking about ...

But i digress, you are all doing an awesome job with manjaro. It not only runs beautifully, it actually has a pretty smart design behind it and i actually prefer it over arch, and not for the installation but actual day-to-day features like mhwd, the multiple kernel choices and having packages rolling through stable/testing/unstable repositories.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 03. March 2014, 23:12:18
Oh i think you might be surprised about Red Hats 2.6.32 kernel. http://lwn.net/Articles/486304/ is a rather old article about it, but even back then it already had over 7700 patches applied to it. And it got pretty recent hardware support including backported btrfs, CFS scheduler etc. And they will continue backporting hardware and drivers till 2016 for it and security till atleast 2020 or 2023(https://access.redhat.com/site/support/policy/updates/errata/). Now im not saying i want to run that thing on manjaro but you have to admit that what they are doing is pretty interesting from a technical pov(and afaik noone else is doing it that way)
It is interesting I agree, but I fear systemd wouldn't want to run on it. Red Hat don't use systemd in their 6.5 release.

Quote
At a minimum, you need 2.6.36 for the cgroup API FS mounted at /sys/fs/cgroup
Source: https://bbs.archlinux.org/viewtopic.php?pid=913573#p913573
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Ace on 08. March 2014, 04:45:58
Please keep 3.11. Since the most recent catalyst drivers, it is the most stable with accelerated video.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: mardt on 13. March 2014, 14:59:42
Minimum 3.11 on 3.10 my lan on hp 7800p dont work intel e1000e on 3.11 and up work like a charm
Title: Re: Vote for your Kernel(s) to be kept!
Post by: salome on 19. March 2014, 15:27:55
Mantain kernels 3.10, 3.12 and 3.13 series, drop 3.4 and 3.11 (3.8 is already dropped in testing).

and maybe, you could set zram and zswap by default (but I don't remember if 3.10 series support zswap)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: jmartins on 19. March 2014, 16:15:02

My sugestion is mantain only one version below the kernel current version and the new manjaro releases always use the current kernel.org version

And set zram and zswap by default.

regards,
Joao


Title: Re: Vote for your Kernel(s) to be kept!
Post by: jmartins on 20. March 2014, 14:09:01

Another suggestion is use the https://gnunet.org/cryogenic

regard,
João
Title: Re: Vote for your Kernel(s) to be kept!
Post by: kike1965 on 20. March 2014, 16:49:20
Done, linux310  ;)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: rudefyet on 21. March 2014, 19:39:14
I absolutely need 3.10 for now. 3.12+ causes data corruption on my system.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: LCJr on 21. March 2014, 20:08:39
Could we get 2.6 or a little earlier so I can run Manjaro on my AMD K6-2?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 22. March 2014, 00:44:57
I absolutely need 3.10 for now. 3.12+ causes data corruption on my system.
3.10 isn't going anywhere anytime soon. :)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: gfgraham on 22. March 2014, 02:15:38
3.10 + 3.13 because I use them. Also selected 3.4 for some unknown reason....nostalgia maybe?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 22. March 2014, 11:08:12
Yep, but the3.12 is  missing in this poll. As it is the last LTS, it's a very good choice.  :)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: rikkinho on 01. April 2014, 06:32:43
linux 3.13 is no more a option
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 01. April 2014, 06:36:02
linux 3.13 is no more a option

3.13 will probably still get a few more point releases, but yes, 3.14 is now out and 3.13 will be EOL'd in the not too distant future.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Verändert2.0 on 01. April 2014, 07:30:05
The newest and the latest stable- i think that's the way to go anyway.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 01. April 2014, 07:37:21
3.13 will probably still get a few more point releases, but yes, 3.14 is now out and 3.13 will be EOL'd in the not too distant future.

Actually there is this factor:
http://www.phoronix.com/scan.php?page=news_item&px=MTY0NTc

Canonical might maintain 3.13 for a little while when kernel upstream stops. Though the article does say that, unlike in earlier Ubuntu LTS's, the kernel may get an upstream version bump during the life of the LTS release.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Verändert2.0 on 01. April 2014, 07:41:55
Yes, but do we want to depend on Ubuntu ?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 01. April 2014, 07:42:42
Yes, but do we want to depend on Ubuntu ?

Only if the 3.13 series offers something other kernels don't ;)

With a lot of changes happening around the free AMD/radeon driver currently, i wouldn't be too quick to throw out modern kernels.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: ruziel on 01. April 2014, 08:43:16
Is it possibly time to start this pole afresh? Given the information that's coming to light, I would no longer vote for 3.13 & am wondering where the 3.12 option is, if in fact it's an LTS kernel.

If so, maybe someone should start a new pole, provide a link @ the top of this & freeze the post.

Just a thought.

Ruziel  ;)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 01. April 2014, 09:19:13
The 3.13 is a bit missed, but it's the current kernel. I wait for the 3.14.  :)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Enindu on 01. April 2014, 09:34:06
Latest kernel [3.14], latest kernel in Manjaro [3.13] and latest LTS kernel [3.12] should keep..  :)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 01. April 2014, 09:37:34
Latest kernel [3.14], latest kernel in Manjaro [3.13] and latest LTS kernel [3.12] should keep..  :)

Yep. Latest current kernel and latest LTS kernel.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 01. April 2014, 09:58:52
Guys the 3.12 kernel has had only 15 point releases and is not a GKH maintained LTS
i.e. not the usual kernel.org guy who manages the main LTS kernels - it's life cycle could be unpredictable (though i admit with it's seeming inclusion in SLES 12, it should be around for years).

3.10 is GKH maintained and is 35 point releases deep. I currently get at least some form of performance or stability regression (albeit minor) when i goto any other kernel and i can find recent examples on these forums of people stating anything later than 3.10 has problems for them.

We can't just have a blind policy of "Latest mainline and latest LTS".
We need to keep some highly stable kernel around. Note we only dropped the 3.4 LTS series recently, which was originally released almost 2 years ago.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: rikkinho on 01. April 2014, 10:22:56
3.11 is patched and validated for the purposes of Canonical, not for those of Arch.

And for the team of Linus, it's EOL.

Do we have the same patches than Canonical ?

most of the patchs by canonical are backports from new kernels. "their" 3.13 is a example of this, they backport all intel patchs from 3.14rcs because the future intel cpu/gpu.

i don t see the point of the kernel 3.8 or 3.11 right now 3.4(some people need it because of old amd cards), 3.10(because is a lts), 3.13 (i hate it but ok) and 3.14(last one who already has better performance than 3.13)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Verändert2.0 on 01. April 2014, 11:10:33
@Rob: Sorry- i was thinking of the 3.10 kernel as the stable one to keep. And i´m quite sure we won´t switch to 3.14 yet, are we ?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: ruziel on 01. April 2014, 11:14:17
Do we have any visibility of when 3.14 might find it's way into the stable repository? It would be great when non-testing users can start kicking it's tyres. Meantime, I have no doubt that the dev team will make the right call.

All in good time.

R  ;)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 01. April 2014, 12:08:44
@Rob: Sorry- i was thinking of the 3.10 kernel as the stable one to keep. And i´m quite sure we won´t switch to 3.14 yet, are we ?

All good, i was mainly responding to Enindu & Esclapion

As for 3.14, i'm sure Phil will introduce it as an option soon (as it is now officially released), but we won't "switch" to it no. (i.e. not use it for ISO's and not generally recommend it, yet.)

EDIT: One reason Phil may not yet have looked at 3.14 could be because Arch hasn't either.
Considering Arch still does some patching to 3.13, he might be waiting to see what they come up with for 3.14 before we even start on it.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: ruziel on 01. April 2014, 12:12:18
Rob, thanks - I look forward to giving “shuffling zombie juror” a try, once Phil has dropped it into stable.

Upwards.

R.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 01. April 2014, 12:15:55
Rob, thanks - I look forward to giving “shuffling zombie juror” a try, once Phil has dropped it into stable.

Upwards.

R.
(editied my last post with another comment too)

I'm pretty strongly considering setting up 3.14 PKGBUILD myself right now just for teh lols (and save Phil some time)... but yeah as i say in my last posts' edit, probably better to just wait for Arch.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: ruziel on 01. April 2014, 12:24:38
Rob.

Thanks. I see that 3.14 looks to deal with "buffer bloat", that can affect VOIP etc. I don't know if that will improve Skype call quality for example, but it sounds promising.

It's great to know you're part of the crew - we've got a wonderful dev & test team @ Manjaro.

Hats off all round!

R.

Title: Re: Vote for your Kernel(s) to be kept!
Post by: ruziel on 01. April 2014, 12:28:51
Just in case anyone is getting bored with all the talk about 3.14, check out what's in store for 3.15 via this Ars! Technica article:

http://arstechnica.com/information-technology/2014/03/new-linux-version-will-reduce-suspend-and-resume-times/

Never a dull moment.

R.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 01. April 2014, 12:34:54
So i started setting up a fairly vanilla 3.14 PKGBUILD, including only the minimal Manjaro patchwork.

BFQ patches = already released for 3.14
aufs patches = no 3.14 support yet ( http://aufs.sourceforge.net/ )

So at the least we have to wait for that, before it can be a proper Manjaro kernel.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 01. April 2014, 15:23:02
A silly question, but why do we need AUFS ?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 01. April 2014, 15:23:26
A silly question, but why do we need AUFS ?
ManjaroISO.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 01. April 2014, 15:25:24
ManjaroISO.

Ah, OK, thanks. So, we need it absolutely.  :D
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 01. April 2014, 15:28:43
So, we need it absolutely.  :D
Indeed. :)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: FutureSuture on 01. April 2014, 19:48:04
All good, i was mainly responding to Enindu & Esclapion

As for 3.14, i'm sure Phil will introduce it as an option soon (as it is now officially released), but we won't "switch" to it no. (i.e. not use it for ISO's and not generally recommend it, yet.)

EDIT: One reason Phil may not yet have looked at 3.14 could be because Arch hasn't either.
Considering Arch still does some patching to 3.13, he might be waiting to see what they come up with for 3.14 before we even start on it.
That is absolutely terrible in my case as I need Linux 3.13 at the minimum to even be able to boot. Linux 3.14 would finally allow me to game on my new AMD GPU. It's been over a month and I am suffering severe withdrawal! It would also help if ManjaroISO actually worked for me. (http://forum.manjaro.org/index.php?topic=11960.msg109060#msg109060) I am at a point where I will donate 50€ to Manjaro if I can finally get ManjaroISO to create a working ISO file with Linux 3.13 or even Linux 3.14 and everything else I need working too, all via a live USB stick. Speeding up getting Linux 3.14 on Manjaro should be in there as well.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: neonr4in on 23. April 2014, 12:04:39
I prefer 3.13, because its stability on my system  :D
Title: Re: Vote for your Kernel(s) to be kept!
Post by: mxx on 23. April 2014, 12:21:53
3.12 is not even an option? What will happen to linux312-netbook package?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 23. April 2014, 12:29:19
When this poll has been done, the 3.12 was not LTS.

Now, the 3.12 is the default kernel chosen for the future Manjaro 0.8.10.

So, sure, it remains. And for a long time.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 23. April 2014, 13:46:45
3.12 is not even an option? What will happen to linux312-netbook package?

The linux312-netbook package is not in the official repos, i provide it in a separate repo for the Netbook edition.
Many Netbook edition packages have already been included in the official repos, however the netbook kernel is not one of them, for now i plan to continue to provide that via an additional repo.
linux312-netbook will continue to be used for the 0.8.10 Netbook edition release, so it will be updated to the latest 3.12 point release, and is not going anywhere any time soon.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Enindu on 23. April 2014, 19:23:07
Is not Linux313 kernel series expired? [http://kernel.org (http://kernel.org)] Are we going to keep it?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: FadeMind on 23. April 2014, 19:27:15
Is not Linux313 kernel series expired? [http://kernel.org (http://kernel.org)] Are we going to keep it?

You're right. Today was released lastest update for 3.13.x series: 3.13.11 [EOL](now available in Manjaro unstable repository)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: philm on 23. April 2014, 19:47:09
For some the SES series by Canonical and LTS series by upstream is not clear. LTS series will be maintained by Greg K. Hartman from the Linux Foundation. Canonical will do the same with their SES series. SES series is based on LTS patches. So the Ubuntu Kernel Team will do the same as kernel maintainers of Linux Foundation. Kernel releases for Ubuntu will get extra patches needed by Canonical. So Canonicals SES series is also a vanilla kernel. We will patch our own patches also to those kernels to make our kernels work for Manjaro. So every Manjaro kernel is tested by us and especially designed to work with Manjaro.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: FadeMind on 23. April 2014, 20:02:26
3.13 will be updated like 3.8?
So, what will be with 3.12 LTS? Why is not available on vote list?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: ohrenkamen on 23. April 2014, 20:42:46
https://www.kernel.org/category/releases.html

LTS kernels.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: wolfyrion on 24. April 2014, 12:51:16
i dont know if that is a placebo but I feel that with 3.12.x kernel my system is snappier , more responsive etc....
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 24. April 2014, 12:58:59
i dont know if that is a placebo but I feel that with 3.12.x kernel my system is snappier , more responsive etc....

Vs 3.10 or 3.13 ?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: wolfyrion on 24. April 2014, 13:13:49
Vs 3.10 or 3.13 ?

Vs ALL 

Just waiting for Kernel 3.15.........

btw we have to wait until final release or there is a chance to get an RC taste of 3.15 kernel on unstable repos?  ::)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: salome on 24. April 2014, 15:22:50
Hi,

i totice some things:
- there isn't kernel 3.12 series in the pool...why not?
- the 3.13.11 kernel is now an EOL
- there is not kernel 3.15 yet

So I think the best choice is remove the 13.11 and 13.13 EOL versions and replace them with 3.12  and 3.15 (when it will be ready)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: ruziel on 24. April 2014, 15:37:59
Personally I think this pole should be frozen & an updated one started. The absence of 3.12 (and 3.14 being added only recently) means that it currently has only limited relevancy.

More power to u all.

Ruziel  ;)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: donutello on 24. April 2014, 15:40:58
- the 3.13.11 kernel is now an EOL
- there is not kernel 3.15 yet

The Ubuntu kernel team has picked up support for 3.13, giving extended support. http://www.phoronix.com/scan.php?page=news_item&px=MTY3MTU (http://www.phoronix.com/scan.php?page=news_item&px=MTY3MTU)

3.15 is still rc2, so might be a while before we see it.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: darso on 19. June 2014, 03:08:06
Hi guys, had a wee look at this post a few weeks ago.  Didn't understand it much then and have only a little more understanding of it now.

You guys really a bunch of good guys and I am very proud to even be part of Manjaro in any way, even as just a user of this great os.  Over the past few weeks I have messed about with packages and different things, learned to install kernels and applications and change drivers from free to non-free and edit config files and have loved every minute of it, even after all the re-installs and hair pulling antics lol

After reading every reply and quote and message my head is completely buzzing but it was soooooo worth the late night.  I finally decided to make my vote and opted for:
310LTS for older systems and also I found it so very stable in Manjaro 0.8.9,
312LTS because from I installed the new 8.1.0 with 312 default my system is running beautiful again, even with a windoze dual boot,
314 because 315 isn't included yet but if 316 or 317 was on the poll I would vote for them because things must and always will change.

Thanks to you for all the hard work you put in to make such an excellent os and for the support and kind way this is given, cheers guys.

Darin. (Happy Manjaro User) ;D
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Growlboy on 23. June 2014, 11:42:44
3.10 Perfectly work on my Dell D420.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: coolthingy450 on 03. July 2014, 04:30:36
Not a fan of Ubuntu kernels since I had to remove one on Ubuntu 13.04 and installed a LTS kernel to get past the buggy mess that was occurring with Unity. Ex: Firefox. Minimizing and unminizing, sometimes the whole DE crashes. Updating on Ubuntu systems are a joke, and I would rather use the yumex package manager on whatever fedora based distros over apt-get on Ubuntu. With Debain I don't have to constantly worry about devs rebuilding their DE entirely when it starts to work well at almost every LTS release. I trust the Manjaro devs way more then the Canonicals, because at the very least, you get somewhere. It's why I'm not using 3.13 anymore.

I'm not bashing the users for using Ubuntu. Just the Canonicals devs themselves.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: coolthingy450 on 03. July 2014, 04:32:06
As of now. 3.14 kernel is working very good. 3.10 is a little old, but reliable since I had little issues with it so far.

Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 04. July 2014, 10:47:59
http://lwn.net/Articles/604283/

Quote
I'm going to be maintaining the 3.14 kernel as a "longterm" kernel for
the next two years, so mention that on the kernel.org site.

Signed-off-by: Greg Kroah-Hartman
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Verändert2.0 on 04. July 2014, 11:08:18
So- we have a winner ?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 04. July 2014, 11:17:20
Now, the 3.14 is LTS. So, if we did this poll again, the results would be different.  ;)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Verändert2.0 on 04. July 2014, 11:34:04
That's why i suggested picking 3.14 as the winner  8)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Lukimya on 04. July 2014, 11:42:40
im curious to know in what time frame this poll will leed to action anyhow  ::)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: philm on 05. July 2014, 09:34:09
Here is the current vote:

Code: [Select]
Linux 3.4 LTS series    35 (6.9%)
Linux 3.8 SES series (maintained by Canonical)    5 (1%)
Linux 3.10 LTS series         174 (34.3%)
Linux 3.11 SES series (maintained by Canonical)  35 (6.9%)
Linux 3.13 SES series (maintained by Canonical) 187 (36.8%)
Linux 3.14 LTS series          56 (11%)
Linux 3.12 LTS series                            16 (3.1%)

Zeroed it out so we can start fresh. Please vote again so we get a current result.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: philm on 05. July 2014, 09:37:06
im curious to know in what time frame this poll will leed to action anyhow  ::)

This poll is just an index for me. It helps me to keep old kernels in Manjaro if still needed.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: FadeMind on 05. July 2014, 09:53:32
The safe solution IMO is provide 3.4 LTS kernel for the OLDER device working and lastest STABLE LTS kernel 3.14 LTS. This safe lots of time and this is good compromise. In default OFC use 3.14 series :)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 05. July 2014, 10:28:51
Hi,

I voted for the two last LTS.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: philm on 05. July 2014, 11:01:05
With linux34 I've some issues currently. Last working kernel is 3.4.95. I've to check on Monday if 3.4.97 will boot up on i686. Otherwise I've to drop it. I also had to backport some stuff to get linux34 working with systemd higher than v212.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: [amended] on 12. July 2014, 00:15:45
Imho, I think the current lts kernels should be kept (3.{10,12,14}).  I think that the 3.4 lts may be getting a little too old, and with philm's problems, it might have to be dropped.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Seboss666 on 12. July 2014, 02:24:29
With other components updating against more recent kernels (systemd probably the biggest part), maintaining linux34 is going to get harder with time. Basically I'm not fond of Ubuntu-specific support for the kernel, as it's not automatically pushed into vanilla. I've checked 3.12 and 3.14. I could have checked 3.10 too, as if a manjaro user is not aware of changing its kernel, it may be still installed if he comes from 0.8.9 (it's the "snapshot" I migrated my laptop with).
Title: Re: Vote for your Kernel(s) to be kept!
Post by: raidermax on 15. July 2014, 19:29:03
A message for the devs, I believe that the latest AMD drivers (nonfree) do not support kernels past 3.13. I have been actually able to install the AMD driver (through mhwd of course) on kernels 3.14 and 3.15 and it works fine just for desktop use but gaming performance has decreased, specifically in the game Minecraft. I have not tested it with other games but if performance decreases on Minecraft it is most likely to decrease on other games as well unless there is some issue between OpenJDK and the kernel. So hopefully you guys can keep the 3.13 kernel a bit longer until AMD releases its next driver update that supports a higher kernel version. Thank you!
Title: Re: Vote for your Kernel(s) to be kept!
Post by: schpankme on 15. July 2014, 19:36:49
Where's the documentation to be found that describs the build difference betwen such kernels as 3.10 - 3.14 - 3.16 ?

On a tip from Rob, I've found that 3.10 preforms better in gaming.  I'm trying to understand why we have so many kernels and not one or two kernels with a code names, with revision history and updates.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: excalibur1234 on 15. July 2014, 19:41:40
since the last update, there is a new entry in your manjaro settings window: kernels.
there, you can find a nice text about what's new in each kernel...
Title: Re: Vote for your Kernel(s) to be kept!
Post by: schpankme on 15. July 2014, 19:52:41
Thx, I found the changlog for each kernel, very detailed as described.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 15. July 2014, 20:24:00
On a tip from Rob, I've found that 3.10 preforms better in gaming.

To clarify, if someone runs one of the proprietary graphics card drivers, they get newer graphics driver module on their older kernel.
If they use an in-kernel free driver, performance enhancements will (virtually always) only come from newer series of kernel.

Thus, nvidia and catalyst uses even more than others should just use whichever kernel (that is still getting security updates (https://kernel.org/category/releases.html)) works best for them.

Everyone should just use whichever kernel they find works best, but proprietary driver users have even less incentive to use newer kernel series.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Maplewood on 06. August 2014, 21:25:48
I'm a bit suprised that 3.14 got so many votes?
https://forum.manjaro.org/index.php?topic=15518.msg144194#msg144194
http://www.phoronix.com/scan.php?page=article&item=linux_314_ultrabook&num=2
It has been seriously improved/updated in the last few months?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: philm on 14. August 2014, 12:50:10
This is the current vote result:

Code: [Select]
Linux 3.4 LTS series      2 (2.2%)
Linux 3.8 SES series  (maintained by Canonical)      0 (0%)
Linux 3.10 LTS series     14 (15.7%)
Linux 3.11 SES series (maintained by Canonical)      1 (1.1%)
Linux 3.13 SES series (maintained by Canonical)      4 (4.5%)
Linux 3.14 LTS series     47 (52.8%)
Linux 3.12 LTS series     21 (23.6%)

time for another reset.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Seboss666 on 14. August 2014, 18:12:59
Done :)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 14. August 2014, 19:05:40
Also. What's funny is that the users retain only the even numbers : 3.10, 3.12, 3.14.

And the 3.8 serves to nothing...  ;)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: dicktater on 14. August 2014, 19:11:58
And the 3.8 serves to nothing... 
All is well then, because 3.8 is getting dropped soon anyway.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Seboss666 on 14. August 2014, 22:52:01
3.8 is already dropped at kernel.org. Following security/bugfix updates will just get harder with time going. So keeping it is not necesary a good thing.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: kertase on 14. September 2014, 17:01:16
I am for keeping all lts as long they are supported...

The rest can be dropped if not specially needed by some hardware
Title: Re: Vote for your Kernel(s) to be kept!
Post by: knifewing on 14. September 2014, 21:06:48
I would very much like to see a Manjaro kernel patched with grsecurity in the "kernel" section of "Manjaro setting manager" that I can just click, install and run. I know this is linux and security isn't a top concern for most people, but security is important and will only become more so as time goes on. there's a reason why gentoo hardened project, grsecurity, apparmor and SELinux exist.

I've tried manually editing the PKGBUILD file of the Manjaro package core source code to patch with grsecurity but it doesn't take and I think there are other modifications to the Manjaro kernel that need to be made for it to work. I think this because I downloaded the PKGBUILD file of this arch grsecurity kernel from the AUR https://www.archlinux.org/packages/community/x86_64/linux-grsec/ and compared it with the Manjaro kernel PKGBUILD file from the source code on github and made the appropriate alterations ie just adding all the grsecurity stuff that was in the arch kernel PKGBUILDER to the manjaro kernel PKGBUILDER but this didn't work so I assume there are other alterations that need to be made to the manjaro kernel so that nothing conflicts with the grsecurity patch causing the kernel building and installation process to abort.

if there is a way I can just run the arch grsec kernel with a manjaro OS frontend that would be nice too.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: schpankme on 14. September 2014, 21:09:44
What will "grsecurity" prevent on your system?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: raidermax on 22. September 2014, 03:08:13
I think a few months ago I posted asking about keeping the 3.13 series because of how gaming performance on 3.14 and 3.15 with the closed source AMD drivers were very bad. I believe a few agreed with me and so I would just like to put out an update, the 3.16 kernel works with AMD's drivers just fine.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: CyberWolf2k14 on 22. September 2014, 05:36:57
I like the 3.11 kernel, simply because it works perfectly with my system.
The initial kernel when I installed 0.8.10 was 3.12.20, and as soon as the next kernel update happened, machine stopped working.
I also like the 3.10 simply because if 3.11 is no longer available (say if I had to resinstall from scratch) the 3.10 would literally be my ONLY option to be able to still use Manjaro.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: excalibur1234 on 22. September 2014, 12:57:50
What will "grsecurity" prevent on your system?
here is a link for further reading: https://wiki.archlinux.org/index.php/Grsecurity
Title: Re: Vote for your Kernel(s) to be kept!
Post by: philm on 22. September 2014, 14:22:11
As we have now linux38 and linux311 removed the poll has also to been updated. Here the current votes:

Code: [Select]
Linux 3.8 SES series (maintained by Canonical)      0 (0%)
Linux 3.10 LTS series     12 (13%)
Linux 3.11 SES series (maintained by Canonical)      1 (1.1%)
Linux 3.12 LTS series     21 (22.8%)
Linux 3.13 SES series (maintained by Canonical)      5 (5.4%)
Linux 3.14 LTS series     53 (57.6%)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: grandadruss on 28. September 2014, 05:29:59
Voted for 3.12 and 3.14
3.12 from initial install, works great, no problems.
3.14 just installed just for fun, also works great, no problems.

Extra info - 3.16 just installed in Sparky[Deb. Testing], also working fine.

Conclusion - any of those fine with me!  :)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: rcrath on 03. November 2014, 05:24:54
3.12-3.13 break bluetooth apple magic trackpad support.  fixed mostly (name is still missing) in 3.14
Title: Re: Vote for your Kernel(s) to be kept!
Post by: CyberWolf2k14 on 08. November 2014, 03:36:54
I will now have to vote a BIG thumbs up for 3.10.
I recently installed 3.10 and removed 3.11, and it runs VERY smoothly.

I have also tried (just for the chuckles) and installed the latest 3.12 and that did NOT go over very well with this machine at all.
It would boot a little ways in and then reboot. NEVER got back in. So, at GRUB had to select 3,10 and got back in and removed 3.12 promptly.

And since the lowly 3.12 is basically not going to work, I can safely assume the NEWER kernels (>3.12) will DEFINITELY NOT WORK either.
So, once 3.10 is retired, I will have to stay at 3.10 for as long as possible since it is now the last version to work with this machine.

In all actuality, only ONE version of the 3.12 line actually worked, that was 3.12.20 the one originally installed by the Manjaro 0.8.10 Xfce DVD. That tho lasted until the very first update which took it to 3.12.28 and then it died.

So, yeah, 3.10.x will be as far as I can go with kernels now. Unless I receive a bloody HUGE miracle and fall into some cash to get newer equipment (much newqer prefer) that is.

OK, sorry for that, rant officially over.  ^-^ 8) O:-)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: skeevy420 on 12. November 2014, 01:32:11
I was going to vote for 3.16 or 3.17, but neither are choices  :(. 

Both give me increased performance with the free Radeon driver, with 3.17 being good enough to play games with Wine.  I'm unable to reliably run the Catalyst driver for more than a few hours before my system locks up and I have to do a forced reboot.  Don't worry, this isn't a Manjaro issue, happens with every Catalyst driver I've used on Windows and Linux.  GPU is an R7 260x if anyone is curious.

Do the Manjaro kernel devs backport the free GPU drivers into the LTS kernels like 3.14?  My Catalyst crashes are why I'm asking...if not, no biggie since I don't have any issues with 3.17 or the AUR's linux-mainline for 3.18rc3 (used once for testing; didn't feel like dealing with ZFS modules and breaking MHWD to run an RC kernel full time).

Here's to hoping 3.18 leaves RC status so we can start using that (and Mesa 10.4 and LLVM 3.6).  Gallium3D Nine (http://www.phoronix.com/scan.php?page=news_item&px=MTgyOTI) is looking to be pretty interesting.  The next year is looking to be a good year for open source Radeon and AMD driver users on Linux.

Keep up the good work.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Seboss666 on 12. November 2014, 10:18:44
Kernels are not modified as far as I know. Arch, and so Manjaro have a philosophy to make the least modifications they can. They use almost only upstream packages.

You can always keep the installed kernel after it has been "EOLed", it's not that a problem if it runs without hickups for you. The only problem that remains when you do so is potential security flaws that would not get corrected. It's not that usual though.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: flippy on 12. November 2014, 10:58:13
Kernels are not modified as far as I know. Arch, and so Manjaro have a philosophy to make the least modifications they can. They use almost only upstream packages.

You can always keep the installed kernel after it has been "EOLed", it's not that a problem if it runs without hickups for you. The only problem that remains when you do so is potential security flaws that would not get corrected. It's not that usual though.
No there some modified. Even Rob was talking about how manjaro kernel are a little bit different then arch on Linux Action Show.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: FutureSuture on 14. November 2014, 04:40:14
Wouldn't it save a ton of work to just provide the latest longterm and stable kernel? What speaks against this?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 14. November 2014, 04:50:57
Wouldn't it save a ton of work to just provide the latest longterm and stable kernel? What speaks against this?
What speaks against it is the users who's hardware doesn't work on either of those kernels.
What you propose would have us providing only 3.14 and 3.17 series currently. You can find many examples around the forums of people claiming neither of those work for them.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: FutureSuture on 14. November 2014, 05:34:14
What speaks against it is the users who's hardware doesn't work on either of those kernels.
What you propose would have us providing only 3.14 and 3.17 series currently. You can find many examples around the forums of people claiming neither of those work for them.
Thank you for the explanation. That seems really odd considering how Linus does his best not to break things from one release to the next from what I remember. What will those users do once their current kernel is deprecated?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 14. November 2014, 06:28:20
That seems really odd considering how Linus does his best not to break things from one release to the next from what I remember.
The user-space API never breaks, this doesn't include hardware drivers.

What will those users do once their current kernel is deprecated?
They hope that before their kernel series is deprecated some newer series starts working for them (so, within 10 months from now for 3.10.x users, longer for 3.12.x users)

If capable they can compile the kernel from vanilla sources and then are eligible to submit bug reports upstream.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Seboss666 on 14. November 2014, 11:52:16
Even if they don't "modify" certain drivers, between releases it happens it breaks, because some other sub-system has been modified. Furthermore, they don't necesarily test all hardware with each kernel series, and sometimes, glitches can occur without being noticed because of that (I had a pretty bad experience with suspend and resume for Intel GMA4500HD and 3.15 series).
Title: Re: Vote for your Kernel(s) to be kept!
Post by: gerstavros on 17. November 2014, 13:45:06
I have no problem in manjaro with 3.14 kernel, just better performance from past 3.10 that i was using.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: philm on 09. December 2014, 23:53:22
Another stable release so we have to update this poll. Here for documentation:
Code: [Select]
Linux 3.10 LTS series 14 (12.4%)
Linux 3.12 LTS series 30 (26.5%)
Linux 3.13 SES series 4  (3.5%)
Linux 3.14 LTS series 58 (51.3%)
Linux 3.15 (EOL) 7  (6.2%)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Seboss666 on 10. December 2014, 18:24:44
I voted for three series : 3.10 for "legacy" hardware that may not work with newer kernels, 3.14 for rock-solid, circa four years hardware, and 3.18 (don't know yet the eventual LTS status of it), for bleeding edge hardware (especially graphic cards, needing the last DRM for running well).
Title: Re: Vote for your Kernel(s) to be kept!
Post by: azadian on 03. January 2015, 15:47:48
For me, anything past 3.12 hangs during boot. :-(
Title: Re: Vote for your Kernel(s) to be kept!
Post by: fennectech on 14. January 2015, 03:09:48
Currently 3.18 is not usable for me so i voting for 3.17     im waiting for an update to 3.18 to fix the bug then i can vote for it
Title: Re: Vote for your Kernel(s) to be kept!
Post by: QtAndNice on 18. January 2015, 22:01:02
to all of you having problems with your kernels, don't forget to file a bug report, also don't forget to doublecheck if the same bug has been reported allready
Title: Re: Vote for your Kernel(s) to be kept!
Post by: nburgin on 22. January 2015, 08:17:31
I happen to be using 3.10 but could probably upgrade to anything not higher than 3.17, the highest supported by my graphics card. However 3.10 is supported upstream at kernel.org until next September though, so continuing support until then is probably one of the easier options you could pick to keep supporting, without having to assemble 3rd party maintenance patches. Just my 2 cents.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Charles LaHaine on 23. January 2015, 13:12:08
Currently, kernel 3.18 + Intel driver 2.99.917 = System hangs, so voting for 3.17
Title: Re: Vote for your Kernel(s) to be kept!
Post by: ruziel on 23. January 2015, 14:21:15
While a lot of Manjaro users like having a relatively leading edge OS, I hope we keep 3.10 supported for as long as possible, to avoid disqualifying people who's machine doesn't work that well with the newer kernels.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Seboss666 on 23. January 2015, 16:14:45
Getting the last version of your DE is not incompatible with using a kernel that suits your hardware well. As long as the kernel is "supported", it's not a problem.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Charles LaHaine on 29. January 2015, 12:31:30
Quote
Currently, kernel 3.18 + Intel driver 2.99.917 = System hangs, so voting for 3.17

In fact, I would've voted for 3.16 if it managed backlight brightness as well as 3.17 does, i.e. min brightness doesn't turn screen off.
If only that feature was backported to 3.16. :-\

P.S. I also think you should keep supporting 3.10 for HW compatibility reasons.

EDIT: As someone else pointed out, following kernels should keep everybody happy:
Title: Re: Vote for your Kernel(s) to be kept!
Post by: wojciechkrs on 30. January 2015, 18:43:01
3.17. 3.18 hangs after GRUB randomly. ;/
Title: Re: Vote for your Kernel(s) to be kept!
Post by: geolab on 19. February 2015, 20:13:00
a question.. there is no more linux-lts after 3.14? I see a 3.10lts, 3.12lts 3.14lts then anything more after that. why? is there a rule o determine the new lts kernel or what?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Seboss666 on 19. February 2015, 22:27:11
the LTS status of the kernel is decided by the kernel developers themselves. Sometimes Manjaro adds some kernels that are maintained by some distributions (like Ubuntu), and that's all. When a kernel is definitely abandoned by the teams of the distributions, or the kernel developers themselves, it is also deprecated by Manjaro.

The 3.16 series will be maintained for a while, as Debian has planned to use the 3.16 series.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 20. February 2015, 03:09:06
You can view the current kernel.org maintained LTS kernels here:
https://www.kernel.org/category/releases.html

As Seboss666 mentioned, some kernels get maintained by others.
3.16 can be considered 'LTS'.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: schpankme on 11. March 2015, 02:18:10
Can we get the "linux-grsec" package added to the Repo to provide for "grsecurity hardened kernel"?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 11. March 2015, 02:19:52
Can we get the "linux-grsec" package added to the Repo to provide for "grsecurity hardened kernel"?

No.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: FadeMind on 16. March 2015, 16:53:02
3.18 is now LTS  EOL Jan, 2017 8)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Lukimya on 16. March 2015, 16:56:59
3.18 is now LTS  EOL Jan, 2017 8)

Great news. 3.18 has proven to be reliable. Now I can remove 3.16
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 16. March 2015, 17:00:49
3.18 is now LTS  EOL Jan, 2017 8)

Nice.

This'll likely be the kernel used on 0.9.0 final media, then.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 16. March 2015, 17:17:58
3.18 is now LTS  EOL Jan, 2017 8)

A good new !  ^-^
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Seboss666 on 16. March 2015, 20:17:02
I may give it a try then, even if I don't expect big move with my 7yo laptop :D
Title: Re: Vote for your Kernel(s) to be kept!
Post by: philm on 17. March 2015, 18:51:52
Another snapshot of our votes:
Code: [Select]
Linux 3.10 LTS series 28 (9.9%)
Linux 3.12 LTS series (maintained by Suse) 25 (8.9%)
Linux 3.13 SES series (maintained by Canonical) 3 (1.1%)
Linux 3.14 LTS series 65 (23%)
Linux 3.16 SES series (maintained by Canonical) 54 (19.1%)
Linux 3.17 25 (8.9%)
Linux 3.18 LTS series 82 (29.1%)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 17. March 2015, 18:58:44
I vote 3.18, it's not a surprise.   ;D
Title: Re: Vote for your Kernel(s) to be kept!
Post by: eduardo on 17. March 2015, 19:01:45
For me, anything past 3.12 hangs during boot. :-(
Same for me after kernel 3.17. Is this something we have to live with? This seems to be a new trend of the kernel, to break compatibility with old hardware.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Seboss666 on 17. March 2015, 19:32:43
I'll keep my vote until I test 3.18 for a few days/week on my machine. Be sure I'll continue to select 3.14 as well, see how well it works on it.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: exploder on 17. March 2015, 19:40:11
The 3.14 kernel worked best on my HP 655 laptop. I am running the 3.19 kernel on my 7 year old Compaq desktop.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: schpankme on 17. March 2015, 20:31:52
Linux 3.10.x LTS series
Linux 3.14.x LTS series
Linux 3.18.x LTS series

Easy decision.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: yaoweizhen on 22. March 2015, 23:14:33
Always get this message when system booting.

[FAILED] Failed to start Load/Save Screen Backlight Brightness of backlight

Tried different versions of kernel and ways to fix that, no lucky, only 3.14 works for me.

My computer is HP Pavillion 23, all-in-one desktop PC, and AMD Radeon display card.

Title: Re: Vote for your Kernel(s) to be kept!
Post by: schpankme on 22. March 2015, 23:30:27
You can remove "xorg-xbacklight".
Code: [Select]
sudo pacman -Rns xorg-xbacklight
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Seboss666 on 28. March 2015, 12:06:01
I have tested the 3.18 series on my old laptop, without a hitch for now. So I've included it in my vote, as well as 314 and 310. I still vote for this "old" dude because it can work better than more recent series on very old hardware (more than 8 years). But I'm not sure how long it will work flawlessly with systemd focusing on recent series.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: philm on 19. April 2015, 23:50:14
With the latest vote-result nobody is using linux313. What changed?

Code: [Select]
Linux 3.10 LTS series               6 (4.9%)
Linux 3.12 LTS series (maintained by Suse)     5 (4.1%)
Linux 3.13 SES series (maintained by Canonical)    0 (0%)
Linux 3.14 LTS series      23 (18.9%)
Linux 3.16 SES series (maintained by Canonical)   15 (12.3%)
Linux 3.18 LTS series (maintained by Oracle)    41 (33.6%)
Linux 3.19 (soon to be SES)      32 (26.2%)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Seboss666 on 20. April 2015, 09:44:48
maybe because 3.14 "vanilla" real lts works better, so no need to rely on canonical ?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: ringo on 20. April 2015, 09:57:33
hmmm Lot LTS type of kernel ... is funny :)

people use newest mostly an sure there are some cant use kernels above 3.16 somehowe.

think on netbooks is 3.12 i gues..
Title: Re: Vote for your Kernel(s) to be kept!
Post by: excalibur1234 on 01. May 2015, 12:23:43
at the moment, 8 kernels are supported.
how about deprecating support for at least 2 to 3 kernel series (e.g. 3.13, 3.10, and 3.19)?

maybe restart this poll and announce it on the manjaro homepage?
please announce the result, too. this way all users of soon outdated kernels can prepare the switch.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Lukimya on 01. May 2015, 13:14:49
at the moment, 8 kernels are supported.
maybe restart this poll and announce it on the manjaro homepage?
please announce the result, too. this way all users of soon outdated kernels can prepare the switch.

I'm sure that's the way it's going to play out.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 01. May 2015, 13:29:21
The 3.13, at least, serves to nothing.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: fennectech on 05. May 2015, 02:12:03
linux 40    i like big numbers and i cant lie     (ive found all of them stable)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: philm on 05. May 2015, 20:29:54
Seems still nobody is using linux313 ...
Code: [Select]
Linux 3.10 LTS series   7 (5%)
Linux 3.12 LTS series (maintained by Suse) 7 (5%)
Linux 3.13 SES series (maintained by Canonical)  0 (0%)
Linux 3.14 LTS series 25 (17.7%)
Linux 3.16 SES series (maintained by Canonical) 19 (13.5%)
Linux 3.18 LTS series (maintained by Oracle)    45 (31.9%)
Linux 3.19 (soon to be SES) 38 (27%)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Seboss666 on 05. May 2015, 21:52:27
I guess the 3.16 series of Kernel will be well maintained with Debian using it in their Jessie release...
Title: Re: Vote for your Kernel(s) to be kept!
Post by: linux_dream on 06. May 2015, 03:09:09
I switched from 3.16 to 3.18 yesterday and so far all seems ok, so I voted for 3.18. As a noob I guess that as a rule of thumb usually the latest kernels are the best.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 06. May 2015, 06:46:19
As a noob I guess that as a rule of thumb usually the latest kernels are the best.

The kernel that is still getting security updates and simply 'works best' for a given user is the "best" kernel for that user and their hardware. Whether that be 3.10 or 3.18 or 4.0 or whatever.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Seboss666 on 06. May 2015, 12:13:02
I switched from 3.16 to 3.18 yesterday and so far all seems ok, so I voted for 3.18. As a noob I guess that as a rule of thumb usually the latest kernels are the best.
That's not always true, I had a problem switchng from 3.14 to 3.15, suspend and resume broke the GPU state. With 3.18, all is fine. So I voted for at least two of them that worked flawlessly for me. And those two are still actively supported.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: linux_dream on 06. May 2015, 15:51:46
The kernel that is still getting security updates and simply 'works best' for a given user is the "best" kernel for that user and their hardware. Whether that be 3.10 or 3.18 or 4.0 or whatever.
I see but when you notice no difference whatsoever between kernels 3.14, 3.16 and 3.18, isn't it better to stick with 3.18 as a rule of thumb?

Quote from: Seboss666
That's not always true, I had a problem switchng from 3.14 to 3.15, suspend and resume broke the GPU state. With 3.18, all is fine. So I voted for at least two of them that worked flawlessly for me. And those two are still actively supported.
That's why I said a "rule of thumb" (not always an accurate rule). I am near your case, for me 3.14, 3.16 and 3.18 all seem to work fine (I can't notice any difference), but I only voted for 3.18.
If kernel 2.16 would work fine on your machine would you vote for it (if there was an option to vote for it, that is)? I wouldn't.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 06. May 2015, 19:18:36
I see but when you notice no difference whatsoever between kernels 3.14, 3.16 and 3.18, isn't it better to stick with 3.18 as a rule of thumb?

Personally i use the opposite principle. If a newer kernel shows no performance improvement then i'd rather have the older one that's had it's stability refined and worked on more.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: linux_dream on 07. May 2015, 03:19:17
Personally i use the opposite principle. If a newer kernel shows no performance improvement then i'd rather have the older one that's had it's stability refined and worked on more.
Interesting. If this is not too off-topic, I would like to know how you determine the performance of the kernels (benchmarks?https://wiki.archlinux.org/index.php/Benchmarking (https://wiki.archlinux.org/index.php/Benchmarking)?)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 07. May 2015, 05:48:39
Interesting. If this is not too off-topic, I would like to know how you determine the performance of the kernels

The only way that matters for a desktop system. "Feel".
Title: Re: Vote for your Kernel(s) to be kept!
Post by: linux_dream on 07. May 2015, 13:11:21
The only way that matters for a desktop system. "Feel".
Thank you. :)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Kraig on 08. May 2015, 03:32:06
3.10 is very stable for my pc desktop, not dropped support, please.
3.13 result good from Ubuntu/Xubuntu 14.04 LTS, best of 3.16.
4.0 okay for many people that i read, because is improved from 3.19.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Kraig on 10. May 2015, 11:15:01
Now i'm trying the 4.0 version, not bad really, as stability is similar to 3.10. Great!
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Sothis6881 on 12. May 2015, 01:39:56
I've had good experiences with a variety of hardware using 3.16, 3.18, and 4.0.

4.0 seems to be the most suited for my laptop and desktop that I've tried so far.  :)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Kraig on 12. May 2015, 12:17:50
At the end should keep only supported kernel 3.13, 3.16, 4.0 (also the release 4.1 when is ready).
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 12. May 2015, 12:41:34
At the end should keep only supported kernel 3.13, 3.16, 4.0 (also the release 4.1 when is ready).

You forget my preferred, 3.18 LTS (maintained by kernel.org and Oracle).  ;)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Rob on 13. May 2015, 12:26:57
You forget my preferred, 3.18 LTS (maintained by kernel.org and Oracle).  ;)
He also forgot 3.10, 3.12 and 3.14...

They're all LTS, Kraig. They're all still "supported".

I know there's some people who still have to use 3.10 for their hardware.
3.14 is my current kernel of choice for my desktop.

Possibly 3.12 could go. 3.10 and 3.14 are probably covering any use cases 3.12 could be viable for.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: mbb on 23. May 2015, 01:04:46
I'm using Manjaro on an old laptop, with an integrated GPU, intel 855GM.
I used kernels 3.12 thru 3.14 with no problem. With version 3.16 I got constant FIFO underruns, caused by the intel drm, freezing my system and draining all its power. This behavior got less frequent with 3.19, but when it happened it was much more persistent. I'm using 4.0 now, for about two days, with only one short occurrence at boot (got it with dmesg), so it seems to be getting better (still too early to tell).

This said, the best one for me is 3.14, 3.10 is important for very old hardware, and 4.0 looks promising.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: philm on 27. June 2015, 11:41:43
Well we have still the usual trend:
Code: [Select]
Linux 3.10 LTS series     14 (7.3%)
Linux 3.12 LTS series (maintained by Suse)      7 (3.6%)
Linux 3.13 ESS series (maintained by Canonical)      6 (3.1%)
Linux 3.14 LTS series     24 (12.4%)
Linux 3.16 ESS series (maintained by Canonical)     20 (10.4%)
Linux 3.18 LTS series (maintained by Oracle)     44 (22.8%)
Linux 3.19 ESS series (maintained by Canonical)     14 (7.3%)
Linux 4.0     64 (33.2%)

We will drop linux310 latest by September 2015. Next on the chopping block will be linux312, linux313 and linux316 by the end of Spring in 2016. As we are currently working on additional overlayfs support for manjaro-tools we may not have a bigger discussion due unsupported kernels by aufs.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 27. June 2015, 12:10:36
I voted for 3.18 and 4.1, 2 true LTS.  :)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Seboss666 on 27. June 2015, 12:52:17
If 4.1 is set to be LTS, I might give it a try. On my new laptop, broadwell based, I'm experimenting glitches with 4.0 when resuming, both graphics and wifi are broken, needing a complete shutdown, wait, power on to get back to work. Anyway, I'm still voting for 3.14 and 3.18, both working pretty well on older hardware.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Kraig on 23. August 2015, 09:41:49
Kernel 3.13 - 3.19 - 4.1
Title: Re: Vote for your Kernel(s) to be kept!
Post by: ewolnux on 23. August 2015, 10:27:50
3.14 & 4.1
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Atsuri on 19. September 2015, 12:01:45
All kernels seem to work fine, but I noticed that on my MacBook Pro 5,5 13-inch (2009) 3.18 and 4.1 are the most reliable. It's mostly about the Broadcom bcm4322 chip and the nVidia GeForce 9400M / 320M graphics card.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: fm2014 on 23. September 2015, 13:31:09
Where is linux kernel 4.2 space to vote ?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Ars Technis on 14. October 2015, 17:14:03
Where is linux kernel 4.2 space to vote ?
As it's the latest "Stable" kernel, I suppose there's no need to ask to keep it or not... ;)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: fr3d8 on 02. November 2015, 20:09:36
I am use kernel experimental 4.3.0-1 with Procesor i7 4970K  16Gb Nvidia GTX 650 , Manjaro Deepin 15.10  is amazing  is wonderful is magnificent. :)

With this kernel I am realy use 8 core
my grafic card is very happy ,
thanks a lot to the greats jobs Dr. Manjaro and Dr. Tolvards  :)


regards

fr3d8
Spain

Title: Re: Vote for your Kernel(s) to be kept!
Post by: Kraig on 14. November 2015, 21:56:22
At this point it's best to keep only 3.18, 4.1 and later versions.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: philm on 15. December 2015, 20:04:08
Code: [Select]
Linux 3.10 LTS series      7 (2.4%)
Linux 3.12 LTS series (maintained by Suse)      8 (2.7%)
Linux 3.13 ESS series (maintained by Canonical)      1 (0.3%)
Linux 3.14 LTS series     19 (6.5%)
Linux 3.16 ESS series (maintained by Canonical)      8 (2.7%)
Linux 3.18 LTS series (maintained by Oracle)     71 (24.4%)
Linux 3.19 ESS series (maintained by Canonical)     15 (5.2%)
Linux 4.1 LTS series            148 (50.9%)

Seems most use linux318 and linux41 so far.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: eugen-b on 15. December 2015, 20:07:45
What does ESS stand for?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Esclapion on 15. December 2015, 21:12:07
What does ESS stand for?

Extended Stable Support (Ubuntu)
Title: Re: Vote for your Kernel(s) to be kept!
Post by: philm on 15. December 2015, 21:21:27
Good news for linux42. Canonical just announced (http://www.spinics.net/lists/kernel/msg2144931.html) to adopt it into their ESS series (https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable) until August 2016.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: badbodh on 23. December 2015, 13:00:35
please don't kill 3.16, it serves my old laptop pretty good.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: daogiahieu on 06. January 2016, 01:40:28
4.1 LTS please :D, it is the best with my computer now.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: LAZA on 12. January 2016, 10:17:48
With the release of Kernel 4.4 as first "Longterm Kernel" i'm shure a lot of people will be satisfied with it till the end (at least) January 2018!
Title: Re: Vote for your Kernel(s) to be kept!
Post by: epidenimus on 13. January 2016, 16:58:25
I'm not sure what changed after 3.17, but I have tried 3 newer kernels and none allows my Intel-based laptop to function 100% with proper suspend functionality. I'll test with some other newer ones as I have time.   Please keep 3.16 as long as possible.

Thanks for all the effort to make switching it up easy!

Does anyone know a way to set a default kernel in GRUB without having to manually catch it on boot each time?  As this is my work use laptop, I'd like to keep 3.16 as the default and try others when I can, but it always defaults to the newest version.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: badbodh on 14. January 2016, 17:21:09
I'm not sure what changed after 3.17, but I have tried 3 newer kernels and none allows my Intel-based laptop to function 100% with proper suspend functionality. I'll test with some other newer ones as I have time.   Please keep 3.16 as long as possible.

Thanks for all the effort to make switching it up easy!

Does anyone know a way to set a default kernel in GRUB without having to manually catch it on boot each time?  As this is my work use laptop, I'd like to keep 3.16 as the default and try others when I can, but it always defaults to the newest version.

edit /etc/default/grub
Code: [Select]
GRUB_DISABLE_SUBMENU=y
GRUB_SAVEDEFAULT=true
GRUB_DEFAULT=saved
update-grub
Title: Re: Vote for your Kernel(s) to be kept!
Post by: jalexander01k13 on 17. January 2016, 04:01:22
Hello

I am currently using 3.18 LTS and I like this version. LTS seems to have more to offer as well. Just my opinion.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: neonr4in on 25. January 2016, 05:45:39
Vote for 3.18, 3.19, 4.1 and 4.2
Title: Re: Vote for your Kernel(s) to be kept!
Post by: notageek on 25. January 2016, 16:53:44
3.18 - 3.19 - 4.1
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Kraig on 31. January 2016, 08:29:02
I can't wait if gets a stable version of 4.5!
Title: Re: Vote for your Kernel(s) to be kept!
Post by: gadgetboi on 21. February 2016, 10:11:27
so have anybody suggest the best kernel for KDE? my KDE sometimes just lost windows decorations for no reason and it stuck there, I can't exit and the only way is to log off and log in
Title: Re: Vote for your Kernel(s) to be kept!
Post by: philm on 22. February 2016, 21:33:55
Again time to reset the vote. Here is the current trend:

Code: [Select]
Linux 3.10 LTS series     7 (3.6%)
Linux 3.12 LTS series (maintained by Suse)     4 (2.1%)
Linux 3.13 ESS series (maintained by Canonical)     2 (1%)
Linux 3.14 LTS series    14 (7.2%)
Linux 3.16 ESS series (maintained by Canonical)     5 (2.6%)
Linux 3.18 LTS series (maintained by Oracle)       24 (12.3%)
Linux 3.19 ESS series (maintained by Canonical)    11 (5.6%)
Linux 4.1 LTS series    66 (33.8%)
Linux 4.2 ESS series (maintained by Canonical)    15 (7.7%)
Linux 4.3    47 (24.1%)

Linux 4.3-series is now EOL and will be removed soon.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: excalibur1234 on 22. February 2016, 22:11:17
if i recall correctly, manjaro images with the following kernels have been released:
4.1
3.18
3.16
3.12
3.10
these are the kernels i voted for.


have you seen the votes for kernel 3.13?
why not remove it, too?
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Kraig on 28. February 2016, 11:20:15
For sure 3.18 and 4.4 series.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: Atsuri on 10. March 2016, 13:23:58
I would say 4.4, as it is the latest LTS kernel. 4.1 and 3.18 being close seconds. 4.1 worked very well with my MacBook's Broadcom 4321 wireless NIC ;).
Title: Re: Vote for your Kernel(s) to be kept!
Post by: jbMacAZ on 11. March 2016, 06:45:23
4.5 runs OK on my Dell laptop.  4.3[EOL] is the only recent kernel that runs well on my Asus T100-CHI - 4.4/4.5 regressed relative to the CHI.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: vnvman on 17. April 2016, 18:43:45
4.4 is fine on my AMD netbook. 4.5 has insanely high CPU load and stutters.
Title: Re: Vote for your Kernel(s) to be kept!
Post by: zajonara on 02. May 2016, 20:39:48
Yup. 4.4 seem to work good.