Re: [PATCH 1/2] lockdep,rtmutex,bug: Show taint flags on error
On Fri, 28 Oct 2011 04:36:55 +0100, Ben Hutchings b...@decadent.org.uk wrote: Currently lock debugging is disabled when the kernel is tainted, with a few exceptions. It is already recognised that this can be useful for staging modules (TAINT_CRAP), but that also goes for out-of-tree modules (TAINT_OOT_MODULE) so long as core kernel developers don't have to spend time debugging them. Also, there are several reasons for tainting that are unlikely to introduce false locking bug reports (e.g. TAINT_FIRMWARE_WORKAROUND). Instead of disabling lock debugging, show the taint flags in all lockdep and rtmutex-debug error messages. Signed-off-by: Ben Hutchings b...@decadent.org.uk Acked-by: Rusty Russell ru...@rustcorp.com.au -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lis1q5tc@rustcorp.com.au
Re: [PATCH] module,bug: Add TAINT_OOT_MODULE flag for modules not built in-tree
On Wed, 26 Oct 2011 21:55:28 -0400, Dave Jones da...@redhat.com wrote: On Thu, Oct 27, 2011 at 11:41:37AM +1030, Rusty Russell wrote: I think we need a taint_string() function, and instead of lockdep disabling itself it should note the taint string in its reports. Similarly for anything else (oops already does this). you mean like print_tainted() ? Wow, there's one terribly named function! So, yeah, kinda like that. Only remove the suckage. Thanks, Rusty. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkgiosm5@rustcorp.com.au
Re: [PATCH 2/2] module: Re-enable dynamic debugging for GPL-compatible OOT modules
On Fri, 28 Oct 2011 04:38:14 +0100, Ben Hutchings b...@decadent.org.uk wrote: Dynamic debugging was enabled for GPL-compatible out-of-tree modules until my addition of TAINT_OOT_MODULE. It should continue to be enabled now. Please just remove the test entirely. AFAICT there's nothing unique to dynamic debug which means it should avoid taint. If it oopses, we'll learn all about tainting in the oops message. Signed-off-by: Ben Hutchings b...@decadent.org.uk --- kernel/module.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/module.c b/kernel/module.c index dab585e..448fd77 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -2881,7 +2881,7 @@ static struct module *load_module(void __user *umod, } /* This has to be done once we're sure module name is unique. */ - if (!mod-taints || mod-taints == (1UTAINT_CRAP)) + if (!(mod-taints ~(1U TAINT_CRAP | 1U TAINT_OOT_MODULE))) dynamic_debug_setup(info.debug, info.num_debug); /* Find duplicate symbols */ @@ -2918,7 +2918,7 @@ static struct module *load_module(void __user *umod, module_bug_cleanup(mod); ddebug: - if (!mod-taints || mod-taints == (1UTAINT_CRAP)) + if (!(mod-taints ~(1U TAINT_CRAP | 1U TAINT_OOT_MODULE))) dynamic_debug_remove(info.debug); unlock: mutex_unlock(module_mutex); -- 1.7.7 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obwxq5tz@rustcorp.com.au
Bug#647136: linux-image-2.6.32-5-amd64: psmouse.c bad data from KBD bad parity
Arvind K wrote: -By modprobe psmouse I meant that, whenever the touchpad stops working, I have to run the following: $sudo modprobe -r psmouse $sudo modprobe psmouse I see. [...] [36521.371269] psmouse.c: bad data from KBC - bad parity [36521.373636] psmouse.c: bad data from KBC - bad parity [... and so on, once every 2ms or so ...] Yep, that sounds broken. :) [...] [36552.047333] psmouse.c: bad data from KBC - bad parity [36556.015679] Synaptics Touchpad, model: 1, fw: 7.2, id: 0x1c0b1, caps: 0xd04731/0xa4/0xa [36556.058547] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio4/input/input13 I assume this is when you unloaded and reloaded the driver. It would also be interesting to see the initialization sequence (i.e., dmesg output from bootup) when nothing is going wrong. The log you sent is abridged at the beginning because the parity errors flooded the log. What version of gsynaptics are you using? Based on [1], it seems that gsynaptics does not work with a modern X server (though that is no excuse to provoke parity errors like this). Michal, any hints about what gsynaptics could have been doing to provoke this (e.g., a simpler command to simulate what it does)? It would also still be interesting to see what a recent (3.x) kernel does. I have a vague suspicion that v2.6.34-rc7~22^2~8 (Input: psmouse - ignore parity error for basic protocols, 2010-04-19) or some similar fix could have changed the behavior here. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111031092748.gb24...@elie.hsd1.il.comcast.net
Re: [kernel] r18204 - in dists/sid/linux-2.6/debian/installer: alpha/modules/alpha amd64/modules/amd64 armel/modules/armel-iop32x armel/modules/armel-kirkwood armel/modules/armel-orion5x armhf/modules
On Mon, Oct 31, 2011 at 04:05:27AM +, Ben Hutchings wrote: Add empty files to trigger generation of kernel-image udebs linux-2.6 is still a version 1 source package. Empty files won't survive. Bastian -- Without freedom of choice there is no creativity. -- Kirk, The return of the Archons, stardate 3157.4 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111031121246.gc2...@wavehammer.waldi.eu.org
Bug#647095: CPU hyperthreading turned on after soft power-cycle
On 10/30/2011 4:25 PM, Ben Hutchings wrote: On Sun, 2011-10-30 at 07:05 -0400, Jiri Polach wrote: Package: linux-2.6 Version: 2.6.39-3~bpo60+1 Severity: normal When the computer is turned off using shutdown -h or halt command, the hypertherading BIOS setting is changed - even if hypertherading is disabled in BIOS, the kernel detects twice as many processors on next boot as if hyperthreading was enabled. Please see details below. I have observed the problem on several Supermicro platforms with various Intel Xeon processors. The particular case I report was observed on Supermicro X8DTT-F mainboard with two Intel Xeon E5645 processors (6core). The problem can be reproduced the following way: By my understanding of how hyperthreading is controlled, this has to be a BIOS bug, as you seem to have suspected. But if the BIOS behaviour is kernel version-dependent, then presumably there is something the kernel can do to work around it. Yes, there are reasons that support my suspicion that BIOS is not doing its work properly. But I cannot prove it until it is clear what has been changed in the kernel. 1. Turn on the computer, go to BIOS setup and turn Simultaneous multithreading to Disabled. Boot Debian. 2. Check with cat /proc/cpuinfo that the system reports 12 CPUs (2 x six-core processor). 3. (optionally) Reboot the system (shutdown -r) and check that there are still 12 CPUs detected and reported. 4. Halt the system using shutdown -h or halt, turn it on again, and boot Debian. I assume from this that shutdown -h is configured to turn the system off. I do not know. I have been using mostly halt to shutdown the system and turn the server off and I tried shutdown -h only several times to see if there is any difference. Both commands have turned the computer off, but I did not do any special shutdown -h configuration. 5. Check the number of CPUs reported - it will show you that there are 24 CPUs as if hyperthreading was enabled. 6. Reboot and go to BIOS setup - it still shows that Simultaneous multithreading is set to Disabled. Do not change anythig, just select Save and Exit. Boot Debian and check the number of CPUs - it now shows 12 CPUs again. I have tested several kernel versions and it seems that this behavior appeared for the first time somewhere between 2.6.35.7 and 2.6.38.6 versions (ok = does not show the decribed behavior, not ok = does show): * linux-image-2.6.32-5-amd64 official Debian - ok * linux-image-2.6.39-bpo.2-amd64 official Debian from backports - not ok * linux 2.6.35.7 - custom compiled from source - ok * linux 2.6.38.6 - custom compiled from source - not ok * linux 2.6.39.4 - custom compiled from source - not ok * linux 3.0.4 - custom compiled from source - not ok That might be too large a range for developers to consider. Can you test some versions between 2.6.35.7 and 2.6.38.6 (bisection)? OK, after another day of testing it seems that the problem appears in 2.6.38.1, because * linux 2.6.37.6 - custom compiled from source - ok * linux 2.6.38.1 - custom compiled from source - not ok Best regards, Jiri Polach Ben. I have exchnged many e-mails with Supermicro distributor who apparently is in direct contact with Supermicro technicians. They more or less deny any responsibility for this problem and repeatedly point to the fact that some (older) kernels do not exhibit this behavior so it must be a kernel problem. Their representative writes: I discussed this with supermicro and they informed me that the Kernel itself is causing the issue, that it may be sending the hyperthreading command code to the BIOS. Although I do not completely agree with their arguments, my knowledge is not deep enough to recognize where exactly the core of the problem is so I report this as a bug in a hope that someone will know what happens when a kernel turns a computer off and what has changed in kernel somewhere between the versions I mention above. I have asked Supermicro distributor for more information on what they think happens there and what exactly they mean by hyperhreading command code and I am waiting for their response. -- Package-specific info: ** Version: Linux version 2.6.39-bpo.2-amd64 (Debian 2.6.39-3~bpo60+1) (norb...@tretkowski.de) (gcc version 4.4.5 (Debian 4.4.5-8) ) #1 SMP Tue Jul 26 10:35:23 UTC 2011 [...] ** Model information sys_vendor: Supermicro product_name: X8DTT product_version: 1234567890 chassis_vendor: Supermicro chassis_version: 1234567890 bios_vendor: American Megatrends Inc. bios_version: 080016 board_vendor: Supermicro board_name: X8DTT board_version: 2.0 [...] -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eae9d3a.7000...@atlas.cz
Bug#532005: gnome: Bell beep on PC speaker no longer works
tags 532005 + patch
quit
Hi,
Matthew Wakeling wrote:
Today I upgraded from Lenny to Squeeze. The console beep no longer works.
Some hideous sound now emerges from the sound card instead.
Reproduced on an HP G71-445US laptop. The honk that replaced the bell
is like a quick buzzer sound. Could you try this patchset (the first
patch of which seems to help on that machine, at least)?
FWIW, when I unload and load the pcspkr driver, it doesn't fix
anything on that machine. One of two things happens, and which
happens on each trial seems random: (A) the beep stays the same, or
(B) the beep goes away entirely.
From: Daniel J Blueman daniel.blue...@gmail.com
Date: Tue, 3 Aug 2010 11:09:13 +0100
Subject: ALSA: hda - Fix beep frequency on IDT 92HD73xx and 92HD71Bxx codecs
commit 1b0e372d7b52c9fc96348779015a6db7df7f286e upstream.
Fix HDA beep frequency on IDT 92HD73xx and 92HD71Bxx codecs.
These codecs use the standard beep frequency calculation although the
datasheet says it's linear frequency.
Other IDT/STAC codecs might have the same problem. They should be
fixed individually later.
Signed-off-by: Daniel J Blueman daniel.blue...@gmail.com
Signed-off-by: Takashi Iwai ti...@suse.de
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
sound/pci/hda/patch_sigmatel.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c
index 01da10bd8715..9f6205dd1996 100644
--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -200,6 +200,7 @@ struct sigmatel_spec {
unsigned int spdif_mute: 1;
unsigned int check_volume_offset:1;
unsigned int auto_mic:1;
+ unsigned int linear_tone_beep:1;
/* gpio lines */
unsigned int eapd_mask;
@@ -3757,7 +3758,7 @@ static int stac92xx_parse_auto_config(struct hda_codec
*codec, hda_nid_t dig_out
if (err 0)
return err;
/* IDT/STAC codecs have linear beep tone parameter */
- codec-beep-linear_tone = 1;
+ codec-beep-linear_tone = spec-linear_tone_beep;
/* if no beep switch is available, make its own one */
caps = query_amp_caps(codec, nid, HDA_OUTPUT);
if (codec-beep
@@ -4852,6 +4853,7 @@ static int patch_stac9200(struct hda_codec *codec)
return -ENOMEM;
codec-spec = spec;
+ spec-linear_tone_beep = 1;
spec-num_pins = ARRAY_SIZE(stac9200_pin_nids);
spec-pin_nids = stac9200_pin_nids;
spec-board_config = snd_hda_check_board_config(codec, STAC_9200_MODELS,
@@ -4914,6 +4916,7 @@ static int patch_stac925x(struct hda_codec *codec)
return -ENOMEM;
codec-spec = spec;
+ spec-linear_tone_beep = 1;
spec-num_pins = ARRAY_SIZE(stac925x_pin_nids);
spec-pin_nids = stac925x_pin_nids;
@@ -4998,6 +5001,7 @@ static int patch_stac92hd73xx(struct hda_codec *codec)
return -ENOMEM;
codec-spec = spec;
+ spec-linear_tone_beep = 0;
codec-slave_dig_outs = stac92hd73xx_slave_dig_outs;
spec-num_pins = ARRAY_SIZE(stac92hd73xx_pin_nids);
spec-pin_nids = stac92hd73xx_pin_nids;
@@ -5145,6 +5149,7 @@ static int patch_stac92hd83xxx(struct hda_codec *codec)
return -ENOMEM;
codec-spec = spec;
+ spec-linear_tone_beep = 1;
codec-slave_dig_outs = stac92hd83xxx_slave_dig_outs;
spec-digbeep_nid = 0x21;
spec-mux_nids = stac92hd83xxx_mux_nids;
@@ -5294,6 +5299,7 @@ static int patch_stac92hd71bxx(struct hda_codec *codec)
return -ENOMEM;
codec-spec = spec;
+ spec-linear_tone_beep = 0;
codec-patch_ops = stac92xx_patch_ops;
spec-num_pins = STAC92HD71BXX_NUM_PINS;
switch (codec-vendor_id) {
@@ -5553,6 +5559,7 @@ static int patch_stac922x(struct hda_codec *codec)
return -ENOMEM;
codec-spec = spec;
+ spec-linear_tone_beep = 1;
spec-num_pins = ARRAY_SIZE(stac922x_pin_nids);
spec-pin_nids = stac922x_pin_nids;
spec-board_config = snd_hda_check_board_config(codec, STAC_922X_MODELS,
@@ -5656,6 +5663,7 @@ static int patch_stac927x(struct hda_codec *codec)
return -ENOMEM;
codec-spec = spec;
+ spec-linear_tone_beep = 1;
codec-slave_dig_outs = stac927x_slave_dig_outs;
spec-num_pins = ARRAY_SIZE(stac927x_pin_nids);
spec-pin_nids = stac927x_pin_nids;
@@ -5790,6 +5798,7 @@ static int patch_stac9205(struct hda_codec *codec)
return -ENOMEM;
codec-spec = spec;
+ spec-linear_tone_beep = 1;
spec-num_pins = ARRAY_SIZE(stac9205_pin_nids);
spec-pin_nids = stac9205_pin_nids;
spec-board_config = snd_hda_check_board_config(codec, STAC_9205_MODELS,
@@ -5945,6 +5954,7 @@ static int patch_stac9872(struct hda_codec *codec)
if
Processed: Re: gnome: Bell beep on PC speaker no longer works
Processing commands for cont...@bugs.debian.org: tags 532005 + patch Bug #532005 [linux-2.6] PC speaker bell makes a hideous buzzing honk, not a nice beep (HDA digital beep should not override actual pc speaker) Added tag(s) patch. quit Stopping processing here. Please contact me if you need assistance. -- 532005: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532005 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13200683558675.transcr...@bugs.debian.org
Re: [PATCH 2/2] module: Re-enable dynamic debugging for GPL-compatible OOT modules
On Mon, 2011-10-31 at 12:29 +1030, Rusty Russell wrote: On Fri, 28 Oct 2011 04:38:14 +0100, Ben Hutchings b...@decadent.org.uk wrote: Dynamic debugging was enabled for GPL-compatible out-of-tree modules until my addition of TAINT_OOT_MODULE. It should continue to be enabled now. Please just remove the test entirely. AFAICT there's nothing unique to dynamic debug which means it should avoid taint. If it oopses, we'll learn all about tainting in the oops message. It looks like the dynamic debug facility is not meant to be available to proprietary modules. Ben. Signed-off-by: Ben Hutchings b...@decadent.org.uk --- kernel/module.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/module.c b/kernel/module.c index dab585e..448fd77 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -2881,7 +2881,7 @@ static struct module *load_module(void __user *umod, } /* This has to be done once we're sure module name is unique. */ - if (!mod-taints || mod-taints == (1UTAINT_CRAP)) + if (!(mod-taints ~(1U TAINT_CRAP | 1U TAINT_OOT_MODULE))) dynamic_debug_setup(info.debug, info.num_debug); /* Find duplicate symbols */ @@ -2918,7 +2918,7 @@ static struct module *load_module(void __user *umod, module_bug_cleanup(mod); ddebug: - if (!mod-taints || mod-taints == (1UTAINT_CRAP)) + if (!(mod-taints ~(1U TAINT_CRAP | 1U TAINT_OOT_MODULE))) dynamic_debug_remove(info.debug); unlock: mutex_unlock(module_mutex); -- 1.7.7 -- Ben Hutchings Computers are not intelligent. They only think they are. signature.asc Description: This is a digitally signed message part
Bug#646889: linux-image-2.6.32-5-686: Since I'm using nfsd instead of samba a kerneloops occurs when accessing the files on server
On Sun, 2011-10-30 at 11:45 +0100, Marc Matzen wrote: Hi, I have applied the patch and a memory allocation failure still occurs (swapper instead of nfsd). Different problem. For some reason the network stack is reallocating a large buffer. You may be able to work around this by disabling TSO (ethtool -K eth0 tso off). But I wonder why it's necessary to reallocate. Are you using iptables or a packet-transformation facility? Ben. -- Ben Hutchings Computers are not intelligent. They only think they are. signature.asc Description: This is a digitally signed message part
Re: gcc-4.6
On Fri, 2011-10-28 at 20:53 +0200, Stefan Lippers-Hollmann wrote: Hi On Friday 28 October 2011, Ben Hutchings wrote: On Fri, Oct 28, 2011 at 06:39:13PM +0200, Bastian Blank wrote: Hi We need to bump the compiler before the Wheezy release to 4.6. Preliminary tests shows that it works fine with Linux 3.1. Now is the question, when do we want to do it? We don't yet have an aufs patch for 3.1, and there will be no rt [...] aufs 3.x-rcN-20111024 (aufs3.x-rcN branch) is working fine with 3.1, also if compiled by gcc-4.6. I've applied the 3.0 and 3.1 aufs patches to the respective branches. And I'm now subscribed to the aufs mailing list so I should see when the repository moves next time... Ben. -- Ben Hutchings Computers are not intelligent. They only think they are. signature.asc Description: This is a digitally signed message part
Bug#647185: linux-2.6: kernel null pointer dereference while adding SAN path
Package: linux-2.6 Version: 2.6.32-38 Hi, removing paths to our SAN and adding them back results in [ 951.569561] device-mapper: table: 253:2: sde too small for target: start=0, len=140465493850188, dev_size=627107840 [ 951.571750] BUG: unable to handle kernel NULL pointer dereference at (null) [ 951.571876] IP: [(null)] (null) [ 951.571961] PGD 6500c1067 PUD 650135067 PMD 0 [ 951.578673] Oops: 0010 [#1] SMP [ 951.578788] last sysfs file: /sys/devices/virtual/block/dm-3/uevent [ 951.578846] CPU 16 [ 951.578928] Modules linked in: 8021q garp stp ext4 jbd2 crc16 dm_round_robin dm_multipath scsi_dh bonding ipmi_devintf ipmi_si ipmi_msghandler ohci_hcd radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core snd_pcm snd_timer snd soundcore snd_page_alloc hpilo hpwdt joydev pcspkr psmouse evdev serio_raw power_meter container processor button ext3 jbd mbcache dm_mod raid10 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 raid0 multipath linear md_mod sd_mod crc_t10dif sg usbhid sr_mod hid cdrom ata_generic hpsa ata_piix thermal uhci_hcd cciss ehci_hcd qla2xxx scsi_transport_fc libata scsi_tgt bnx2 usbcore qlcnic nls_base scsi_mod thermal_sys [last unloaded: scsi_wait_scan] [ 951.581772] Pid: 5801, comm: blkid Not tainted 2.6.32-5-amd64 #1 ProLiant DL380 G7 [ 951.581845] RIP: 0010:[] [(null)] (null) [ 951.581934] RSP: 0018:88071b9c5b80 EFLAGS: 00010006 [ 951.581989] RAX: 880e1ad3e880 RBX: 880e1a4888d0 RCX: [ 951.582054] RDX: 0002 RSI: 0001 RDI: 880e1a4888d0 [ 951.582116] RBP: 880e1a4888d0 R08: 880719cb33e8 R09: 880719f12840 [ 951.582175] R10: 000100027c26 R11: 88065b00 R12: 880e1a4888d0 [ 951.582234] R13: 0002 R14: 88071bcc1d60 R15: 88071bcc1c44 [ 951.582297] FS: 7f5c1037d740() GS:88001a50() knlGS: [ 951.582372] CS: 0010 DS: ES: CR0: 80050033 [ 951.582429] CR2: CR3: 00071b6d2000 CR4: 06e0 [ 951.582488] DR0: DR1: DR2: [ 951.582546] DR3: DR6: 0ff0 DR7: 0400 [ 951.582606] Process blkid (pid: 5801, threadinfo 88071b9c4000, task 88071a31bf90) [ 951.582680] Stack: [ 951.582729] 8117629e 88071bbd7dc8 81176c40 88071bbd7dc8 [ 951.582885] 0 88071bbd7dc8 880e1a4888d0 0096 88071bcc1c00 [ 951.583118] 0 8117dec9 88071bbd7dc8 c9000c8da040 88071a2fac10 [ 951.583397] Call Trace: [ 951.583452] [8117629e] ? elv_drain_elevator+0x16/0x5a [ 951.583510] [81176c40] ? elv_insert+0x91/0x260 [ 951.583568] [8117dec9] ? blk_insert_cloned_request+0x4f/0x67 [ 951.583630] [a022d90f] ? dm_dispatch_request+0x33/0x59 [dm_mod] [ 951.583691] [a022eedb] ? dm_request_fn+0x121/0x1a2 [dm_mod] [ 951.583752] [810b43e3] ? sync_page_killable+0x0/0x2f [ 951.583810] [8117f07a] ? generic_unplug_device+0x21/0x34 [ 951.583870] [a022dac8] ? dm_unplug_all+0x33/0x4c [dm_mod] [ 951.583928] [810b43d9] ? sync_page+0x3c/0x46 [ 951.583984] [810b43ec] ? sync_page_killable+0x9/0x2f [ 951.584043] [812fb80a] ? __wait_on_bit_lock+0x3f/0x84 [ 951.584101] [810b42e8] ? __lock_page_killable+0x5d/0x63 [ 951.584160] [81064fc0] ? wake_bit_function+0x0/0x23 [ 951.584217] [810b42f7] ? lock_page_killable+0x9/0x1f [ 951.584274] [810b5917] ? generic_file_aio_read+0x363/0x536 [ 951.584334] [810eed05] ? do_sync_read+0xce/0x113 [ 951.584391] [81064f92] ? autoremove_wake_function+0x0/0x2e [ 951.584451] [810ccd36] ? handle_mm_fault+0x3b8/0x80f [ 951.584508] [810ef728] ? vfs_read+0xa6/0xff [ 951.584564] [810ef83d] ? sys_read+0x45/0x6e [ 951.584621] [81010b42] ? system_call_fastpath+0x16/0x1b [ 951.584677] Code: Bad RIP value. [ 951.584795] RIP [(null)] (null) [ 951.584879] RSP 88071b9c5b80 [ 951.584932] CR2: [ 951.584985] ---[ end trace 71dd7f009a29d813 ]--- As I'm adding back the old paths pretty much at the same time it seems for me that blkid wants to access ond of the devices I've just removed. But that should not result in a NULL pointer dereference, also it should not render the access to the LUN faulty, completely forgetting about the kind of hardware behind it. lun_alias (980006470684a65693038) dm-1 , size=4.9T features='0' hwhandler='0' wp=rw |-+- policy='round-robin 0' prio=0 status=active | |- #:#:#:# - #:# active faulty running | `- #:#:#:# - #:# active faulty running `-+- policy='round-robin 0' prio=0 status=enabled |- #:#:#:# - #:# active faulty running `- #:#:#:# - #:# active faulty running The expected output of multipath -ll would be more like
Bug#646889: linux-image-2.6.32-5-686: Since I'm using nfsd instead of samba a kerneloops occurs when accessing the files on server
On Mon, 31 Oct 2011 13:48:55 + Ben Hutchings b...@decadent.org.uk wrote: Different problem. For some reason the network stack is reallocating a large buffer. You may be able to work around this by disabling TSO (ethtool -K eth0 tso off). I’ll give it a try. But I wonder why it's necessary to reallocate. Are you using iptables or a packet-transformation facility? No, I’m not using iptables or anything similar on this machine. Marc -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111031151419.09e5de0a@nibbler
Bug#631664: Wishlist: Add support for software-rf-switch in Fujitsu-Siemens notebook
On Sun, 2011-10-16 at 22:25 +0200, Tino Schmidt wrote:
[...]
Hi,
I'm sorry for the long delay but I can use the laptop only on weekend.
Here is the output:
# modprobe wistron_btns force=1
FATAL: Error inserting wistron_btns
(/lib/modules/2.6.26-2-686/kernel/drivers/input/misc/wistron_btns.ko):
No such device
It looks like this model is rather different, maybe not a Wistron design
at all.
I would prefer you to test against Linux 3.0, but it appears that the
model detection has not changed since 2.6.26.
# dmesg
[ 168.628474] wistron_btns: BIOS entry point not found
and
# grep . /sys/class/dmi/id/*_{vendor,name,version}
/sys/class/dmi/id/bios_vendor:FUJITSU SIEMENS
/sys/class/dmi/id/board_vendor:FUJITSU SIEMENS
/sys/class/dmi/id/chassis_vendor:FUJITSU SIEMENS
/sys/class/dmi/id/sys_vendor:FUJITSU SIEMENS
/sys/class/dmi/id/board_name:AMILO A1655
/sys/class/dmi/id/product_name:AMILO A Series
/sys/class/dmi/id/bios_version:1.0C-8044-8A20
/sys/class/dmi/id/board_version:Rev0.4b
/sys/class/dmi/id/chassis_version:N/A
/sys/class/dmi/id/product_version:0100
Please build and test the attached driver (make insmod
amilo-rfkill.ko). It provides a standard rfkill device which you can
control with e.g. the 'rfkill' command, and will only bind to specific
models.
If this works, I'll submit the code upstream.
Ben.
Hi Ben,
Thank you for your code!
Before I built the module (Kernel 2.6.32) I had to insert the include
line #include asm/io.h ( - inb()-function ?)
With Kernel 2.6.26 I couldn't even built the module.
But loading of the module failed:
# insmod amilo-rfkill.ko
insmod: error inserting 'amilo-rfkill.ko': -1 No such device
In kernel 2.6.32 exists /dev/rfkill but
# rfkill list
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: yes
# rfkill unblock all
# rfkill list
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: yes
doesn't work here. Nothing changed.
Thanks,
Tino
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4eaedb1a.3070...@gmx.net
Bug#647136: linux-image-2.6.32-5-amd64: psmouse.c bad data from KBD bad parity
On 31 October 2011 14:57, Jonathan Nieder jrnie...@gmail.com wrote: Arvind K wrote: -By modprobe psmouse I meant that, whenever the touchpad stops working, I have to run the following: $sudo modprobe -r psmouse $sudo modprobe psmouse I see. [...] [36521.371269] psmouse.c: bad data from KBC - bad parity [36521.373636] psmouse.c: bad data from KBC - bad parity [... and so on, once every 2ms or so ...] Yep, that sounds broken. :) [...] [36552.047333] psmouse.c: bad data from KBC - bad parity [36556.015679] Synaptics Touchpad, model: 1, fw: 7.2, id: 0x1c0b1, caps: 0xd04731/0xa4/0xa [36556.058547] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio4/input/input13 I assume this is when you unloaded and reloaded the driver. It would also be interesting to see the initialization sequence (i.e., dmesg output from bootup) when nothing is going wrong. The log you sent is abridged at the beginning because the parity errors flooded the log. What version of gsynaptics are you using? Based on [1], it seems that gsynaptics does not work with a modern X server (though that is no excuse to provoke parity errors like this). Michal, any hints about what gsynaptics could have been doing to provoke this (e.g., a simpler command to simulate what it does)? It would also still be interesting to see what a recent (3.x) kernel does. I have a vague suspicion that v2.6.34-rc7~22^2~8 (Input: psmouse - ignore parity error for basic protocols, 2010-04-19) or some similar fix could have changed the behavior here. So should I boot again, and just send that log? I just installed gsynaptics from the debian repo. The version is 1.5.1-3 I will install 3.x, asap. I have actually installed 2.6.39 from backports. Have to test that out first.
Re: [PATCH 2/2] module: Re-enable dynamic debugging for GPL-compatible OOT modules
On Mon, 31 Oct 2011 13:44:17 +, Ben Hutchings b...@decadent.org.uk wrote: Non-text part: multipart/signed On Mon, 2011-10-31 at 12:29 +1030, Rusty Russell wrote: On Fri, 28 Oct 2011 04:38:14 +0100, Ben Hutchings b...@decadent.org.uk wrote: Dynamic debugging was enabled for GPL-compatible out-of-tree modules until my addition of TAINT_OOT_MODULE. It should continue to be enabled now. Please just remove the test entirely. AFAICT there's nothing unique to dynamic debug which means it should avoid taint. If it oopses, we'll learn all about tainting in the oops message. It looks like the dynamic debug facility is not meant to be available to proprietary modules. That was my guess too, but Mathieu (the author) said it was about malformed modules: On Wed, 26 Oct 2011 02:15:21 -0400: This check for tainted modules was first introduced with markers, and then used by tracepoints, and then also by dynamic debug. The rationale for this check was mainly to ensure that the marker/tracepoint code would not trigger a crash when loading a module with incompatible module header, originally compiled for an older kernel, into a newer kernel. This problem would happen even if the said module does not contain any marker/tracepoint, because we happen to try to use fields that are non-existent in the module header. This is pretty bogus: since they forced the module in the first place, they can handle the explosion. So we should drop it altogether. Thanks, Rusty. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r51svbit@rustcorp.com.au
Uploading linux-2.6 (3.0.0-6)
I intend to upload linux-2.6 version 3.0.0-6 to unstable today (Tuesday). This will include stable updates 3.0.7 and 3.0.8 and may require an ABI change (I haven't checked yet). It should fix the missing kernel-image udebs in 3.0.0-5, among other things. Ben. -- Ben Hutchings Computers are not intelligent. They only think they are. signature.asc Description: This is a digitally signed message part
[PATCH] module: Enable dynamic debugging regardless of taint
Dynamic debugging is currently disabled for tainted modules, except for TAINT_CRAP. This prevents use of dynamic debugging for out-of-tree modules now that they are also tainted. This condition was apparently intended to avoid a crash if a force- loaded module has an incompatible definition of dynamic debug structures. However, a administrator that forces us to load a module is claiming that it *is* compatible even though it fails our version checks. If they are mistaken, there are any number of ways the module could crash the system. Signed-off-by: Ben Hutchings b...@decadent.org.uk --- kernel/module.c |6 ++ 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/kernel/module.c b/kernel/module.c index dab585e..ef8cb70 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -2881,8 +2881,7 @@ static struct module *load_module(void __user *umod, } /* This has to be done once we're sure module name is unique. */ - if (!mod-taints || mod-taints == (1UTAINT_CRAP)) - dynamic_debug_setup(info.debug, info.num_debug); + dynamic_debug_setup(info.debug, info.num_debug); /* Find duplicate symbols */ err = verify_export_symbols(mod); @@ -2918,8 +2917,7 @@ static struct module *load_module(void __user *umod, module_bug_cleanup(mod); ddebug: - if (!mod-taints || mod-taints == (1UTAINT_CRAP)) - dynamic_debug_remove(info.debug); + dynamic_debug_remove(info.debug); unlock: mutex_unlock(module_mutex); synchronize_sched(); -- 1.7.7 -- Ben Hutchings Computers are not intelligent. They only think they are. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1320119973.30281.7.camel@deadeye
Bug#631664: Wishlist: Add support for software-rf-switch in Fujitsu-Siemens notebook
On Mon, 2011-10-31 at 18:30 +0100, Tino Schmidt wrote:
On Sun, 2011-10-16 at 22:25 +0200, Tino Schmidt wrote:
[...]
Hi,
I'm sorry for the long delay but I can use the laptop only on weekend.
Here is the output:
# modprobe wistron_btns force=1
FATAL: Error inserting wistron_btns
(/lib/modules/2.6.26-2-686/kernel/drivers/input/misc/wistron_btns.ko):
No such device
It looks like this model is rather different, maybe not a Wistron design
at all.
I would prefer you to test against Linux 3.0, but it appears that the
model detection has not changed since 2.6.26.
# dmesg
[ 168.628474] wistron_btns: BIOS entry point not found
and
# grep . /sys/class/dmi/id/*_{vendor,name,version}
/sys/class/dmi/id/bios_vendor:FUJITSU SIEMENS
/sys/class/dmi/id/board_vendor:FUJITSU SIEMENS
/sys/class/dmi/id/chassis_vendor:FUJITSU SIEMENS
/sys/class/dmi/id/sys_vendor:FUJITSU SIEMENS
/sys/class/dmi/id/board_name:AMILO A1655
/sys/class/dmi/id/product_name:AMILO A Series
/sys/class/dmi/id/bios_version:1.0C-8044-8A20
/sys/class/dmi/id/board_version:Rev0.4b
/sys/class/dmi/id/chassis_version:N/A
/sys/class/dmi/id/product_version:0100
Please build and test the attached driver (make insmod
amilo-rfkill.ko). It provides a standard rfkill device which you can
control with e.g. the 'rfkill' command, and will only bind to specific
models.
If this works, I'll submit the code upstream.
Ben.
Hi Ben,
Thank you for your code!
Before I built the module (Kernel 2.6.32) I had to insert the include
line #include asm/io.h ( - inb()-function ?)
That should be linux/io.h, actually.
With Kernel 2.6.26 I couldn't even built the module.
But loading of the module failed:
# insmod amilo-rfkill.ko
insmod: error inserting 'amilo-rfkill.ko': -1 No such device
Sorry, I made the driver look for product name AMILO A1655 but that is
actually the board name. Could you try changing DMI_PRODUCT_NAME to
DMI_BOARD_NAME?
In kernel 2.6.32 exists /dev/rfkill but
# rfkill list
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: yes
# rfkill unblock all
# rfkill list
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: yes
doesn't work here. Nothing changed.
This is the rfkill device exposed by the regular wireless driver. Since
it doesn't know anything about the model-specific blocking behaviour, it
appears to treat it as hard-blocking. But that shouldn't matter if we
can get this new driver working.
Ben.
--
Ben Hutchings
Computers are not intelligent. They only think they are.
signature.asc
Description: This is a digitally signed message part
Bug#647249: linux-image-3.0.0-2-amd64: Dell Inspiron Mini 1018 is no longer able to enable wireless
Package: linux-2.6 Version: 3.0.0-5 Severity: normal Dear Maintainer, After I disable wireless via network-manager-gnome, I can't enable it again, I guess Fn+F2 does not disable rfkill as it should. # ifconfig wlan0 up SIOCSIFFLAGS: Operation not possible due to RF-kill # rfkill list 0: dell-wifi: Wireless LAN Soft blocked: yes Hard blocked: yes 1: phy0: Wireless LAN Soft blocked: no Hard blocked: yes I hope this bug report helps with the solution: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/697520 Any other information you need about this issue please don't hesitate to ask. Thanks in advance for your help! ;-) Regards, P.S. Currently the only way for me to get my wireless enabled again is reset the BIOS to the default settings. -- Package-specific info: ** Version: Linux version 3.0.0-2-amd64 (Debian 3.0.0-5) (b...@decadent.org.uk) (gcc version 4.5.3 (Debian 4.5.3-9) ) #1 SMP Fri Oct 7 20:48:45 UTC 2011 ** Command line: BOOT_IMAGE=/vmlinuz-3.0.0-2-amd64 root=/dev/mapper/debian-root ro quiet ** Tainted: O (4096) * Out-of-tree module has been loaded. ** Kernel log: [ 21.019929] input: PC Speaker as /devices/platform/pcspkr/input/input4 [ 21.037664] dcdbas dcdbas: Dell Systems Management Base Driver (version 5.6.0-3.2) [ 21.124660] i801_smbus :00:1f.3: PCI INT B - GSI 19 (level, low) - IRQ 19 [ 21.630553] [drm] Initialized drm 1.1.0 20060810 [ 22.036696] cfg80211: Calling CRDA to update world regulatory domain [ 22.073824] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 22.073841] i915 :00:02.0: setting latency timer to 64 [ 22.138310] i915 :00:02.0: irq 44 for MSI/MSI-X [ 22.138328] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 22.138335] [drm] Driver supports precise vblank timestamp query. [ 22.138467] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 22.472523] [drm] initialized overlay support [ 22.493161] fbcon: inteldrmfb (fb0) is primary device [ 22.536658] fixme: max PWM is zero. [ 22.543683] Console: switching to colour frame buffer device 128x37 [ 22.554015] fb0: inteldrmfb frame buffer device [ 22.554020] drm: registered panic notifier [ 22.558161] acpi device:01: registered as cooling_device2 [ 22.558507] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input5 [ 22.558686] ACPI: Video Device [IGD0] (multi-head: yes rom: no post: no) [ 22.558847] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [ 22.623237] Synaptics Touchpad, model: 1, fw: 7.4, id: 0x1e0b1, caps: 0xd04773/0xa4/0xa0400 [ 22.637552] Linux media interface: v0.10 [ 22.671085] Linux video capture interface: v2.00 [ 22.711405] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input6 [ 22.736546] uvcvideo: Found UVC 1.00 device Laptop_Integrated_Webcam_0.3M (04f2:b201) [ 22.751818] input: Laptop_Integrated_Webcam_0.3M as /devices/pci:00/:00:1d.7/usb1/1-4/1-4:1.0/input/input7 [ 22.752063] usbcore: registered new interface driver uvcvideo [ 22.752071] USB Video Class driver (v1.1.0) [ 22.772483] HDA Intel :00:1b.0: PCI INT A - GSI 22 (level, low) - IRQ 22 [ 22.772603] HDA Intel :00:1b.0: irq 45 for MSI/MSI-X [ 22.772673] HDA Intel :00:1b.0: setting latency timer to 64 [ 22.808546] rtl8192ce :07:00.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [ 22.808567] rtl8192ce :07:00.0: setting latency timer to 64 [ 22.952909] hda_codec: ALC272: BIOS auto-probing. [ 22.954300] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/input/input8 [ 22.956588] input: HDA Intel Headphone as /devices/pci:00/:00:1b.0/sound/card0/input9 [ 22.994463] ieee80211 phy0: Selected rate control algorithm 'rtl_rc' [ 22.996371] rtlwifi: wireless switch is on [ 24.702677] EXT4-fs (dm-1): re-mounted. Opts: (null) [ 24.917007] EXT4-fs (dm-1): re-mounted. Opts: errors=remount-ro [ 25.329621] loop: module loaded [ 25.993139] Adding 3903484k swap on /dev/mapper/debian-swap. Priority:-1 extents:1 across:3903484k [ 26.396388] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) [ 26.448864] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: (null) [ 27.941779] RPC: Registered named UNIX socket transport module. [ 27.941786] RPC: Registered udp transport module. [ 27.941791] RPC: Registered tcp transport module. [ 27.941795] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 28.043966] FS-Cache: Loaded [ 28.126813] FS-Cache: Netfs 'nfs' registered for caching [ 28.160977] Installing knfsd (copyright (C) 1996 o...@monad.swb.de). [ 28.570290] fuse init (API version 7.16) [ 30.954630] NET4: DECnet for Linux: V.2.5.68s (C) 1995-2003 Linux DECnet Project Team [ 30.955259] DECnet: Routing cache hash table of 1024 buckets, 16Kbytes [
Re: [PATCH] module: Enable dynamic debugging regardless of taint
On Tue, 01 Nov 2011 03:59:33 +, Ben Hutchings b...@decadent.org.uk wrote: Dynamic debugging is currently disabled for tainted modules, except for TAINT_CRAP. This prevents use of dynamic debugging for out-of-tree modules now that they are also tainted. This condition was apparently intended to avoid a crash if a force- loaded module has an incompatible definition of dynamic debug structures. However, a administrator that forces us to load a module is claiming that it *is* compatible even though it fails our version checks. If they are mistaken, there are any number of ways the module could crash the system. Signed-off-by: Ben Hutchings b...@decadent.org.uk Thanks, applied, unless Mathieu objects... Cheers, Rusty. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lis0v4ih@rustcorp.com.au
