Bug#596170: arno-iptables-firewall: local ipv6 no longer works
On Fri, 10 Sep 2010, Michael Hanke wrote: On Fri, Sep 10, 2010 at 09:46:38AM +0200, Arno van Amersfoort wrote: Carlos: Can you test this? Michael: Can you apply these changes to our aif version in Sqeeuze? I have backported and slightly simplified the patch. A new .deb and the backported patch are attached. Please let me know if it works. Arno and Michael, Thanks again for the fixes and the update package. I have tested it, and it seems to work as expected. Rules are no longer left behind and ipv6 works on internal interfaces. Regards, Carlos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#596170: arno-iptables-firewall: local ipv6 no longer works
On Thu, 9 Sep 2010, Michael Hanke wrote: Thanks for the patch. I have backported the patch to 1.9.2k. I'm attaching the backported patch, the full diff for a tentative 1.9.2.k-4 package, as well as an updated .deb for 1.9.2.k-4 that is targeting Debian squeeze (for convenient testing). I'd be glad if you could check this and provide feedback whether it does what it should. On my system it looks reasonable now: Thanks for the updated package. I can confirm that wxmaxima now works again, and I can ping6 ip6-localhost as well. I have noticed that old ipv6 rules are not purged when stopping or restarting arno-iptables-firewall, leading to rules accumulating on restart and unexpected behaviour on stop (no external ipv6 traffic is possible). The following is after restarting arno-iptables-firewall twice. moewe:~# ip6tables -L -v Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 32 2240 ACCEPT all lo any anywhere anywhere 0 0 ACCEPT all lo any anywhere anywhere 0 0 ACCEPT all lo any anywhere anywhere Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all lo any anywhere anywhere 0 0 ACCEPT all lo any anywhere anywhere 0 0 ACCEPT all lo any anywhere anywhere Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination I have not yet checked whether interfaces declared as internal are affected. I will do, and report again. Many thanks, Carlos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#596170: arno-iptables-firewall: local ipv6 no longer works
On Thu, 9 Sep 2010, Carlos Fonseca wrote: I have not yet checked whether interfaces declared as internal are affected. I will do, and report again. OK, declaring an interface as internal using debconf seems to work as expected (ipv6 traffic is allowed on that interface). However, reconfiguring the package to declare it external again (and restarting the firewall) has no effect, because the old ipv6 rules are still there... Carlos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#596170: arno-iptables-firewall: local ipv6 no longer works
Package: arno-iptables-firewall Version: 1.9.2.k-3 Severity: important Tags: ipv6 After upgrading to this version, wxmaxima has become unusable. The reason is that, when it starts, it tries to connect to ip6-localhost:ipp and the connection gets stuck in SYN_SENT. Similarly, 'ping6 ::1' reports ping: sendmsg: Operation not permitted This seems to be a direct result of the fix for bug 594326, but shouldn't incoming ipv6 traffic be blocked only on *external* interfaces? Note that there is nothing listening on port ipp on this machine. Previously, wxmaxima would just report an error and continue...) Thanks, Carlos -- System Information: Debian Release: squeeze/sid APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=pt_PT.UTF-8, LC_CTYPE=pt_PT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages arno-iptables-firewall depends on: ii debconf [debconf-2.0] 1.5.35 Debian configuration management sy ii gawk 1:3.1.7.dfsg-5 GNU awk, a pattern scanning and pr ii iproute 20100519-3 networking and traffic control too ii iptables 1.4.8-3administration tools for packet fi Versions of packages arno-iptables-firewall recommends: ii dnsutils 1:9.7.1.dfsg.P2-2 Clients provided with BIND ii lynx 2.8.8dev.5-1 Text-mode WWW Browser (transitiona arno-iptables-firewall suggests no packages. -- debconf information: arno-iptables-firewall/title: * arno-iptables-firewall/debconf-wanted: true arno-iptables-firewall/config-int-nat-net: * arno-iptables-firewall/dynamic-ip: true * arno-iptables-firewall/config-int-net: * arno-iptables-firewall/icmp-echo: false * arno-iptables-firewall/services-udp: * arno-iptables-firewall/config-ext-if: eth0 wlan0 ppp+ eth1 eth2 * arno-iptables-firewall/services-tcp: * arno-iptables-firewall/restart: true * arno-iptables-firewall/config-int-if: * arno-iptables-firewall/nat: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593870: udev: No medium found in Huawei E169 GSM modem's MicroSD card reader
On Sat, 21 Aug 2010, Marco d'Itri wrote: Is a partition needed or not? In your first message you tried to mount the raw device. A partition is needed. Since only /dev/sdb was available, I was only trying to force reading the device, in the hope that the partition table would be read. Did the kernel actually report reading a partition table on the card? Does /sys/block/sdb/sdb1/ exist? If it does, does "echo add > /sys/block/sdb/sdb1/uevent" create the device? /sys/block/sdb/sdb1/ does (did) not exist... It this does not, will a manually created sdb1 work? A manually created sdb1 would report "no medium found" as well. Apparently, the problem is related to hal. I found that hal specifically ignores the storage side of this modem due to the following section in /usr/share/hal/fdi/preprobe/10osvendor/20-broken-usb-sticks.fdi int="0x1001"> true The other machines had an older version of hal-info installed, and were polling /dev/sdb for media changes. Eventually, the card got detected. Removing that section from the above file seems to fix it. Whether that should be needed, I don't know. In addition, there seems to be some kind of interation between media detection in the card reader (which is LUN 1 of the device), and whether the "CD-ROM" (LUN 0) has been accessed or not, but since it is working right now, perhaps this bug can be closed. Thanks, Carlos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593870: udev: No medium found in Huawei E169 GSM modem's MicroSD card reader
On Sat, 21 Aug 2010, Marco d'Itri wrote: If the device exists, udev is done doing its stuff (unless you have specific reasons to believe otherwise and a theory). I have tried to narrow it down as much as possible before reporting this. As far as I could see, there were many changes to the way udev handles storage devices between 154-1 and 160-1/161-1. Somehow, udev 154-1 finds the partition on the card and creates a device for it, udev 161-1 doesn't. It may be that the previous way of detecting the card on the device worked and the new way isn't working on this device. Is it possible to download the 154-1 and later debian sources from somewhere, so that I can build the debian package and try downgrading until I identify the first version that no longer works? Is there anything specific I can do to debug this? Thanks, Carlos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593870: udev: No medium found in Huawei E169 GSM modem's MicroSD card reader
On Sat, 21 Aug 2010, Marco d'Itri wrote: You need usb-modeswitch. I am sorry, but I do not think so. The modem devices are available, so the device has already switched modes (the kernel does it in this case). The storage devices are available as well, I can access the "CD-ROM" with the Windows drivers, and I can access the card reader via /dev/sdb. I just can't read the card, because it is not detected for some reason. The same kernel and a previous udev version work fine. Why should usb-modeswitch be needed? Thanks, Carlos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593870: udev: No medium found in Huawei E169 GSM modem's MicroSD card reader
Package: udev Version: 161-1 Severity: normal My Huawei E169 GSM modem has a built-in micro-sd card reader. On a current squeeze installation, the reader is detected and the corresponding device file (/dev/sdb) is created. However, no device is created for the partition of the card, which is apparently never read. Trying to force a "mount /dev/sdb /mnt" results in a "mount: no medium found on /dev/sdb", although the card is inserted. I have tried the modem on different debian machines, and the card is reliably detected on a 32-bit, mostly lenny installation with a current squeeze kernel and udev 154-1, as well as on pure lenny installation. Unfortunately, I cannot find the 154-1 version of the amd64 udev package on the internet anymore, or I would have tried downgrading. Regards, Carlos -- System Information: Debian Release: squeeze/sid APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.35-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=pt_PT (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages udev depends on: ii debconf [debconf-2.0]1.5.35 Debian configuration management sy ii libc62.11.2-2Embedded GNU C Library: Shared lib ii libselinux1 2.0.96-1SELinux runtime shared libraries ii libudev0 161-1 libudev shared library ii libusb-0.1-4 2:0.1.12-15 userspace USB programming library ii lsb-base 3.2-23.1Linux Standard Base 3.2 init scrip ii util-linux 2.17.2-3.1 Miscellaneous system utilities Versions of packages udev recommends: ii pciutils 1:3.1.7-4 Linux PCI Utilities ii usbutils 0.87-5 Linux USB utilities udev suggests no packages. -- Configuration Files: /etc/modprobe.d/blacklist.conf changed: blacklist evbug blacklist usbmouse blacklist usbkbd blacklist eepro100 blacklist de4x5 blacklist am53c974 blacklist iTCO_wdt blacklist pcspkr -- debconf information: udev/new_kernel_needed: false udev/title/upgrade: udev/reboot_needed: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#526983: 'official' realtek driver works for me
Zach Sadecki wrote: I built and installed the Realtek 8168 driver version 8.018.00 from the Realtek site and the problem has gone away. Thanks for the suggestion. I have downloaded version 8.018.00 of the r8101 driver (my chip is an RTL8101e) from the Realtek site, and have tried it with kernel linux-image-2.6.32-5-amd64 version 2.6.32-20. However, the problem persists: the network card hangs shortly after starting a large rsync. The main difference is that dmesg shows nothing, but suspending to RAM and resuming fixes it just as with the default driver. In addition, while testing the Realtek r8101 driver, I got the following rsync error once, right after enting the password for the remote machine: Received disconnect from UNKNOWN: 2: Corrupted MAC on input. rsync: writefd_unbuffered failed to write 4 bytes to socket [generator]: Broken pipe (32) rsync error: unexplained error (code 255) at io.c(1530) [generator=3.0.7] rsync error: received SIGUSR1 (code 19) at main.c(1306) [receiver=3.0.7] On the second try, the network just hung... I am going back to using the default driver. Carlos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#526983: linux-image-2.6.29-1-amd64: NETDEV WATCHDOG: eth0 (r8169): transmit timed out
On Mon, 15 Feb 2010, Moritz Muehlenhoff wrote: Please report this upstream at http://bugzilla.kernel.org (Product: Drivers, Component: Network) and send us the bug number. I have just added some additional info to http://bugzilla.kernel.org/show_bug.cgi?id=14962 which seems to be the same bug (it refers to debian bug 528362, which has been merged with this one). Basically, the problem is still present in 2.6.35-1~experimental.1. Sorry to have gone silent... Regards, Carlos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#526983: linux-image-2.6.29-1-amd64: NETDEV WATCHDOG: eth0 (r8169): transmit timed out
On Mon, 18 Jan 2010, Carlos Fonseca wrote: I have just installed linux-image-2.6.32-trunk-amd64_2.6.32-5, and will try to reproduce it with that kernel, as well. Here it goes. Carlos [ 588.804125] [ cut here ] [ 588.804141] WARNING: at /build/buildd-linux-2.6_2.6.32-5-amd64-9RvY2G/linux-2.6-2.6.32/debian/build/source_amd64_none/net/sched/sch_generic.c:261 dev_watchdog+0xe2/0x194() [ 588.804148] Hardware name: Satellite A110 [ 588.804153] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out [ 588.804157] Modules linked in: i915 drm_kms_helper drm i2c_algo_bit bridge stp bnep sco rfcomm l2cap crc16 bluetooth xt_multiport xt_state autofs4 cpufreq_stats cpufreq_userspace cpufreq_powersave cpufreq_conservative ipt_LOG iptable_mangle iptable_filter iptable_nat ip_tables nf_nat x_tables nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 fuse pcspkr coretemp acpi_cpufreq firewire_sbp2 loop snd_hda_codec_realtek snd_hda_intel snd_hda_codec arc4 snd_hwdep ecb snd_pcm_oss snd_mixer_oss snd_pcm joydev snd_seq_midi snd_rawmidi pcmcia snd_seq_midi_event battery container ac snd_seq snd_timer snd_seq_device video output iwl3945 iwlcore snd yenta_socket rsrc_nonstatic mac80211 pcmcia_core i2c_i801 psmouse soundcore rng_core cfg80211 serio_raw evdev processor button i2c_core snd_page_alloc intel_agp rfkill agpgart ext3 jbd mbcache dm_mirror dm_region_hash dm_log dm_snapshot dm_mod sg sr_mod cdrom sd_mod crc_t10dif ide_pci_generic ide_core ata_piix ata_generic sdhci_pci sdhci firewire_ohci firewire_core crc_itu_t mmc_core led_class libata scsi_mod r8169 mii uhci_hcd thermal fan thermal_sys ehci_hcd usbcore nls_base [last unloaded: scsi_wait_scan] [ 588.804341] Pid: 0, comm: swapper Not tainted 2.6.32-trunk-amd64 #1 [ 588.804345] Call Trace: [ 588.804349][] ? dev_watchdog+0xe2/0x194 [ 588.804361] [] ? dev_watchdog+0xe2/0x194 [ 588.804369] [] ? warn_slowpath_common+0x77/0xa3 [ 588.804375] [] ? dev_watchdog+0x0/0x194 [ 588.804382] [] ? warn_slowpath_fmt+0x51/0x59 [ 588.804390] [] ? enqueue_task_fair+0x24/0x69 [ 588.804398] [] ? activate_task+0x20/0x26 [ 588.804405] [] ? try_to_wake_up+0x249/0x259 [ 588.804412] [] ? netif_tx_lock+0x3d/0x69 [ 588.804419] [] ? netdev_drivername+0x3b/0x40 [ 588.804425] [] ? dev_watchdog+0xe2/0x194 [ 588.804432] [] ? __wake_up+0x30/0x44 [ 588.804441] [] ? run_timer_softirq+0x1c9/0x268 [ 588.804449] [] ? __do_softirq+0xdd/0x19f [ 588.804457] [] ? tick_dev_program_event+0x2d/0x95 [ 588.804465] [] ? call_softirq+0x1c/0x30 [ 588.804471] [] ? do_softirq+0x3f/0x7c [ 588.804478] [] ? irq_exit+0x36/0x76 [ 588.804486] [] ? smp_apic_timer_interrupt+0x87/0x95 [ 588.804492] [] ? apic_timer_interrupt+0x13/0x20 [ 588.804496][] ? acpi_idle_enter_bm+0x26a/0x29e [processor] [ 588.804520] [] ? acpi_idle_enter_bm+0x263/0x29e [processor] [ 588.804528] [] ? cpuidle_idle_call+0x95/0xee [ 588.804536] [] ? cpu_idle+0xa2/0xda [ 588.804542] ---[ end trace 84d7d31e6a0b75ae ]--- [ 588.820207] r8169: eth0: link up [ 600.820205] r8169: eth0: link up
Bug#526983: linux-image-2.6.29-1-amd64: NETDEV WATCHDOG: eth0 (r8169): transmit timed out
On Sun, 17 Jan 2010, Ben Hutchings wrote: I believe this bug was fixed in upstream version 2.6.32. This is now available in sid; please can you test it? Ben. I have just tried it with linux-image-2.6.32-trunk-amd64_2.6.32-4, and the timeout ocurred shortly after boot while rsyncing a large directory (see below). I have just installed linux-image-2.6.32-trunk-amd64_2.6.32-5, and will try to reproduce it with that kernel, as well. Is there anything else I can do to help debug this? Carlos [ 163.804080] [ cut here ] [ 163.804099] WARNING: at /build/buildd-linux-2.6_2.6.32-4-amd64-2Mp3BR/linux-2.6-2.6.32/debian/build/source_amd64_none/net/sched/sch_generic.c:261 dev_watchdog+0xe2/0x194() [ 163.804106] Hardware name: Satellite A110 [ 163.804111] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out [ 163.804115] Modules linked in: i915 drm_kms_helper drm i2c_algo_bit bridge stp bnep sco rfcomm l2cap crc16 bluetooth xt_multiport xt_state autofs4 cpufreq_stats cpufreq_userspace cpufreq_powersave cpufreq_conservative ipt_LOG iptable_mangle iptable_filter iptable_nat ip_tables nf_nat x_tables nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 fuse pcspkr coretemp acpi_cpufreq firewire_sbp2 loop snd_hda_codec_realtek snd_hda_intel snd_hda_codec arc4 snd_hwdep ecb snd_pcm_oss snd_mixer_oss snd_pcm joydev snd_seq_midi battery snd_rawmidi pcmcia snd_seq_midi_event snd_seq ac container snd_timer snd_seq_device iwl3945 video output iwlcore snd mac80211 yenta_socket rsrc_nonstatic pcmcia_core cfg80211 psmouse processor i2c_i801 soundcore intel_agp button evdev i2c_core serio_raw rng_core agpgart rfkill snd_page_alloc ext3 jbd mbcache dm_mirror dm_region_hash dm_log dm_snapshot dm_mod sg sr_mod cdrom sd_mod crc_t10dif ide_pci_generic ide_core ata_piix ata_generic sdhci_pci sdhci firewire_ohci firewire_core crc_itu_t mmc_core led_class libata scsi_mod r8169 mii uhci_hcd thermal fan thermal_sys ehci_hcd usbcore nls_base [last unloaded: scsi_wait_scan] [ 163.804299] Pid: 0, comm: swapper Not tainted 2.6.32-trunk-amd64 #1 [ 163.804303] Call Trace: [ 163.804307][] ? dev_watchdog+0xe2/0x194 [ 163.804321] [] ? dev_watchdog+0xe2/0x194 [ 163.804329] [] ? warn_slowpath_common+0x77/0xa3 [ 163.804337] [] ? dev_watchdog+0x0/0x194 [ 163.804343] [] ? warn_slowpath_fmt+0x51/0x59 [ 163.804351] [] ? enqueue_task_fair+0x24/0x69 [ 163.804359] [] ? activate_task+0x20/0x26 [ 163.804366] [] ? try_to_wake_up+0x249/0x259 [ 163.804374] [] ? netif_tx_lock+0x3d/0x69 [ 163.804381] [] ? netdev_drivername+0x3b/0x40 [ 163.804388] [] ? dev_watchdog+0xe2/0x194 [ 163.804394] [] ? __wake_up+0x30/0x44 [ 163.804403] [] ? run_timer_softirq+0x1c9/0x268 [ 163.804412] [] ? __do_softirq+0xdd/0x19f [ 163.804419] [] ? tick_dev_program_event+0x2d/0x95 [ 163.804427] [] ? call_softirq+0x1c/0x30 [ 163.804434] [] ? do_softirq+0x3f/0x7c [ 163.804441] [] ? irq_exit+0x36/0x76 [ 163.804449] [] ? smp_apic_timer_interrupt+0x87/0x95 [ 163.804456] [] ? apic_timer_interrupt+0x13/0x20 [ 163.804460][] ? hpet_legacy_next_event+0x0/0x7 [ 163.804480] [] ? acpi_idle_enter_bm+0x26a/0x29e [processor] [ 163.804491] [] ? acpi_idle_enter_bm+0x263/0x29e [processor] [ 163.804501] [] ? cpuidle_idle_call+0x95/0xee [ 163.804509] [] ? cpu_idle+0xa2/0xda [ 163.804514] ---[ end trace 5d93e39c12569cc1 ]--- [ 163.820195] r8169: eth0: link up [ 193.820254] r8169: eth0: link up [ 205.820192] r8169: eth0: link up [ 253.820265] r8169: eth0: link up
Bug#526983: linux-image-2.6.29-1-amd64: NETDEV WATCHDOG: eth0 (r8169): transmit timed out
On Sat, 25 Jul 2009, Moritz Muehlenhoff wrote: Looking at the commits for r8169.c, several look like they could've fixed this. Could you try 2.6.30 from unstable? Cheers, Moritz I have been using the kernels from http://kernel-archive.buildserver.net/debian-kernel and it continues to happen. I have also upgraded the BIOS in the meantime, but the only difference is that now, *sometimes*, the interface comes back to life shortly after the oops. Sometimes, it doesn't. The oops below happened with kernel 2.6.30-4~snapshot.13990. The interface did come back afterwards, so I did not have to suspend/resume, but this is *not* always the case. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.30-1-amd64 (Debian 2.6.30-4~snapshot.13990) (wa...@debian.org) (gcc version 4.3.3 (GCC) ) #1 SMP Thu Jul 23 02:29:33 UTC 2009 ... [ 88.642173] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [ 321.366720] ACPI: EC: GPE storm detected, transactions will use polling mode [ 321.865126] ACPI: EC: missing confirmations, switch off interrupt mode. [ 384.804112] [ cut here ] [ 384.804132] WARNING: at /build/linux-2.6-2.6.30/debian/build/source_amd64_none/net/sched/sch_generic.c:226 dev_watchdog+0xc7/0x164() [ 384.804138] Hardware name: Satellite A110 [ 384.804141] NETDEV WATCHDOG: eth0 (r8169): transmit timed out [ 384.804145] Modules linked in: i915 drm i2c_algo_bit bridge stp bnep sco rfcomm l2cap bluetooth xt_multiport xt_state autofs4 cpufreq_stats cpufreq_userspace cpufreq_powersave cpufreq_conservative ipt_LOG iptable_mangle iptable_filter iptable_nat ip_tables nf_nat x_tables nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 pcspkr coretemp acpi_cpufreq firewire_sbp2 loop snd_hda_codec_realtek snd_hda_intel snd_hda_codec pcmcia arc4 snd_hwdep snd_pcm_oss snd_mixer_oss ecb snd_pcm yenta_socket rsrc_nonstatic joydev pcmcia_core evdev psmouse snd_seq_midi i2c_i801 serio_raw i2c_core iwl3945 iwlcore rng_core snd_rawmidi iTCO_wdt rfkill mac80211 snd_seq_midi_event video output battery snd_seq snd_timer snd_seq_device cfg80211 container snd ac button processor soundcore snd_page_alloc intel_agp ext3 jbd mbcache dm_mirror dm_region_hash dm_log dm_snapshot dm_mod sg sr_mod cdrom sd_mod crc_t10dif ide_pci_generic ide_core ata_piix ata_generic libata r8169 mii sdhci_pci sdhci mmc_core led_class scsi_mod firewire_ohci firewire_core crc_itu_t uhci_hcd thermal fan thermal_sys ehci_hcd [ 384.804318] Pid: 0, comm: swapper Not tainted 2.6.30-1-amd64 #1 [ 384.804322] Call Trace: [ 384.804326][] ? dev_watchdog+0xc7/0x164 [ 384.804341] [] ? dev_watchdog+0xc7/0x164 [ 384.804350] [] ? warn_slowpath_common+0x77/0xa3 [ 384.804357] [] ? dev_watchdog+0x0/0x164 [ 384.804363] [] ? warn_slowpath_fmt+0x51/0x59 [ 384.804372] [] ? enqueue_task+0x5c/0x65 [ 384.804380] [] ? autoremove_wake_function+0x9/0x2e [ 384.804386] [] ? netif_tx_lock+0x3d/0x69 [ 384.804394] [] ? netdev_drivername+0x3b/0x40 [ 384.804400] [] ? dev_watchdog+0xc7/0x164 [ 384.804406] [] ? __wake_up+0x30/0x44 [ 384.804412] [] ? dev_watchdog+0x0/0x164 [ 384.804420] [] ? run_timer_softirq+0x193/0x210 [ 384.804428] [] ? getnstimeofday+0x55/0xaf [ 384.804435] [] ? __do_softirq+0xac/0x173 [ 384.804442] [] ? call_softirq+0x1c/0x30 [ 384.804448] [] ? do_softirq+0x3a/0x7e [ 384.804454] [] ? irq_exit+0x3f/0x80 [ 384.804461] [] ? smp_apic_timer_interrupt+0x87/0x94 [ 384.804467] [] ? apic_timer_interrupt+0x13/0x20 [ 384.804471][] ? acpi_idle_enter_bm+0x274/0x2a8 [processor] [ 384.804505] [] ? acpi_idle_enter_bm+0x26d/0x2a8 [processor] [ 384.804514] [] ? cpuidle_idle_call+0x8b/0xc7 [ 384.804522] [] ? cpu_idle+0x50/0x91 [ 384.804527] ---[ end trace eadd4032f69184bd ]--- [ 384.821181] r8169: eth0: link up Thanks for looking into this. Cheers, Carlos
