Bug#650771: r8169 connectivity intermittent, link up messages in syslog
Robbert Haarman wrote: I am going to catch some sleep now. FYI: http://thread.gmane.org/gmane.linux.kernel/1223268 -- 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/20111205081727.ga8...@elie.hsd1.il.comcast.net
Bug#604049: marked as done (linux-image-2.6.32-5-amd64: data corruption with promise stex driver and use of device-mapper layers (lvm/dm-crypt/..))
Your message dated Mon, 5 Dec 2011 02:25:15 -0600 with message-id 20111205082515.gb8...@elie.hsd1.il.comcast.net and subject line Re: data corruption with promise stex driver and use of device-mapper layers (lvm/dm-crypt/..) has caused the Debian Bug report #604049, regarding linux-image-2.6.32-5-amd64: data corruption with promise stex driver and use of device-mapper layers (lvm/dm-crypt/..) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 604049: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604049 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-2.6 Version: 2.6.32-27 Severity: critical Tags: d-i upstream Justification: causes serious data loss any use of the stex.ko promise hw-raid controller driver with a device-mapper layer produces data corruption (or filesystem corruption like you can see in my dmesg). for test i've used for instance: # cd /mnt/raid5lvmxfs # raid5 stex.ko disk with lvm+xfs # cp -r /usr . # md5sum --quiet -c /usr.md5sum #generated with md5deep usr/lib64/jvm/java-6-sun/jre/lib/plugin.jar: FAILED usr/lib64/jvm/java-6-sun/jre/lib/rt.jar: FAILED usr/lib64/jvm/java-6-sun/jre/lib/charsets.jar: FAILED usr/lib64/libasound.so.2.0.0: FAILED usr/lib64/libhd.so.16.0: FAILED usr/lib64/libperl.so.5.10.1: FAILED usr/lib64/libunistring.so.0.1.2: FAILED usr/lib64/libc.a: FAILED usr/lib64/libpthread.a: FAILED md5sum: WARNING: 122 of 136316 computed checksums did NOT match the number of files vary in quantity on each pass. Using the filesystem directly onto the raid-disk it works fine. i've asked Ed Lin (Maintainer of stex.c from promise) on lkml and got the following answer: We found similar problem during test. The stex driver sets sg_tablesize as 32 (for st_yel it's 38) in the probe entry. It seems that this value was overridden by the system if using dm/lvm, for unknown reason. The driver received requests with more sg items than registered. Sg item number could be as high as 64. This is completely unexpected. The firmware could not handle such requests, and error occurred. The problem can be easily reproduced using a minimum test that only requires copying files from system usr directory to stex dm volume (ext2). The stex dm volume was created using the command echo 0 5120 linear /dev/sdb1 0 | dmsetup create sdb. The problem should exist on every kernel since 2.6.32. The problem did not occur on 2.6.31 using similar minimum test. regards, Markus Schulz -- Package-specific info: ** Version: Linux version 2.6.32-5-amd64 (Debian 2.6.32-27) (m...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Sat Oct 30 14:18:21 UTC 2010 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-amd64 root=UUID=e674b4d5-7530-4e6a-9c7e-18ed8e649c24 ro quiet ** Not tainted ** Kernel log: [7.004930] scsi 7:0:0:0: Direct-Access Generic 6000 PQ: 0 ANSI: 0 CCS [7.005876] sd 7:0:0:0: Attached scsi generic sg3 type 0 [7.007124] sd 7:0:0:0: [sdc] Attached SCSI removable disk [7.693252] EXT4-fs (sda3): mounted filesystem with ordered data mode [7.751743] kjournald starting. Commit interval 5 seconds [7.751932] EXT3 FS on dm-2, internal journal [7.751938] EXT3-fs: mounted filesystem with ordered data mode. [7.780957] SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled [7.781685] SGI XFS Quota Management subsystem [7.784115] XFS mounting filesystem dm-1 [ 52.749497] Starting XFS recovery on filesystem: dm-1 (logdev: internal) [ 54.424250] Ending XFS recovery on filesystem: dm-1 (logdev: internal) [ 55.138260] r8169: eth0: link up [ 55.138267] r8169: eth0: link up [ 61.240646] RPC: Registered udp transport module. [ 61.240650] RPC: Registered tcp transport module. [ 61.240652] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 61.283590] Slow work thread pool: Starting up [ 61.283781] Slow work thread pool: Ready [ 61.283853] FS-Cache: Loaded [ 61.319926] FS-Cache: Netfs 'nfs' registered for caching [ 61.342520] Installing knfsd (copyright (C) 1996 o...@monad.swb.de). [ 61.889257] Loading iSCSI transport class v2.0-870. [ 61.914928] iscsi: registered transport (tcp) [ 61.984953] iscsi: registered transport (iser) [ 62.453489] svc: failed to register lockdv1 RPC service (errno 97). [ 62.454175] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory [ 62.464294] NFSD: starting 90-second grace period [ 65.265356] eth0: no IPv6 routers present [ 281.589476] XFS internal error
Wheezy: Intel EG20T Support
I was trying to install the Testing version of Debian last week onto an Atom prozessor board, equipped with an EG20T platform controller. Although the Kernel from 2.6.38 on should support this chip, it was not activated in the package, neither as a module nor in the kernel itself. Now I wonder why. Is there and particular reason for this or any special risk of instability for this issue? Regards Gerald
Bug#613321: linux-image-amd64: Please enable 'memtest' option for all linux kernels
Sorry Ben, I feel like I need to clarify some ambiguity of our communication. When in reply to bug filed against linux-image-amd64 you sad Your request cannot be satisfied since the MEMTEST option is only available for x86, my perception let me think that for some reason you meant the feature cannot be enabled for amd64. Now I realize you probably meant MEMTEST will be available only on x86 i.e. on amd64 (aka x86_64) and on i386 (aka x86_32) but not on other platforms. This is certainly good enough for me since like vast majority of users I have only x86 in my possession. I reckon many people might feel satisfied. Thanks again for your hard work. Regards, Dmitry. -- 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/201112052000.40377.only...@member.fsf.org
Re: Wheezy: Intel EG20T Support
On Mon, Dec 05, 2011 at 09:46:49AM +0100, Faustmann Gerald wrote: I was trying to install the Testing version of Debian last week onto an Atom prozessor board, equipped with an EG20T platform controller. Although the Kernel from 2.6.38 on should support this chip, it was not activated in the package, neither as a module nor in the kernel itself. Now I wonder why. Is there and particular reason for this or any special risk of instability for this issue? please use reportbug to file the issue so it won't get forgotten. afais it's still also the case for 3.1 linux images. thanks -- maks -- 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/20111205090515.gh11...@vostochny.stro.at
Bug#598144: rt2500pci: very low transfers and link quality
Hi Jonathan, Thanks for reply about this problem, but the laptop with rt2500 wireless card died 6 or 7 months ago (a graphic card crash), so I can't try the 3.1 kernel version. I think that after a lot of tests (compiling a new module version using compat-wireless project, compiling the drivers from Ralink, updating the kernel version, disabling Network-Manager to manually configure the card, ...), I finally got the wireless card working fine, but now I can't remember which was the final solution to the problem. I'm sure that there was something bad with the rt2500pci module because I found a lot of information about the problem, associated to different distros, and I could verify with a Live CD that the problem was in Ubuntu too. I'm thinking about analyze the laptop hard disk this Christmas to recover some files to my new computer, so if I find some information about the solutión that I applied, I promise to write again to tell you. Meanwhile, I think that you can mark this bug as solved if you want. Greetings, David. El 3 de diciembre de 2011 08:19, Jonathan Nieder jrnie...@gmail.comescribió: # forwarded last year: # http://thread.gmane.org/gmane.linux.kernel.wireless.general/56714 # no response, so let's try again. notforwarded 598144 quit Heya, Regarding version 2.6.32-20, David Sánchez Herrero wrote: I have been using rt2500pci since rt2500 legacy drivers source package dissapeared from the repository, and I have had this problems from the first time until now. The legacy drivers worked fine, but with the new ones I have very low transfers and poor link quality. That's no good. So let's see. [...] it's impossible to make anything because in all terminals appears one message continously: cfg80211: Calling CRDA to update world regulatory domain. I can see that I lose the connection, probably because this message. This happens with 2.6.36-rc5-686 kernel. Any idea about solving this problem? Very odd. Does it still happen? [...] This problem doesn't exists with 2.6.32-5-686 kernel, but with it, I have again the error message that appears in my first report: phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). Which kernel version is that? You can get the currently running kernel version by running cat /proc/version and looking for the string in parentheses. I don't see any relevant fixes upstream (amazingly, since the driver has had a lot of work done). If you can get a chance to test a 3.1.y or later kernel from sid, that would be very helpful. (Then we can get help from upstream.) For graphics, while testing you can use the vesa driver or nouveau. Thanks for writing and hope that helps, Jonathan [...] 01:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 01) Subsystem: Micro-Star International Co., Ltd. Device [1462:3fcc]
Bug#650722: linux-image-2.6.32-5-amd64: kernel BUG at mm/hugetlb.c:1986 while doing virsh save of a KVM guest
Hi, Am 05.12.2011 03:13, schrieb Ben Hutchings: On Fri, 2011-12-02 at 11:50 +0100, Arnd Hannemann wrote: Package: linux-2.6 Version: 2.6.32-38 Severity: normal I'm using hugetlb memory for my KVM guests. When trying to save a guest state to a file with virsh save I hit the below kernel bug: [...] Did this occur only once, or is it reproducible? Unfortunately I couldn't reproduce it, I just tried it a dozen times, and it worked. Unfortunately, I can't find an upstream bug fix that's obviously related to this. (There has been a fix for a bug that caused the same assertion to fail, but that bug was only introduced after Linux 2.6.32.) Ok, thanks for investigating. I think then you can close this bug, I migh reopen it, if I have a test case which is reproducible. Best regards Arnd -- Arnd Hannemann Tel.: +49 (0) 2161 / 4643 - 134 credativ GmbH, HRB Mönchengladbach 12080 Hohenzollernstr. 133, 41061 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz signature.asc Description: OpenPGP digital signature
Bug#651015: Tests good
Hello. I just wanted to mention that I have the same problem with a USB headset on an Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05) (8086:3b3c) and testing with upstream 3.2.0-rc4 kernel resolves it. How long until after it becomes latest stable upstream might we see it in Debian Testing? (Also, the reply message address for subscribing to bug reports is too long (username part) and my mail server rejects it, so please make sure to CC me on replies.) Sincerely, Sean M. Pappalardo smime.p7s Description: S/MIME Cryptographic Signature
Bug#594676: Files Download Pb with the atl1c module and my ReadyNAS
Ben Hutchings a écrit :
On Thu, 2011-12-01 at 11:33 +0100, giggzounetSMTP wrote:
[...]
On my LAN my routeur always forces the mtu of my laptops to 1492. I have
a laptop with debian sid and an eeepc with debian stable lenny. On this
LAN I have a NAS (readyNAS duo of Netgear). With my laptop with sid I
don't have any problem at all to upload/download file from my NAS with
ftp/cifs/NFS and with firestarter installed. But with my eeepc (with
ethernet atl1c) I get one:
- with firestarter installed
- with an mtu set to 1492
I can't download file from my NAS through ftp/cifs/NFS. But I can upload
without problem.
So I have a little bit researched on the problem:
- with mtu of 1500 on my eeepc the problem disappears. even firestarter
is installed.
- the net.ipv4.tcp_timestamps value ist set to 0 by firestarter. When I
force it to 1 it works out of the box even with an mtu of 1492.
Please provide packet captures for your download attempts. Use
'tcpdump -i eth0 -w eeepc.pcap' (as root) on the eeePC to create the
file 'eeepc.pcap' (and press ^C to stop). If you can install tcpdump on
the NAS, please run 'tcpdump -i eth0 -w nas.pcap' there at the same
time. You can use wireshark to review these files before sending them
to us.
Please also provide the firewall rules that firestarter generates
('iptables -vnL' will print these)
Ben.
Hi,
I can't install tcpdump on the NAS. On the eeepc I did:
I'm connecting on the nas with ftp -p.
Then I'm switching directory.
And finnaly I start a get.
nothing is done, so I do ctrl+c then bye.
The tcpdump is in the pb_NAS.txt file.
I did iptables -vnL and the results are in iptables.log.
Thx a lot,
Regards,
GiGGz
14:24:39.874317 IP (tos 0x0, ttl 64, id 46792, offset 0, flags [DF], proto TCP
(6), length 44) 192.168.0.4.57933 192.168.0.5.10021: S, cksum 0x1e6a
(correct), 2487174152:2487174152(0) win 5808 mss 1452
14:24:39.874537 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6),
length 44) 192.168.0.5.10021 192.168.0.4.57933: S, cksum 0x39f4 (correct),
619233108:619233108(0) ack 2487174153 win 5840 mss 1460
14:24:39.874653 IP (tos 0x0, ttl 64, id 46793, offset 0, flags [DF], proto TCP
(6), length 40) 192.168.0.4.57933 192.168.0.5.10021: ., cksum 0x51d1
(correct), ack 1 win 5808
14:24:39.913398 IP (tos 0x0, ttl 64, id 54843, offset 0, flags [DF], proto TCP
(6), length 102) 192.168.0.5.10021 192.168.0.4.57933: P 1:63(62) ack 1 win
5840
14:24:39.913523 IP (tos 0x10, ttl 64, id 46794, offset 0, flags [DF], proto TCP
(6), length 40) 192.168.0.4.57933 192.168.0.5.10021: ., cksum 0x5193
(correct), ack 63 win 5808
14:24:41.039400 IP (tos 0x10, ttl 64, id 46795, offset 0, flags [DF], proto TCP
(6), length 52) 192.168.0.4.57933 192.168.0.5.10021: P, cksum 0x8180
(incorrect (- 0xb886), 1:13(12) ack 63 win 5808
14:24:41.039608 IP (tos 0x0, ttl 64, id 54844, offset 0, flags [DF], proto TCP
(6), length 40) 192.168.0.5.10021 192.168.0.4.57933: ., cksum 0x5167
(correct), ack 13 win 5840
14:24:41.048400 IP (tos 0x0, ttl 64, id 54845, offset 0, flags [DF], proto TCP
(6), length 73) 192.168.0.5.10021 192.168.0.4.57933: P, cksum 0x4201
(correct), 63:96(33) ack 13 win 5840
14:24:41.048513 IP (tos 0x10, ttl 64, id 46796, offset 0, flags [DF], proto TCP
(6), length 40) 192.168.0.4.57933 192.168.0.5.10021: ., cksum 0x5166
(correct), ack 96 win 5808
14:24:43.991953 IP (tos 0x10, ttl 64, id 46797, offset 0, flags [DF], proto TCP
(6), length 54) 192.168.0.4.57933 192.168.0.5.10021: P, cksum 0x8182
(incorrect (- 0x6891), 13:27(14) ack 96 win 5808
14:24:44.025514 IP (tos 0x0, ttl 64, id 54846, offset 0, flags [DF], proto TCP
(6), length 40) 192.168.0.5.10021 192.168.0.4.57933: ., cksum 0x5138
(correct), ack 27 win 5840
14:24:44.085207 IP (tos 0x0, ttl 64, id 54847, offset 0, flags [DF], proto TCP
(6), length 66) 192.168.0.5.10021 192.168.0.4.57933: P, cksum 0x70c2
(correct), 96:122(26) ack 27 win 5840
14:24:44.085331 IP (tos 0x10, ttl 64, id 46798, offset 0, flags [DF], proto TCP
(6), length 40) 192.168.0.4.57933 192.168.0.5.10021: ., cksum 0x513e
(correct), ack 122 win 5808
14:24:44.085444 IP (tos 0x10, ttl 64, id 46799, offset 0, flags [DF], proto TCP
(6), length 46) 192.168.0.4.57933 192.168.0.5.10021: P, cksum 0x817a
(incorrect (- 0x9d78), 27:33(6) ack 122 win 5808
14:24:44.085624 IP (tos 0x0, ttl 64, id 54848, offset 0, flags [DF], proto TCP
(6), length 40) 192.168.0.5.10021 192.168.0.4.57933: ., cksum 0x5118
(correct), ack 33 win 5840
14:24:44.089889 IP (tos 0x0, ttl 64, id 54849, offset 0, flags [DF], proto TCP
(6), length 59) 192.168.0.5.10021 192.168.0.4.57933: P, cksum 0xe9ac
(correct), 122:141(19) ack 33 win 5840
14:24:44.127296 IP (tos 0x10, ttl 64, id 46800, offset 0, flags [DF], proto TCP
(6), length 40) 192.168.0.4.57933 192.168.0.5.10021: ., cksum 0x5125
(correct), ack 141 win 5808
14:24:47.747473 IP (tos 0x10, ttl 64, id 46801, offset 0, flags [DF], proto TCP
(6), length 46) 192.168.0.4.57933
Processed: Re: Bug#651057: machine freezes at boot time (twice so far)
Processing commands for cont...@bugs.debian.org: reassign 651057 src:linux-2.6 Bug #651057 [linux-image] machine freezes at boot time (twice so far) Warning: Unknown package 'linux-image' Bug reassigned from package 'linux-image' to 'src:linux-2.6'. Bug No longer marked as found in versions 2.6.32-5-amd64. thanks Stopping processing here. Please contact me if you need assistance. -- 651057: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651057 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.132309071731877.transcr...@bugs.debian.org
Processed: tagging 650722
Processing commands for cont...@bugs.debian.org: tags 650722 + unreproducible Bug #650722 [linux-2.6] linux-image-2.6.32-5-amd64: kernel BUG at mm/hugetlb.c:1986 while doing virsh save of a KVM guest Added tag(s) unreproducible. thanks Stopping processing here. Please contact me if you need assistance. -- 650722: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650722 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.132309382014521.transcr...@bugs.debian.org
Bug#613321: linux-image-amd64: Please enable 'memtest' option for all linux kernels
On Mon, 2011-12-05 at 20:00 +1100, Dmitry Smirnov wrote: Sorry Ben, I feel like I need to clarify some ambiguity of our communication. When in reply to bug filed against linux-image-amd64 you sad Your request cannot be satisfied since the MEMTEST option is only available for x86, my perception let me think that for some reason you meant the feature cannot be enabled for amd64. Now I realize you probably meant MEMTEST will be available only on x86 i.e. on amd64 (aka x86_64) and on i386 (aka x86_32) but not on other platforms. [...] That's correct. In the context of the Linux kernel, 'x86' includes both. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
Bug#651015: Tests good
On Mon, 2011-12-05 at 10:40 +0100, Sean M. Pappalardo wrote: Hello. I just wanted to mention that I have the same problem with a USB headset on an Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05) (8086:3b3c) and testing with upstream 3.2.0-rc4 kernel resolves it. How long until after it becomes latest stable upstream might we see it in Debian Testing? We don't have to wait for that, since the fix can be applied to 3.1. The current version in unstable (3.1.4-1) failed to build on MIPS so we'll need to make another upload soon which will include this fix. If *that* builds everywhere and doesn't have a serious regression then it will go into testing 10 days later. So I would estimate about 2 weeks. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
Bug#651076: linux-image-3.1.0-1-amd64: randomly hangs on systems with rtl8192se wireless
Package: linux-2.6 Version: 3.1.1-1 Severity: normal Tags: upstream Dear Maintainer, I've recently found that 3.1.0 kernel hangs quite randomly on my laptop. I can't trigger that, but figured out that those hangs related to rtl8192se driver. Below you can find part of kernel buffer dump. It seems that recent changes of rtlwifi led to race condition on wifi powersave state enter. That in turn lead to hang, with only option to hardreset machine. There is thread on lkml about issue, and in this message (https://lkml.org/lkml/2011/9/19/207) one confirm that problem can be solved be turning off powersaving. This is just workaround but you may be interested in it as temporary solution I thought. Also I tried 3.2-rc4 kernel from experimental and it also hung. -- Rinat 3[ 5300.347806] BUG: soft lockup - CPU#0 stuck for 23s! [kworker/0:2:25329] 4[ 5300.347813] Modules linked in: cryptd aes_x86_64 aes_generic acpi_cpufreq mperf cpufreq_powersave cpufreq_userspace cpufreq_stats cpufreq_conservative parport_pc ppdev lp parport microcode binfmt_misc fuse loop snd_hda_codec_hdmi snd_hda_codec_si3054 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi joydev snd_seq_midi_event snd_seq snd_timer i915 drm_kms_helper drm iTCO_wdt snd_seq_device arc4 snd rtl8192se iTCO_vendor_support rtlwifi mac80211 i2c_algo_bit soundcore cfg80211 jmb38x_ms i2c_i801 memstick i2c_core ac intel_ips psmouse snd_page_alloc serio_raw battery pcspkr evdev rfkill wmi power_supply video button processor ext4 mbcache jbd2 crc16 btrfs zlib_deflate crc32c libcrc32c dm_mod sd_mod sr_mod cdrom crc_t10dif thermal thermal_sys ahci libahci libata sdhci_pci sdhci ehci_hcd jme mii scsi_mod usbcore mmc_core [last unloaded: scsi_wait_scan] 4[ 5300.347945] CPU 0 4[ 5300.347947] Modules linked in: cryptd aes_x86_64 aes_generic acpi_cpufreq mperf cpufreq_powersave cpufreq_userspace cpufreq_stats cpufreq_conservative parport_pc ppdev lp parport microcode binfmt_misc fuse loop snd_hda_codec_hdmi snd_hda_codec_si3054 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi joydev snd_seq_midi_event snd_seq snd_timer i915 drm_kms_helper drm iTCO_wdt snd_seq_device arc4 snd rtl8192se iTCO_vendor_support rtlwifi mac80211 i2c_algo_bit soundcore cfg80211 jmb38x_ms i2c_i801 memstick i2c_core ac intel_ips psmouse snd_page_alloc serio_raw battery pcspkr evdev rfkill wmi power_supply video button processor ext4 mbcache jbd2 crc16 btrfs zlib_deflate crc32c libcrc32c dm_mod sd_mod sr_mod cdrom crc_t10dif thermal thermal_sys ahci libahci libata sdhci_pci sdhci ehci_hcd jme mii scsi_mod usbcore mmc_core [last unloaded: scsi_wait_scan] 4[ 5300.348054] 4[ 5300.348060] Pid: 25329, comm: kworker/0:2 Not tainted 3.1.3-md #2 CLEVO CO.E4105 /E4105 4[ 5300.348072] RIP: 0010:[81070172] [81070172] do_raw_spin_lock+0x15/0x1b 4[ 5300.348089] RSP: 0018:8800af003ea8 EFLAGS: 0297 4[ 5300.348094] RAX: fd67 RBX: 8800a95b0520 RCX: 6b34 4[ 5300.348099] RDX: fd66 RSI: 8800a95b1f98 RDI: 8800a95b1d14 4[ 5300.348104] RBP: 8800a95b0520 R08: R09: 00012f40 4[ 5300.348109] R10: 00012f40 R11: 8800370fd400 R12: 8800af003e18 4[ 5300.348114] R13: 8133319e R14: 8800a95b0520 R15: 8800a95b1ce0 4[ 5300.348121] FS: () GS:8800af00() knlGS: 4[ 5300.348126] CS: 0010 DS: ES: CR0: 8005003b 4[ 5300.348131] CR2: 7f0203c0e000 CR3: 01605000 CR4: 06f0 4[ 5300.348136] DR0: DR1: DR2: 4[ 5300.348142] DR3: DR6: 0ff0 DR7: 0400 4[ 5300.348148] Process kworker/0:2 (pid: 25329, threadinfo 88008ae5a000, task 8800a807f7d0) 0[ 5300.348152] Stack: 4[ 5300.348155] a02dc4f4 8800a95b1f90 8800a95b1f90 8800a95b1f98 4[ 5300.348164] 8104a5ba 816040b0 88008ae5bfd8 0100 4[ 5300.348173] 8104ada4 0001 000a 8800aec05000 0[ 5300.348181] Call Trace: 0[ 5300.348184] IRQ 4[ 5300.348200] [a02dc4f4] ? rtl_lps_leave+0x13/0xe1 [rtlwifi] 4[ 5300.348211] [8104a5ba] ? tasklet_action+0x73/0xc2 4[ 5300.348220] [8104ada4] ? __do_softirq+0xb9/0x177 4[ 5300.348228] [8133492c] ? call_softirq+0x1c/0x30 4[ 5300.348239] [8100f845] ? do_softirq+0x3c/0x7b 4[ 5300.348246] [8104b00c] ? irq_exit+0x3c/0x9a 4[ 5300.348254] [81026b01] ? x2apic_cluster_probe+0x7d/0x7f 4[ 5300.348262] [8100f575] ? do_IRQ+0x82/0x98 4[ 5300.348269] [8132da2e] ? common_interrupt+0x6e/0x6e 0[ 5300.348273] EOI 4[ 5300.348282] [811a1df1] ?
Bug#634794: CD-ROM drives don't respond to the eject button here too
Hello, On both of my computers that host CD drives the eject button on the drives doesn't work anymore, as soon as a disc has been inserted. However, unlike the reporter from the original bug, I can use the eject command to eject the drives. That is quite a pain ;-)... Drive model (but at home I have two other drives that show the same problem): [2.070768] scsi 4:0:0:0: CD-ROMhp DVD-RAM GH80N RF01 PQ: 0 ANSI: 5 [2.083101] sr0: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray [2.083106] cdrom: Uniform CD-ROM driver Revision: 3.20 [2.083212] sr 4:0:0:0: Attached scsi CD-ROM sr0 Cheers, Vincent -- 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/CAEnRq5MUTkdHnrGLxk=hyedepsqv80akkuy4gosuoprrvrn...@mail.gmail.com
Bug#634794: CD-ROM drives don't respond to the eject button here too
Hi Vincent, Vincent Fourmond wrote: However, unlike the reporter from the original bug, I can use the eject command to eject the drives. Please file a separate bug then. Thanks for writing, Jonathan -- 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/20111205162644.ga16...@elie.hsd1.il.comcast.net
Bug#646753: xserver-xorg-video-radeon: Login screen shows random static
On Sam, 2011-11-26 at 05:37 -0600, Jonathan Nieder wrote:
Andrew Goodbody wrote:
On 27/10/11 16:09, Michel Dänzer wrote:
On Mit, 2011-10-26 at 20:29 +0100, Andrew Goodbody wrote:
[4.526223] [drm] Loading CEDAR Microcode
[5.000164] [drm:r600_ring_test] *ERROR* radeon: ring test failed
(scratch(0x8504)=0xCAFEDEAD)
Does this still happen with a 3.0.7, 3.1 or newer based kernel?
No it does not. Life is good with a 3.1.0 kernel.
Thanks much.
Michel, was this a regression, or is there some commit (87463ff83bcd?)
that ought to be backported to squeeze?
Rather 12d5180bd7e683a4ae80830b82ba67e7b7fac7b2 ('drm/radeon/kms: fix
channel_remap setup (v2)').
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
--
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/1323102876.11335.499.camel@thor.local
Bug#634794: CD-ROM drives don't respond to the eject button here too
On Mon, Dec 05, 2011 at 10:26:44AM -0600, Jonathan Nieder wrote: Hi Vincent, Vincent Fourmond wrote: However, unlike the reporter from the original bug, I can use the eject command to eject the drives. Please file a separate bug then. Also, don't file that bug against the kernel. It will be some userland component auto-mounting the disk. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20111205183154.gd3...@decadent.org.uk
Bug#634794: CD-ROM drives don't respond to the eject button here too
On Mon, Dec 5, 2011 at 7:31 PM, Ben Hutchings b...@decadent.org.uk wrote: On Mon, Dec 05, 2011 at 10:26:44AM -0600, Jonathan Nieder wrote: Hi Vincent, Vincent Fourmond wrote: However, unlike the reporter from the original bug, I can use the eject command to eject the drives. Please file a separate bug then. Also, don't file that bug against the kernel. It will be some userland component auto-mounting the disk. Most definitely not. I don't have automounters ;-)... (as the pmount current maintainer, I'm quite well placed to know what happens with that respect). And eject wouldn't work, then... Cheers, Vincent, who'll file a proper bug whenever time gets a little less spare... -- 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/caenrq5nfge6g7vorlgwjwgzjka1znyq5m7ta_nctcagtvoz...@mail.gmail.com
Bug#634794: CD-ROM drives don't respond to the eject button here too
On Mon, Dec 05, 2011 at 08:04:23PM +0100, Vincent Fourmond wrote: On Mon, Dec 5, 2011 at 7:31 PM, Ben Hutchings b...@decadent.org.uk wrote: On Mon, Dec 05, 2011 at 10:26:44AM -0600, Jonathan Nieder wrote: Hi Vincent, Vincent Fourmond wrote: However, unlike the reporter from the original bug, I can use the eject command to eject the drives. Please file a separate bug then. Also, don't file that bug against the kernel. It will be some userland component auto-mounting the disk. Most definitely not. I don't have automounters ;-)... (as the pmount current maintainer, I'm quite well placed to know what happens with that respect). Well, check the mount table anyway, as you may have accidentally installed a daemon that may auto-mount (e.g. udisks). And eject wouldn't work, then... eject(1) says: If the device is currently mounted, it is unmounted before ejecting. But mounting a removable drive does disable the eject button (if possible). That is why this sounds like auto-mounting to me. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20111205192833.ge3...@decadent.org.uk
Bug#646753: xserver-xorg-video-radeon: Login screen shows random static
Michel Dänzer wrote:
On Mit, 2011-10-26 at 20:29 +0100, Andrew Goodbody wrote:
[4.526223] [drm] Loading CEDAR Microcode
[5.000164] [drm:r600_ring_test] *ERROR* radeon: ring test failed
(scratch(0x8504)=0xCAFEDEAD)
[...]
Rather 12d5180bd7e683a4ae80830b82ba67e7b7fac7b2 ('drm/radeon/kms: fix
channel_remap setup (v2)').
Kernels without 9535ab732335 ('drm/radeon/kms: setup mc chremap
properly on r7xx/evergreen', which hit mainline in the 2.6.38 merge
window) should not be affected, then. Thanks --- that's a comfort.
--
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/20111205194453.ga16...@elie.hsd1.il.comcast.net
Bug#641749: ath3k_load_firmware: Can't change to loading configuration err
Andres Cimmarusti wrote: I was able to try wheezy with a downgraded udev to version 164 from squeeze, but using Sid's kernel 3.1.4. Sadly, I get the same problem! (this is rather upsetting, since I'm using the same combination on squeeze and I get no problems). Maybe playing with usb-modeswitch (e.g., uninstalling it or trying different versions) could provide some insight. -- 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/20111205212130.gb22...@elie.area4.il.chicago.comcast.net
Bug#651121: After xm restore dumU freezes
Package: linux-image-2.6.32-5-xen-amd64 Version: 2.6.32-38 Steps to reproduce: /usr/sbin/xm save TEST /xen/domains/TEST/checkpoint /usr/sbin/xm restore /xen/domains/TEST/checkpoint xm console # hangs, no input possible Worked with older version about 2 months ago. Not working since update to 2.6.32-38. ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 -- 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/1236542851.539564.1323124640899.JavaMail.fmail@mwmweb006
Bug#651123: linux-latest-2.6: [INTL:pt] Updated Portuguese translation for debconf messages
Package: linux-latest-2.6 Version: 41 Tags: l10n, patch Severity: wishlist Updated Portuguese translation for linux-latest-2.6's debconf messages. Translator: Miguel Figueiredo el...@debianpt.org Feel free to use it. For translation updates please contact 'Last Translator' or the Portuguese Translation Team traduz _at_ debianpt.org. -- Melhores cumprimentos/Best regards, Traduz! - Portuguese Translation Team pt.po.gz Description: application/gzip
Bug#651121: marked as done (After xm restore dumU freezes)
Your message dated Mon, 5 Dec 2011 23:55:14 + with message-id 20111205235514.gf3...@decadent.org.uk and subject line Re: Bug#651121: After xm restore dumU freezes has caused the Debian Bug report #651121, regarding After xm restore dumU freezes to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 651121: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651121 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-image-2.6.32-5-xen-amd64 Version: 2.6.32-38 Steps to reproduce: /usr/sbin/xm save TEST /xen/domains/TEST/checkpoint /usr/sbin/xm restore /xen/domains/TEST/checkpoint xm console # hangs, no input possible Worked with older version about 2 months ago. Not working since update to 2.6.32-38. ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 ---End Message--- ---BeginMessage--- Version: 2.6.32-39 The above version fixes this and is currently in the 'squeeze-updates' suite. You may need to add this to your APT sources. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus ---End Message---
Processed: tagging 651123
Processing commands for cont...@bugs.debian.org: tags 651123 + pending Bug #651123 [linux-latest-2.6] linux-latest-2.6: [INTL:pt] Updated Portuguese translation for debconf messages Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 651123: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651123 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.132314696431786.transcr...@bugs.debian.org
Bug#594676: marked as done (linux-image-2.6-amd64: Files Download Pb with the atl1c module and my ReadyNAS)
Your message dated Tue, 06 Dec 2011 05:18:18 + with message-id 1323148698.7454.244.camel@deadeye and subject line Re: Files Download Pb with the atl1c module and my ReadyNAS has caused the Debian Bug report #594676, regarding linux-image-2.6-amd64: Files Download Pb with the atl1c module and my ReadyNAS to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 594676: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594676 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-image-2.6-amd64 Version: 2.6.32+27~bpo50+1 Severity: normal Hi, I have an eeepc 1201n with debian stable lenny+backports. So I'm using the kernel 2.6.32-bpo.5-amd64. The Ethernet controller is driven by the module atl1c. I'm using firestarter as firewall. I have a file transfer problem between my NAS (readyNAS Duo from Netgear); at first the symptoms: - with firestarter installed (stopped or in use) I can connect my eeepc to my NAS through FTP, CIFS or NFS. For example I can list or go through my shares. But when I'm trying to download a file it is so slow. I get 12Ko in 10minutes... - I can upload files from my eeepc to the NAS without problem with full speed. - When I boot the eeepc under w7 I don't have any problem to download files. - I have two others computers on my LAN: a laptop with SID and the b44 module for the ethernet controller. With this laptop no problem at all to download files from my NAS with firestarter installed. The other one is a desktop station and I don't have any problem, too. Now what I have done with the help of the debian.user.french list: - the NAS has a MTU of 1500 (the software forces it). All the other computers have an mtu of 1492. I don't choose it, my Netgear router force it...When I set the mtu to 1500 on my eeepc with ip link set dev eth0 mtu 1500, then ip route flush cache, I can dowload files from my NAS without problem (firestarter installed and running). When I set the both devices (eeepc and NAS) with a mtu to 1492, it doesn't work at all. - I have tested with the driver from realtek website and I get exactly the same problem. - I did capture with tcpdump. Guys of the debian.user.french mailing list were surprised to see that lots of my packets were lost in my normal configuration (firestarter installed, NAS mtu set to 1500 and eeepc mtu set to 1492). And they see that my packets don't have a lot of the normal TCP options (timestamp, selective ACK, window scaling). So I check with sysctl if these options were enabled or not: net.ipv4.tcp_timestamps = 0 net.ipv4.tcp_sack = 0 net.ipv4.tcp_window_scaling = 0 so they are disable on my normal configuration. Then, I enable the options one by one and see that the net.ipv4.tcp_timestamps option is a part of my problem: with net.ipv4.tcp_timestamps = 0, eeepc_mtu=1492, NAS_mtu=1500 I get problem to download files. with net.ipv4.tcp_timestamps = 1, eeepc_mtu=1492, NAS_mtu=1500 I don't have any problem to download files. The program firestarter modifies the TCP options when it is installed. It seems there is a problem for the atl1c module with the timestamps option disabled and different mtus. On my other laptop with the b44 module, a mtu of 1492 and firestarter I don't have this problem between it and the NAS. Sorry for this lnnng bug report. I can provide tcpdump captures if necessary. Best regards, Guillaume -- System Information: Debian Release: 5.0.5 APT prefers stable APT policy: (987, 'stable'), (985, 'stable'), (500, 'lenny'), (195, 'unstable'), (95, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-bpo.5-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6-amd64 depends on: ii linux-image-2.6.32-bpo 2.6.32-20~bpo50+1 Linux 2.6.32 for 64-bit PCs linux-image-2.6-amd64 recommends no packages. linux-image-2.6-amd64 suggests no packages. -- debconf-show failed ---End Message--- ---BeginMessage--- On Mon, 2011-12-05 at 11:30 +0100, giggzounetsmtp wrote: Ben Hutchings a écrit : On Thu, 2011-12-01 at 11:33 +0100, giggzounetSMTP wrote: [...] On my LAN my routeur always forces the mtu of my laptops to 1492. I have a laptop with debian sid and an eeepc with debian stable lenny. On this LAN I have a NAS (readyNAS duo of Netgear). With my laptop with sid I don't have any problem at all to upload/download file from my NAS with ftp/cifs/NFS and with firestarter installed. But with my eeepc (with ethernet atl1c) I get one: -
Re: Wheezy: Intel EG20T Support
On Mon, 2011-12-05 at 09:46 +0100, Faustmann Gerald wrote: I was trying to install the Testing version of Debian last week onto an Atom prozessor board, equipped with an EG20T platform controller. Although the Kernel from 2.6.38 on should support this chip, it was not activated in the package, neither as a module nor in the kernel itself. Now I wonder why. Is there and particular reason for this or any special risk of instability for this issue? Generally we enable all drivers that can possibly be useful, so long as they're modules and don't have device ID conflicts. I thought these chips would only be used in embedded systems that normally run custom kernels, but obviously I was wrong. I'll enable all the drivers for the EG20T. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
