openSUSE Kernel August 2012

kernel@lists.opensuse.org

24 participants
22 discussions

[opensuse-kernel] CONFIG_CC_STACKPROTECTOR

by richard -rw- weinberger

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

7 years, 7 months

[opensuse-kernel] [PATCH] Delete patches.drivers/input-Add-LED-support-to-Synaptics-device

by Lee, Chun-Yi

As the openSUSE 12.2(bnc#768506,bnc#765524), there also have a bnc#720226 issue happen on openSUSE 12.1. So, we also remove this patch from 12.1. Cc: Takashi Iwai <tiwai(a)suse.de> Cc: C. Andrews Lavarre <alavarre(a)gmail.com> Signed-off-by: Lee, Chun-Yi <jlee(a)suse.com> --- .../input-Add-LED-support-to-Synaptics-device | 218 -------------------- series.conf | 1 - 2 files changed, 0 insertions(+), 219 deletions(-) delete mode 100644 patches.drivers/input-Add-LED-support-to-Synaptics-device diff --git a/patches.drivers/input-Add-LED-support-to-Synaptics-device b/patches.drivers/input-Add-LED-support-to-Synaptics-device deleted file mode 100644 index 5143984..0000000 --- a/patches.drivers/input-Add-LED-support-to-Synaptics-device +++ /dev/null @@ -1,218 +0,0 @@ -From: Takashi Iwai <tiwai(a)suse.de> -Subject: [PATCH 2/2] input: Add LED support to Synaptics device -Patch-mainline: Submitted -References: bnc#547370,bnc#582529,bnc#589014 - -The new Synaptics devices have an LED on the top-left corner. -This patch adds a new LED class device to control it. It's created -dynamically upon synaptics device probing. - -The LED is controlled via the command 0x0a with parameters 0x88 or 0x10. -This seems only on/off control although other value might be accepted. - -The detection of the LED isn't clear yet. It should have been the new -capability bits that indicate the presence, but on real machines, it -doesn't fit. So, for the time being, the driver checks the product id -in the ext capability bits and assumes that LED exists on the known -devices. - -Signed-off-by: Takashi Iwai <tiwai(a)suse.de> - ---- - drivers/input/mouse/Kconfig | 9 +++ - drivers/input/mouse/synaptics.c | 111 ++++++++++++++++++++++++++++++++++++++++ - drivers/input/mouse/synaptics.h | 3 + - 3 files changed, 123 insertions(+) - ---- a/drivers/input/mouse/Kconfig -+++ b/drivers/input/mouse/Kconfig -@@ -19,6 +19,7 @@ config MOUSE_PS2 - select SERIO_LIBPS2 - select SERIO_I8042 if X86 - select SERIO_GSCPS2 if GSC -+ select LEDS_CLASS if MOUSE_PS2_SYNAPICS_LED - help - Say Y here if you have a PS/2 mouse connected to your system. This - includes the standard 2 or 3-button PS/2 mouse, as well as PS/2 -@@ -67,6 +68,14 @@ config MOUSE_PS2_SYNAPTICS - - If unsure, say Y. - -+config MOUSE_PS2_SYNAPTICS_LED -+ bool "Support embedded LED on Synaptics devices" -+ depends on MOUSE_PS2_SYNAPTICS -+ select NEW_LEDS -+ help -+ Say Y here if you have a Synaptics device with an embedded LED. -+ This will enable LED class driver to control the LED device. -+ - config MOUSE_PS2_LIFEBOOK - bool "Fujitsu Lifebook PS/2 mouse protocol extension" if EXPERT - default y ---- a/drivers/input/mouse/synaptics.c -+++ b/drivers/input/mouse/synaptics.c -@@ -28,6 +28,7 @@ - #include <linux/input/mt.h> - #include <linux/serio.h> - #include <linux/libps2.h> -+#include <linux/leds.h> - #include <linux/slab.h> - #include "psmouse.h" - #include "synaptics.h" -@@ -353,6 +354,110 @@ static void synaptics_pt_create(struct p - serio_register_port(serio); - } - -+#ifdef CONFIG_MOUSE_PS2_SYNAPTICS_LED -+/* -+ * LED handling: -+ * Some Synaptics devices have an embeded LED at the top-left corner. -+ */ -+ -+struct synaptics_led { -+ struct psmouse *psmouse; -+ struct work_struct work; -+ struct led_classdev cdev; -+}; -+ -+static void synaptics_set_led(struct psmouse *psmouse, int on) -+{ -+ int i; -+ unsigned char cmd = on ? 0x88 : 0x10; -+ -+ ps2_begin_command(&psmouse->ps2dev); -+ if (__ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_SETSCALE11)) -+ goto out; -+ for (i = 6; i >= 0; i -= 2) { -+ unsigned char d = (cmd >> i) & 3; -+ if (__ps2_command(&psmouse->ps2dev, &d, PSMOUSE_CMD_SETRES)) -+ goto out; -+ } -+ cmd = 0x0a; -+ __ps2_command(&psmouse->ps2dev, &cmd, PSMOUSE_CMD_SETRATE); -+ out: -+ ps2_end_command(&psmouse->ps2dev); -+} -+ -+static void synaptics_led_work(struct work_struct *work) -+{ -+ struct synaptics_led *led; -+ -+ led = container_of(work, struct synaptics_led, work); -+ synaptics_set_led(led->psmouse, led->cdev.brightness); -+} -+ -+static void synaptics_led_cdev_brightness_set(struct led_classdev *cdev, -+ enum led_brightness value) -+{ -+ struct synaptics_led *led; -+ -+ led = container_of(cdev, struct synaptics_led, cdev); -+ schedule_work(&led->work); -+} -+ -+static void synaptics_sync_led(struct psmouse *psmouse) -+{ -+ struct synaptics_data *priv = psmouse->private; -+ -+ if (priv->led) -+ synaptics_set_led(psmouse, priv->led->cdev.brightness); -+} -+ -+static int synaptics_init_led(struct psmouse *psmouse) -+{ -+ struct synaptics_data *priv = psmouse->private; -+ struct synaptics_led *led; -+ int err; -+ -+ /* FIXME: LED is supposedly detectable in cap0c[1] 0x20, but it seems -+ * not working on real machines. -+ * So we check the product id to be sure. -+ */ -+ if (!priv->ext_cap_0c || SYN_CAP_PRODUCT_ID(priv->ext_cap) != 0xe4) -+ return 0; -+ -+ printk(KERN_INFO "synaptics: support LED control\n"); -+ led = kzalloc(sizeof(struct synaptics_led), GFP_KERNEL); -+ if (!led) -+ return -ENOMEM; -+ led->psmouse = psmouse; -+ INIT_WORK(&led->work, synaptics_led_work); -+ led->cdev.name = "psmouse::synaptics"; -+ led->cdev.brightness_set = synaptics_led_cdev_brightness_set; -+ led->cdev.flags = LED_CORE_SUSPENDRESUME; -+ err = led_classdev_register(NULL, &led->cdev); -+ if (err < 0) { -+ kfree(led); -+ return err; -+ } -+ priv->led = led; -+ return 0; -+} -+ -+static void synaptics_free_led(struct psmouse *psmouse) -+{ -+ struct synaptics_data *priv = psmouse->private; -+ -+ if (!priv->led) -+ return; -+ cancel_work_sync(&priv->led->work); -+ synaptics_set_led(psmouse, 0); -+ led_classdev_unregister(&priv->led->cdev); -+ kfree(priv->led); -+} -+#else -+#define synaptics_init_led(ps) 0 -+#define synaptics_free_led(ps) do {} while (0) -+#define synaptics_sync_led(ps) do {} while (0) -+#endif -+ - /***************************************************************************** - * Functions to interpret the absolute mode packets - ****************************************************************************/ -@@ -647,6 +752,7 @@ static void set_input_params(struct inpu - - static void synaptics_disconnect(struct psmouse *psmouse) - { -+ synaptics_free_led(psmouse); - synaptics_reset(psmouse); - kfree(psmouse->private); - psmouse->private = NULL; -@@ -678,6 +784,8 @@ static int synaptics_reconnect(struct ps - return -1; - } - -+ synaptics_sync_led(psmouse); -+ - return 0; - } - -@@ -752,6 +860,9 @@ int synaptics_init(struct psmouse *psmou - SYN_ID_MAJOR(priv->identity), SYN_ID_MINOR(priv->identity), - priv->model_id, priv->capabilities, priv->ext_cap, priv->ext_cap_0c); - -+ if (synaptics_init_led(psmouse) < 0) -+ goto init_fail; -+ - set_input_params(psmouse->dev, priv); - - /* ---- a/drivers/input/mouse/synaptics.h -+++ b/drivers/input/mouse/synaptics.h -@@ -97,6 +97,8 @@ struct synaptics_hw_state { - signed char scroll; - }; - -+struct synaptics_led; -+ - struct synaptics_data { - /* Data read from the touchpad */ - unsigned long int model_id; /* Model-ID */ -@@ -110,6 +112,7 @@ struct synaptics_data { - struct serio *pt_port; /* Pass-through serio port */ - - struct synaptics_hw_state mt; /* current gesture packet */ -+ struct synaptics_led *led; - }; - - void synaptics_module_init(void); diff --git a/series.conf b/series.conf index afb090b..d0c127e 100644 --- a/series.conf +++ b/series.conf @@ -911,7 +911,6 @@ patches.drivers/elousb.patch patches.suse/elousb-2.6.35-api-changes patches.fixes/input-add-acer-aspire-5710-to-nomux.patch - patches.drivers/input-Add-LED-support-to-Synaptics-device patches.drivers/input-elantech-correct-x-y-value-range-for-v2-hardware patches.drivers/input-elantech-get-rid-of-etp_2ft_-in-elantech-h -- 1.6.4.2 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

8 years, 9 months

[opensuse-kernel] Re: [opensuse-factory] segfault on zypper dup completion

by Cristian Rodríguez

El 29/08/12 12:43, Felix Miata escribió: >> [ 475.004020] ------------[ cut here ]------------ >> [ 475.004041] WARNING: at >> /home/abuild/rpmbuild/BUILD/kernel-desktop-3.4.2/linux-3.4/net/sched/sch_generic.c:256 >> >> dev_watchdog+0x1e8/0x200() >> [ 475.004046] Hardware name: >> [ 475.004049] NETDEV WATCHDOG: eth0 (e100): transmit queue 0 timed out >> [ 475.004052] Modules linked in: snd_pcm_oss snd_mixer_oss snd_seq >> snd_seq_device nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc dm_mod >> sr_mod snd_intel8x0 cdrom snd_ac97_codec ac97_bus snd_pcm snd_timer snd >> soundcore snd_page_alloc iTCO_wdt iTCO_vendor_support microcode pcspkr >> e100 >> i2c_i801 shpchp pci_hotplug floppy i915 drm_kms_helper drm >> i2c_algo_bit video >> button scsi_dh_rdac scsi_dh_alua scsi_dh_hp_sw scsi_dh_emc scsi_dh fan >> processor thermal thermal_sys ata_generic ata_piix sata_sil >> [ 475.004113] Pid: 0, comm: swapper/0 Not tainted 3.4.2-1-desktop #1 >> [ 475.004117] Call Trace: >> [ 475.004138] [<c02054b9>] try_stack_unwind+0x199/0x1b0 >> [ 475.004149] [<c02041d7>] dump_trace+0x47/0xf0 >> [ 475.004155] [<c020551b>] show_trace_log_lvl+0x4b/0x60 >> [ 475.004161] [<c0205548>] show_trace+0x18/0x20 >> [ 475.004169] [<c06f02fe>] dump_stack+0x6d/0x72 >> [ 475.004178] [<c0233188>] warn_slowpath_common+0x78/0xb0 >> [ 475.004185] [<c0233253>] warn_slowpath_fmt+0x33/0x40 >> [ 475.004194] [<c0636ef8>] dev_watchdog+0x1e8/0x200 >> [ 475.004204] [<c0240808>] run_timer_softirq+0xf8/0x300 >> [ 475.004211] [<c02398a1>] __do_softirq+0x81/0x1b0 >> [ 475.004217] [<c02040b6>] do_softirq+0x76/0xb0 >> [ 475.004224] ---[ end trace e91e2e809858261d ]--- >> [ 475.021328] e100 0000:01:02.0: eth0: NIC Link is Up 100 Mbps Full >> Duplex >> [ 2774.999044] end_request: I/O error, dev fd0, sector 0 >> [ 3268.406459] udevd[12045]: starting version 182 >> [ 4264.313985] nfsd: last server has exited, flushing export cache >> [ 4269.974101] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state >> recovery directory >> [ 4269.974153] NFSD: starting 90-second grace period >> [ 4875.923898] zypper[2291]: segfault at 0 ip 08140fd8 sp bfcdcd80 >> error 4 in >> zypper[8048000+151000] Well.. that's a kernel bug, zypper not at fault. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

8 years, 10 months

[opensuse-kernel] How to compile the kernel style "OpenSuSE"?

by João Silva

Hello, I have a doubt in the correct procedure for compiling the operating system kernel in OpenSUSE. I have sought help in forums, but nobody could help me, so I'm turning to you. I hope you can understand me, my English is not very good. I'm using version 12.1 of the "OpenSUSE" with kernel "1.3.10-1.16-default." After downloading the kernel source code and all the build dependencies via "YAST", run the following commands as "root": cd /usr/src/linux-3.1.10-1.16/; make clean; make mrproper; cp /boot/config-3.1.10-1.16-default ./.config; make menuconfig; At this stage I would not change any configuration of the kernel, just select the file ".config" and choose a name for the kernel that will be compiled. After these procedures, I save and start the build process via the command: make dep; make rpm; After waiting for the build is done, I checked the package ".rpm" generated has a size of 317 MB, and the repository of the "OpenSUSE", the size of this file is approximately 37 MB. After installing the kernel compiled, I noticed no difference in the number of generated binary files, only in their size. So, I wonder, because the kernel is compiled much mair than the kernel provided by the repository "OpenSUSE"?, And I'm using the same configuration. And what is the correct way to compile the kernel in OpenSUSE?. So I can generate a size compatible with the repository. Thank you for the information, João -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

8 years, 10 months

[opensuse-kernel] [PATCH] make omap2plus (ARM) flavor build with 3.6rc3

by Dirk Müller

Hi, The patch below removes some optional parts from the config that makes it build again with the 3.6.rc3. I'm currently burn-in testing this kernel, so far it looks good. Please apply. Thanks, Dirk

8 years, 10 months

[opensuse-kernel] Re: [opensuse-factory] segfault on zypper dup completion

by David Chang

Hi, 2012/8/24 Felix Miata <mrmazda(a)earthlink.net>: > I just did a dup to a 32 bit Beta 2 P4/Celeron system last dup'd about 6 > weeks ago (host t2240). It appeared to complete normally, but after the > zypper ps warning there was a segmentation fault line. Tail of dmesg: > > [ 37.342287] Installing knfsd (copyright (C) 1996 okir(a)monad.swb.de). > [ 38.104167] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state > recovery directory > [ 38.113952] NFSD: starting 90-second grace period > [ 44.610044] eth0: no IPv6 routers present > [ 475.004020] ------------[ cut here ]------------ > [ 475.004041] WARNING: at > /home/abuild/rpmbuild/BUILD/kernel-desktop-3.4.2/linux-3.4/net/sched/sch_generic.c:256 > dev_watchdog+0x1e8/0x200() > [ 475.004046] Hardware name: > [ 475.004049] NETDEV WATCHDOG: eth0 (e100): transmit queue 0 timed out > [ 475.004052] Modules linked in: snd_pcm_oss snd_mixer_oss snd_seq > snd_seq_device nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc dm_mod > sr_mod snd_intel8x0 cdrom snd_ac97_codec ac97_bus snd_pcm snd_timer snd > soundcore snd_page_alloc iTCO_wdt iTCO_vendor_support microcode pcspkr e100 > i2c_i801 shpchp pci_hotplug floppy i915 drm_kms_helper drm i2c_algo_bit > video button scsi_dh_rdac scsi_dh_alua scsi_dh_hp_sw scsi_dh_emc scsi_dh fan > processor thermal thermal_sys ata_generic ata_piix sata_sil > [ 475.004113] Pid: 0, comm: swapper/0 Not tainted 3.4.2-1-desktop #1 > [ 475.004117] Call Trace: > [ 475.004138] [<c02054b9>] try_stack_unwind+0x199/0x1b0 > [ 475.004149] [<c02041d7>] dump_trace+0x47/0xf0 > [ 475.004155] [<c020551b>] show_trace_log_lvl+0x4b/0x60 > [ 475.004161] [<c0205548>] show_trace+0x18/0x20 > [ 475.004169] [<c06f02fe>] dump_stack+0x6d/0x72 > [ 475.004178] [<c0233188>] warn_slowpath_common+0x78/0xb0 > [ 475.004185] [<c0233253>] warn_slowpath_fmt+0x33/0x40 > [ 475.004194] [<c0636ef8>] dev_watchdog+0x1e8/0x200 > [ 475.004204] [<c0240808>] run_timer_softirq+0xf8/0x300 > [ 475.004211] [<c02398a1>] __do_softirq+0x81/0x1b0 > [ 475.004217] [<c02040b6>] do_softirq+0x76/0xb0 > [ 475.004224] ---[ end trace e91e2e809858261d ]--- > [ 475.021328] e100 0000:01:02.0: eth0: NIC Link is Up 100 Mbps Full Duplex > [ 2774.999044] end_request: I/O error, dev fd0, sector 0 > [ 3268.406459] udevd[12045]: starting version 182 > [ 4264.313985] nfsd: last server has exited, flushing export cache > [ 4269.974101] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state > recovery directory > [ 4269.974153] NFSD: starting 90-second grace period > [ 4875.923898] zypper[2291]: segfault at 0 ip 08140fd8 sp bfcdcd80 error 4 > in zypper[8048000+151000] Did you encounter this issue before? Can you please provide /var/log/message and lspci -nvv ? Thanks! Regards, David > -- > "The wise are known for their understanding, and pleasant > words are persuasive." Proverbs 16:21 (New Living Translation) > > Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! > > Felix Miata *** http://fm.no-ip.com/ > -- > To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org > To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org > -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

8 years, 10 months

[opensuse-kernel] [PATCH] Delete patches.drivers/input-Add-LED-support-to-Synaptics-device

by Lee, Chun-Yi

8 years, 10 months

[opensuse-kernel] Tumbleweed kernel changes to help upstream development

by Greg KH

Hi all, As part of one of the Linux kernel Summit discussions today, it was brought up that after a kernel is released (for example 3.5), it's a bit too late to be doing testing to see how well it is working out. The .0 release is usually a bit rough, and it takes until the .1 or .2 release to get most major issues out of the way. So, the kernel developers would like to get a wider range of testing, and one thing proposed would be to have rolling distros switch their kernel over a bit earlier to the new release than they had been doing. Specifically, around the -rc5 point in time would be great. That way, any reported regressions could be fixed sooner and get into the final .0 release for everyone to use. Now this does place a bit of a larger burden on the users of those distros to be diligent in reporting problems, and the distro engineers to report the issues upstream as well, but it sounds like a reasonable thing to try out. So, for the next kernel release, I'm thinking of switching the kernel in Tumbleweed over to 3.6 at the -rc5 timeframe. Does anyone strongly object to this happening? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

8 years, 10 months

[opensuse-kernel] Re: [opensuse-factory] Re: Tumbleweed kernel changes to help upstream development

by Patrick Shanahan

* Achim Gratz <Stromeko(a)nexgo.de> [08-28-12 13:33]: > Greg KH writes: > > So, the kernel developers would like to get a wider range of testing, > > and one thing proposed would be to have rolling distros switch their > > kernel over a bit earlier to the new release than they had been doing. > > Specifically, around the -rc5 point in time would be great. That way, > > any reported regressions could be fixed sooner and get into the final .0 > > release for everyone to use. > > While I understand the idea, I am one of those Tumbleweed users that do > not have a dedicated test machine or even test partition so I'd really > have to think about sticking with Tumbleweed if this became the new > policy. I usually have the three latest kernels installed, so I can go > back if one of the updates makes problems, but there are times where I > wouldn't want to bear this added risk. Besides, the way Tumbleweed was > advertised in the past does not really fit to what it would become with > that change. I'd suggest putting the not-quite released kernel stuff > into a different or add-on repo so that everyone can opt in or out by > activating the correct repo. > this appears a *reasonable* approach, with wide publication -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

8 years, 10 months

[opensuse-kernel] Can Kernel:stable be updated to version 3.5.3 from 3.5.2

by doiggl＠velocitynet.com.au

Hello Can Kernel:stable be updated to version 3.5.3 from 3.5.2 https://build.opensuse.org/project/packages?project=Kernel%3Astable http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.5.3.bz2 http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.5.3.tar.bz2 Cheers Glenn -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

8 years, 10 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openSUSE Kernel August 2012