Bug#611946: linux-2.6: 2.6.35 introduced lockups with ath9k
Jonathan,
On Sun, Jul 31, 2011 at 02:52, Jonathan Nieder jrnie...@gmail.com wrote:
I have tried with linux-image-2.6.38-bpo.2-amd64 and
linux-image-2.6.39-2-amd64
Thanks. Could you try this patch[1] if you have time for it, and
report back here or upstream[2]? [3] has instructions for testing
patches.
Sadly, I am going on vacations in a few hours. So I will not be able
to try this for a couple of weeks. I'll do it as soon as I get back.
For now, I am using this as a workaround that prevents the crashes:
$ cat /etc/pm/config.d/ath9k
SUSPEND_MODULES=${SUSPEND_MODULES} ath9k
Thanks.
---
Martín Ferrari
--
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/CAL60Pd8_m72rzNzH8sEWrzrFzDNwestwwq7_5+Wfd3=ywu3...@mail.gmail.com
Bug#577640: closed by maximilian attems m...@stro.at (Re: Bug#577640: Another oops + repost)
From: maximilian attems m...@stro.at To: 577640-d...@bugs.debian.org Date: Mon, 26 Jul 2010 09:10:04 +0200 Subject: Re: Bug#577640: Another oops + repost Version: 2.6.35-rc6 aboves version is sitting in NEW should hit archive soon, thus closing. thanks for report. Beware: after testing this, I had a kernel freeze, for which I still don't know the reason... (probably unrelated) -- Martín Ferrari -- 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/aanlkti=qjn67wpl_0dnqhnqbnla+mm-wicadrhatr...@mail.gmail.com
Bug#577640: Another oops + repost
Hi, On Thu, Jul 22, 2010 at 18:43, Eric W. Biederman ebied...@xmission.com wrote: First of all, I would like to know if anybody was able to fix this problem that got kinda lost in the thread: I can't reproduce this on 2.6.35-rc1+ Can you please test a 2.6.35-rc version? If you can still reproduce it there can you send me your .config? Otherwise I expect my last round of changes to sysfs fixed whatever was the underlying problem. I just download and compiled rc6, and all of these problems seem to be solved. Thanks a lot! -- Martín Ferrari -- 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/aanlktimc8q6_zu60vx5smxgqsd+rcpf4raf3mlqpt...@mail.gmail.com
Bug#577640: Another oops + repost
Hi again,
First of all, I would like to know if anybody was able to fix this
problem that got kinda lost in the thread:
On Thu, Apr 22, 2010 at 16:05, Martín Ferrari martin.ferr...@gmail.com wrote:
I have just downloaded and compiled 2.6.32-2 and 2.6.34-rc5 from
kernel.org using the .config from the debian package, and the oops is
reproducible in both.
This small C file reproduces the error every time:
$ cat netnsoops.c
#include stdio.h
#include stdlib.h
#define _GNU_SOURCE
#include sched.h
int main(int argc, char *argv[])
{
int c;
unsigned long flags = CLONE_NEWNET;
if(unshare(flags) == -1) {
perror(unshare);
return 1;
}
system(ip link add name FOO type veth peer name BAR);
system(ip link set FOO netns 1);
system(ip link show);
return 0;
}
Secondly, I discovered another related bug, just more subtle.
I'm creating a dummy device, moving it into a name space and then
taking it back to netns 1. Later, when I delete the dummy, I get an
oops:
[ 610.540091] BUG: unable to handle kernel NULL pointer dereference
at 0028
[ 610.541512] IP: [81138f71] sysfs_find_dirent+0x9/0x2f
[ 610.542369] PGD 3799d067 PUD 37bb3067 PMD 0
[ 610.543370] Oops: [#1] SMP
[ 610.544018] last sysfs file: /sys/devices/virtual/net/lo/operstate
[ 610.544018] CPU 0
[ 610.544018] Modules linked in: dummy loop parport_pc parport
snd_pcm snd_timer tpm_tis tpm tpm_bios snd soundcore snd_page_alloc
pcspkr psmouse serio_raw i2c_piix4 evdev i2c_core button processor
ext3 jbd mbcache ide_cd_mod cdrom ide_gd_mod ata_generic ata_piix
8139too libata scsi_mod floppy piix 8139cp mii thermal thermal_sys
ide_core [last unloaded: scsi_wait_scan]
[ 610.544018]
[ 610.544018] Pid: 1359, comm: ip Tainted: GW 2.6.34-rc5 #1 /
[ 610.544018] RIP: 0010:[81138f71] [81138f71]
sysfs_find_dirent+0x9/0x2f
[ 610.544018] RSP: 0018:88003789f988 EFLAGS: 00010296
[ 610.544018] RAX: 88003789e000 RBX: RCX: 88007d3d2cd8
[ 610.544018] RDX: 0003 RSI: 814a6352 RDI:
[ 610.544018] RBP: 814a6352 R08: 00037f80e800 R09: 88007d3d2ce8
[ 610.544018] R10: 88007d3d2800 R11: 0006 R12: 814a6352
[ 610.544018] R13: 88007d3d2c48 R14: R15: 88003789fbb8
[ 610.544018] FS: 7f22855f7700() GS:880001a0()
knlGS:
[ 610.544018] CS: 0010 DS: ES: CR0: 8005003b
[ 610.544018] CR2: 0028 CR3: 7d4df000 CR4: 06f0
[ 610.544018] DR0: DR1: DR2:
[ 610.544018] DR3: DR6: 0ff0 DR7: 0400
[ 610.544018] Process ip (pid: 1359, threadinfo 88003789e000,
task 88007d2b69f0)
[ 610.544018] Stack:
[ 610.544018] 00037f80e800
81138fbb
[ 610.544018] 0 0296 88007d3d2c38 816698d0
8113a980
[ 610.544018] 0 88007d3d2c38 88007d3d2c38 88007d3d2800
[ 610.544018] Call Trace:
[ 610.544018] [81138fbb] ? sysfs_get_dirent+0x24/0x43
[ 610.544018] [8113a980] ? sysfs_remove_group+0x24/0xcf
[ 610.544018] [8120f776] ? device_del+0x3b/0x1a0
[ 610.544018] [81244139] ? rollback_registered_many+0x15d/0x1c8
[ 610.544018] [8124d81e] ? rtnetlink_rcv_msg+0x0/0x1f5
[ 610.544018] [81244273] ? unregister_netdevice_queue+0x78/0xa9
[ 610.544018] [8124c22b] ? rtnl_dellink+0xb7/0xdb
[ 610.544018] [8125e887] ? netlink_rcv_skb+0x34/0x7c
[ 610.544018] [8124d818] ? rtnetlink_rcv+0x1f/0x25
[ 610.544018] [8125e67b] ? netlink_unicast+0xe2/0x148
[ 610.544018] [8125edaf] ? netlink_sendmsg+0x23f/0x252
[ 610.544018] [8123388d] ? sock_sendmsg+0x83/0x9b
[ 610.544018] [810b3e0d] ? __alloc_pages_nodemask+0x10f/0x5e2
[ 610.544018] [8123c76f] ? copy_from_user+0x13/0x25
[ 610.544018] [8123cb25] ? verify_iovec+0x49/0x84
[ 610.544018] [81233b62] ? sys_sendmsg+0x225/0x2af
[ 610.544018] [81234e17] ? sys_recvmsg+0x48/0x56
[ 610.544018] [81008ac2] ? system_call_fastpath+0x16/0x1b
[ 610.544018] Code: fb 74 1a 8b 07 85 c0 75 11 be 9d 00 00 00 48 c7
c7 da 56 4b 81 e8 2b cf f0 ff f0 ff 03 48 89 d8 5b c3 55 48 89 f5 53
48 83 ec 08 48 8b 5f 28 eb 14 48 8b 7b 18 48 89 ee e8 46 a4 04 00 85
c0 74
[ 610.544018] RIP [81138f71] sysfs_find_dirent+0x9/0x2f
[ 610.544018] RSP 88003789f988
[ 610.544018] CR2: 0028
[ 610.597008] ---[ end trace f92104e98ea87a47 ]---
To reproduce:
$ cat netnsoops2.c
#include stdio.h
#include stdlib.h
#include unistd.h
#include sys/wait.h
#define _GNU_SOURCE
#include sched.h
int main(int argc, char *argv[])
{
int pipefd[2];
pid_t pid
Bug#577640: linux-image-2.6.33-2-amd64: Kernel warnings in netns thread
On Thu, Apr 22, 2010 at 04:38, Eric W. Biederman ebied...@xmission.com wrote:
$ sudo ./startns bash
# ip l a type veth
# ip l s veth0 netns 1
# exit
Then I should ask what is startns?
That's just a simple C program that calls unshare(CLONE_NEWNET) and
execs a shell.
Either that is doing something different from my equivalent program, or I have
patches to fix this, that just haven't been merged yet.
I have just downloaded and compiled 2.6.32-2 and 2.6.34-rc5 from
kernel.org using the .config from the debian package, and the oops is
reproducible in both.
This small C file reproduces the error every time:
$ cat netnsoops.c
#include stdio.h
#include stdlib.h
#define _GNU_SOURCE
#include sched.h
int main(int argc, char *argv[])
{
int c;
unsigned long flags = CLONE_NEWNET;
if(unshare(flags) == -1) {
perror(unshare);
return 1;
}
system(ip link add name FOO type veth peer name BAR);
system(ip link set FOO netns 1);
system(ip link show);
return 0;
}
--
Martín Ferrari
--
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/y2kb9800b71004220705s4db40c4csb3923b61f9ae8...@mail.gmail.com
Bug#577640: linux-image-2.6.33-2-amd64: Kernel warnings in netns thread
, comm: netns Tainted: G W 2.6.33-2-amd64 #1 [ 6696.035355] Call Trace: [ 6696.035357] [8104e303] ? unregister_sysctl_table+0xa6/0xd1 [ 6696.035360] [8104e303] ? unregister_sysctl_table+0xa6/0xd1 [ 6696.035362] [81046b81] ? warn_slowpath_common+0x77/0xa3 [ 6696.035364] [8104e303] ? unregister_sysctl_table+0xa6/0xd1 [ 6696.035367] [812b1205] ? addrconf_ifdown+0x26f/0x2cc [ 6696.035369] [81247edc] ? neigh_sysctl_unregister+0x1a/0x31 [ 6696.035371] [812b1211] ? addrconf_ifdown+0x27b/0x2cc [ 6696.035374] [812b2b0c] ? addrconf_notify+0x714/0x7ea [ 6696.035376] [811eb2e7] ? extract_entropy+0x6a/0x125 [ 6696.035379] [81053aaf] ? lock_timer_base+0x26/0x4b [ 6696.035382] [8123951c] ? skb_dequeue+0x50/0x58 [ 6696.035384] [812482c8] ? pneigh_queue_purge+0x25/0x2f [ 6696.035386] [81249a91] ? neigh_ifdown+0xba/0xc9 [ 6696.035389] [81062f6d] ? notifier_call_chain+0x29/0x4c [ 6696.035392] [81243662] ? rollback_registered_many+0xed/0x19c [ 6696.035394] [8124371f] ? unregister_netdevice_many+0xe/0x57 [ 6696.035397] [812438a3] ? default_device_exit_batch+0x92/0xa3 [ 6696.035399] [8123e97a] ? cleanup_net+0xfd/0x1af [ 6696.035402] [8105bd0d] ? worker_thread+0x188/0x21d [ 6696.035404] [8123e87d] ? cleanup_net+0x0/0x1af [ 6696.035406] [8105f2d2] ? autoremove_wake_function+0x0/0x2e [ 6696.035409] [8105bb85] ? worker_thread+0x0/0x21d [ 6696.035411] [8105ee99] ? kthread+0x79/0x81 [ 6696.035414] [810098e4] ? kernel_thread_helper+0x4/0x10 [ 6696.035416] [8105ee20] ? kthread+0x0/0x81 [ 6696.035418] [810098e0] ? kernel_thread_helper+0x0/0x10 [ 6696.035419] ---[ end trace ef7b93cb006e989e ]--- [...] -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. -- Martín Ferrari -- 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/o2jb9800b71004210819t6ca61099y17be143527ccb...@mail.gmail.com
Bug#40346: Reassigning 8 years old still present bug
Hi again, On 4/6/07, Bernd Eckenfels [EMAIL PROTECTED] wrote: I can reproduce it, but it doesn't seem to be net-tools fault, as the interface is correctly removed (ifconfig and ip a l doesn't list it anymore). I'm not even sure if this is a bug or not, but I think it's up to kernel maintainers to decide on that. This is often explained on linux-net in the last time. It is due to linux host (instead of interface) based addressing model. You need to remove the address instead of downing the interface. Removing is not currently supported by ifconfig for ipv4. So it is somewhat a net-tools bug. I kept testing this one. And ifconfig does the same as ip addr del: it removes the address! And the connection, even when still exists to the socket layer, cannot transfer anything: incoming packets ignored, outgoing packets not sent (I don't know if they stall in a queue or are discarded), ping ignored, arp unanswered. So, I don't know why you say that this doesn't work for ifconfig. I now think that the bug should be closed for good. -- Martín Ferrari
Bug#40346: Reassigning 8 years old still present bug
On 4/6/07, Bernd Eckenfels [EMAIL PROTECTED] wrote: On Fri, Apr 06, 2007 at 07:31:51PM -0300, Martín Ferrari wrote: I kept testing this one. And ifconfig does the same as ip addr del: it removes the address! you mean ifconfig eth0 0 down, or how do you remove the ip with ifconfig? I did ifconfig eth0:0 down and it worked just ok. Recent Discussion: http://www.mail-archive.com/linux-net@vger.kernel.org/msg01235.html But I think that there is something different being discussed: pinging a local address in an inactive interface. Or I misread this bug, but I think the problem was remote pinging to a supposedly removed address. And that's what AJ tested back on the day. -- Martín Ferrari
Bug#40346: Reassigning 8 years old still present bug
On 4/6/07, Bernd Eckenfels [EMAIL PROTECTED] wrote: On Fri, Apr 06, 2007 at 10:31:07PM -0300, Martín Ferrari wrote: But I think that there is something different being discussed: pinging a local address in an inactive interface. Or I misread this bug, but I think the problem was remote pinging to a supposedly removed address. And that's what AJ tested back on the day. Well, maybe it is different, dont know. Hosts react to ip addresses even if the associated interface is down. Thats by definition and might be related to the bug. Yeah, that's by design. But currently, ifconfig is deleting the address as expected when you down an alias... So, what can be done with this bug? I'd close it as done. -- Martín Ferrari
Bug#252289: weird clock
Hi! I want to report that I'm having a very similar problem since some months ago. It is a woody install, with 2.4.18 stock debian kernel. It doesn´t freeze, but the clock derives very quickly from real time. I have just checked the timer interrupt, and it seems that it's ticking at 99Hz. The computer has a PS/2 KVM-switch plugged (it emulates a real keyboard). Any recommendation? quebracho:~# uname -a Linux quebracho 2.4.18-1-686 #1 Wed May 17 21:26:54 UTC 2006 i686 unknown quebracho:~# ntpdate pool.ntp.org; date; grep timer /proc/interrupts 2 Jul 00:25:22 ntpdate[22616]: adjust time server 194.88.2.50 offset 0.445936 sec Sun Jul 2 00:25:22 ART 2006 0: 71271791IO-APIC-edge timer quebracho:~# sleep 300 ; ntpdate pool.ntp.org; date; grep timer /proc/interrupts 2 Jul 00:30:44 ntpdate[22839]: step time server 193.224.70.7 offset 1.868128 sec Sun Jul 2 00:30:44 ART 2006 0: 71303713IO-APIC-edge timer quebracho:~# bc bc 1.06 Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. sacle = 3 (71303713-71271791)/322 99 quebracho:~# cat /proc/interrupts CPU0 0: 71318403IO-APIC-edge timer 1:502IO-APIC-edge keyboard 2: 0 XT-PIC cascade 8: 3IO-APIC-edge rtc 14: 96936927IO-APIC-edge ide0 15: 96939199IO-APIC-edge ide1 17: 147105499 IO-APIC-level eth0 NMI: 0 LOC: 71817675 ERR: 0 MIS: 0 -- Martín Ferrari
Bug#330081: Possible fix
As I said in #343521, I had problems with this exact linux-headers version when compiling zaptel-source with module-assistant, and when compiling cxacru (non-debian) with make (make -C /usr/src/linux-headers-2.6.12-1-686/ SUBDIR=`pwd` modules). In both cases, the version was set to 2.6.12 instead of 2.6.12-1-686, generating wrong module information, and installing in the wrong modules directory. I saw that in pre-2.6.12 kernel-headers packages, in the file include/linux/version.h would define UTS_RELEASE with the complete version, including extraversion, as you can see: /usr/src/kernel-headers-2.6.10-1-386/include/linux/version.h: #define UTS_RELEASE 2.6.10-1-386 /usr/src/kernel-headers-2.6.10-1/include/linux/version.h: #define UTS_RELEASE 2.6.10-1 /usr/src/kernel-headers-2.6.11-1-386/include/linux/version.h: #define UTS_RELEASE 2.6.11-1-386 /usr/src/kernel-headers-2.6.11-1/include/linux/version.h: #define UTS_RELEASE 2.6.11-1 In linux-image-2.6.12 this was not the case: the extraversion was not present in UTS_RELEASE. I don't know if this was intentional, but changing that value, solved all my module-compiling problems. Regards, Martín. -- Martín Ferrari
