Bug#621027: marked as done (Invalid shell option in start-statd)
Your message dated Fri, 22 Apr 2011 08:13:56 +0200 with message-id 4db11ca4.4080...@debian.org and subject line Re: Invalid shell option in start-statd has caused the Debian Bug report #621027, regarding Invalid shell option in start-statd 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.) -- 621027: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621027 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: nfs-common Version: 1:1.2.3-1 Severity: important % head -n1 =start-statd #!/bin/sh -p % /bin/sh -p -c true /bin/sh: Illegal option -p % ls -l =sh lrwxrwxrwx 1 root root 4 17. Dez 18:49 /bin/sh - dash The option -p is not a valid option for dash, that's the default for sh. Bye, Jörg. signature.asc Description: Digital signature http://en.wikipedia.org/wiki/OpenPGP ---End Message--- ---BeginMessage--- Version: 1:1.2.3-2 On 04/22/2011 08:08 AM, Marc Glisse wrote: On Sat, 9 Apr 2011, Marc Glisse wrote: On Sat, 9 Apr 2011, Luk Claes wrote: Do you have rpcbind installed? Do you still have issues with the latest upload (1:1.2.3-2)? No, I appear to have portmap instead. I'll test the new upload (and thus the switch to rpcbind) when I get back It seems to be working fine, thank you. Thanks. Closing this bug. Cheers Luk ---End Message---
Processed: merge my dupplicate bugs
Processing commands for cont...@bugs.debian.org: merge 623615 623435 Bug#623435: linux-image-2.6.32-5-amd64: crashes with BUG sigqueue: Not a valid slab page Bug#623615: linux-image-2.6.32-5-amd64: crashes with BUG sigqueue: Not a valid slab page Merged 623435 623615. thanks Stopping processing here. Please contact me if you need assistance. -- 623615: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623615 623435: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623435 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.13034553357976.transcr...@bugs.debian.org
Bug#623584: initramfs-tools create a wrong directory tree
Hi, I made a few tests on this report and I found that the loader is not looking at the right directories. Please have a look at this: root@debian:/boot/f# chroot . lib64/ld-linux-x86-64.so.2 --list bin/sh bin/sh: error while loading shared libraries: libm.so.6: cannot open shared object file: No such file or directory root@debian:/boot/f# chroot . lib64/ld-linux-x86-64.so.2 --list --library-path /lib64 bin/sh linux-vdso.so.1 = (0x7fff5f3ff000) libm.so.6 = /lib64/libm.so.6 (0x7f7f96cd7000) libc.so.6 = /lib64/libc.so.6 (0x7f7f96976000) /lib64/ld-linux-x86-64.so.2 = lib64/ld-linux-x86-64.so.2 (0x7f7f96f5b000) root@debian:/boot/f# chroot . lib64/ld-linux-x86-64.so.2 --library-path /lib64 bin/sh BusyBox v1.17.1 (Debian 1:1.17.1-8) built-in shell (ash) Enter 'help' for a list of built-in commands. / # exit As you may see, if I manually add /lib64 in the ld search path, then libm is found and the busybox executable starts. So, the problem with this initramfs image is that lib64 should only contain the loader, and all libraries should be in lib. This is how it is: root@debian:/boot/f# ls -ld lib lib64 lib*/* drwxr-xr-x 4 root root4096 Apr 21 14:28 lib -rwxr-xr-x 1 root root 71960 Apr 21 14:28 lib/klibc-r1_A6R6EwMsdze5h5xz93JiNuoM.so -rw-r--r-- 1 root root 128256 Apr 21 14:28 lib/libblkid.so.1 -rw-r--r-- 1 root root 139736 Apr 21 14:28 lib/libdevmapper.so.1.02.1 -rw-r--r-- 1 root root 286776 Apr 21 14:28 lib/libncurses.so.5 -rw-r--r-- 1 root root 258088 Apr 21 14:28 lib/libreadline.so.5 -rw-r--r-- 1 root root 117848 Apr 21 14:28 lib/libselinux.so.1 -rw-r--r-- 1 root root 55136 Apr 21 14:28 lib/libudev.so.0 -rw-r--r-- 1 root root 15720 Apr 21 14:28 lib/libuuid.so.1 drwxr-xr-x 3 root root4096 Apr 21 14:28 lib/modules drwxr-xr-x 3 root root4096 Apr 21 14:28 lib/udev drwxr-xr-x 2 root root4096 Apr 21 14:28 lib64 -rwxr-xr-x 1 root root 128744 Apr 21 14:28 lib64/ld-linux-x86-64.so.2 -rwxr-xr-x 1 root root 1432968 Apr 21 14:28 lib64/libc.so.6 -rw-r--r-- 1 root root 14696 Apr 21 14:28 lib64/libdl.so.2 -rw-r--r-- 1 root root 530736 Apr 21 14:28 lib64/libm.so.6 and this is how it is on a different (and working) amd64 system: neos@appliance-000:/tmp/gg$ ls -ld lib lib64 lib*/* drwxr-xr-x 4 neos neos4096 22 apr 09.17 lib drwxr-xr-x 2 neos neos 33 22 apr 09.17 lib64 -rwxr-xr-x 1 neos neos 128744 22 apr 09.17 lib64/ld-linux-x86-64.so.2 -rwxr-xr-x 1 neos neos 71960 22 apr 09.17 lib/klibc-r1_A6R6EwMsdze5h5xz93JiNuoM.so -rw-r--r-- 1 neos neos 128256 22 apr 09.17 lib/libblkid.so.1 -rwxr-xr-x 1 neos neos 1432968 22 apr 09.17 lib/libc.so.6 -rw-r--r-- 1 neos neos 139736 22 apr 09.17 lib/libdevmapper.so.1.02.1 -rw-r--r-- 1 neos neos 14696 22 apr 09.17 lib/libdl.so.2 -rw-r--r-- 1 neos neos 530736 22 apr 09.17 lib/libm.so.6 -rw-r--r-- 1 neos neos 286776 22 apr 09.17 lib/libncurses.so.5 -rw-r--r-- 1 neos neos 258088 22 apr 09.17 lib/libreadline.so.5 -rw-r--r-- 1 neos neos 117848 22 apr 09.17 lib/libselinux.so.1 -rw-r--r-- 1 neos neos 55136 22 apr 09.17 lib/libudev.so.0 -rw-r--r-- 1 neos neos 15720 22 apr 09.17 lib/libuuid.so.1 drwxr-xr-x 3 neos neos 27 22 apr 09.17 lib/modules drwxr-xr-x 3 neos neos 132 22 apr 09.17 lib/udev (files order is different since these machines have different locales) Please note that on both system (outside of chroot) /lib64 is a link to /lib. So, if I move all lib* files from lib64 to lib, then create the gzipped cpio initrd image and use this for booting, the busybox load and start it work. Then fails because it cannot mont the root file system as shown here: [...] Initialize network drop monitor service List of all partitions: No filesystem could mount root, tried: Kernel panic - not syncing: VFS Unable to mpunt root fs on unknown-block(0,0) Pid: 1, comm: swapper Not Tainted 2.6.32-5-amd64 #1 Call Trace: [...] Beside the very last problem (I will intestigate about it), how do initramfs-tools create the lib and lib64 trees? Does it use a configuration file? Bye, Giuseppe -- 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/1303457811.4695.23.camel@scarafaggio
Bug#617508: patch available
Hi, On 04/15/2011 05:49 AM, Ben Hutchings wrote: Please consider adding this patch to a ((old)stable) kernel update. I don't think this is sufficiently critical for an oldstable update. For stable, yes, we'll consider it once it's accepted upstream. Please let us know when that happens. It looks like the patch is now in Linus' git tree. Commit id is 1574dff8996ab1ed92c09012f8038b5566fce313 It's definitely in the 2.6.39-rc4-git4 patch. Regards, Rik -- 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/4db15221.8040...@esat.kuleuven.be
Bug#622333: Debian Squeeze hangs with kernel 2.6.32-5-xen-686
On Tue, 2011-04-12 at 05:49 -0300, Daniel Bareiro wrote: After upgrading to Squeeze, I am watching a Xen VMHost that after a while it hangs. This did not happen when I was using Xen with Debian Lenny (in this case as with Squeeze, the Xen components are from Debian repositories). In each case I connected a keyboard and monitor to the computer and the screen remained black without answering any key. When this happens, I noticed that the drive activity LED apparently is permanently on. I presume it also stopped responding to network e.g. ssh as well? Do the magic-sysrq key combinations produce any output? Can you reproduce it or did it just happen the once? If you can repro then attaching and configuring a serial console would be useful, since a) you could see if there was anything printed before the screen went dark and b) you can access the Xen debug keyhandlers only over the serial line. Were you doing anything when it hung or was the system just running in a steady state? I notice you are running a 32 bit hypervisor. I would highly recommend using the 64 bit hypervisor (package xen-hypervisor-4.0-amd64) even on i386. You can continue to use your 32 bit dom0 kernel and userspace but the 64 bit hypervisor is much more reliable and better tested etc. [...] -- In particular, I noticed the following lines: -- [0.00] ERROR: Unable to locate IOAPIC for GSI 2 [0.00] ERROR: Unable to locate IOAPIC for GSI 9 [0.004000] [ cut here ] [0.004000] WARNING: at /build/buildd-linux-2.6_2.6.32-31-i386-qYaaJr/linux-2.6-2.6.32/debian/build/source_i386_xen/arch/x86/xen/enlighten .c:726 perf_events_lapic_init+0x28/0x29() Thanks. This is a benign warning, unfortunately I doubt it is related to the hang. Ian. -- Ian Campbell I'll show you MY telex number if you show me YOURS ... signature.asc Description: This is a digitally signed message part
Bug#622828: recovery
Contrary to my earlier conclusion, the upgrade did not delete older images. It appears a ramdisk generation change may have included a bad module whose loading crashed the system later. I could not boot other images because my Grub 2 configuration file grub.cfg missed the corresponding initrd lines. The latter were missing probably because of a ramdisk generation failure. This resulted in a cryptic error message at the boot failure about inability to find a root filesystem in a certain (0,0) disk. As I mentioned earlier, after loading to a shell prompt by editing the linux line in grub boot screen and adding init=/bin/bash, I could disable swapping with swapoff -a, remount the root partition in a read-write mode and start networking. This allowed me to update packages in aptitude. I also had to boot off a recent Debian installer CD-R disk, http://cdimage.debian.org/cdimage/daily-builds/unstable/current/i386/iso-cd/ because I did not understand the reason for the (0,0) root disk mount crash. I also suspect that my manual invocation of update-initramfs failed to include all required modules. In the end, I dropped to shell from the rescue disk, mounted my root filesystem with mount -t ext3 /dev/sda1 /mnt and changed to it with chroot /mnt. I then re-generated the initial ramdisk images with update-initramfs -k 2.6.32-5-686 -d update-initramfs -k 2.6.32-5-686 -c and same commands for some other kernel versions. This allowed me to boot my system in full with 2.6.32-5-686 which turned to be the original kernel version that worked long time for me. (The newer 2.6.38..-686 kernel on which 2.6-686 depends crashes in the Wi-Fi module mac80211 calling a function in cfg80211 when I attempt to associate with my Wi-Fi router. I logged that issue under bug #622833). Still, I do not understand how possible differences in update-initramfs could cause a libata kernel crash. -- -- 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/20110422135659.ga5...@ei.homeip.net
Bug#620297: Same strange load calculation error on 2.6.32-30
Hello, I've noticed the same strange load calculation inconsistency while running kernel 2.6.32-30. Load values are reported too low for given CPU utilization. As far as I remember older kernels from 2.6.32 line had also the same problem. I did some tests on the same hardware using 2.6.26-26lenny2 and 2.6.30-6 kernels, but their load seems to be just right. What's more puzzling is that load is reported correctly on 2.6.32 when CPU cores are used in 100%, e.g. running: # stress -c 4 reports load 4 when 4 cores are quite busy. However running about 80 php-cgi processes when idle is greater than 20% (a rough estimation) results in this load calculation error. I did some searching and found similar bug report on Launchpad: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/513848 and a discussion on LKML: http://lkml.org/lkml/2010/4/13/394 The patch proposed on LKML is the one that got applied to Ubuntu's kernel version 2.6.32-20.29. I've patched the Debian's 2.6.32-30 and it seems that load values are correct, although still a bit lower than on other kernels. Tests were run on simultaneously different servers (same hardware and same jobs run) and I was getting similar results when I switched kernels between machines. *** 2.6.26-26lenny2 # vmstat 10 4 procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 4 0 0 5540920 0 65161600 0 0 102 277 24 2 73 0 7 0 0 5541300 0 65161600 0 0 4098 12131 23 3 75 0 1 0 0 5546456 0 65161600 0 0 4032 11665 23 2 75 0 0 0 0 5545568 0 65161600 0 0 3646 10950 25 2 73 0 # cat /proc/loadavg 2.82 2.99 2.94 1/240 24960 *** 2.6.32-30 # vmstat 10 4 procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 2 0 0 5521764 0 67694400 0 0 62 131 27 3 71 0 6 0 0 5523952 0 67694400 0 0 8339 16585 21 2 76 0 2 0 0 5525632 0 67694400 0 0 9603 19163 31 3 66 0 6 0 0 5525188 0 67695600 0 0 9474 17614 31 3 66 0 # cat /proc/loadavg 0.05 0.14 0.28 8/284 13343 *** 2.6.32-30 (patched) # vmstat 10 4 procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 2 0 0 5504608 0 65782000 0 0 24 53 26 2 72 0 0 0 0 5507128 0 65782000 0 0 8530 17326 23 2 75 0 6 0 0 5508288 0 65782400 0 0 8634 17051 26 3 72 0 4 0 0 5506352 0 65782400 0 0 9139 18106 27 3 70 0 # cat /proc/loadavg 2.31 2.10 1.94 5/284 12602 -- System Information: Debian Release: 5.0.8 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Lesław Kopeć Administrator email: leslaw.ko...@nasza-klasa.pl tel: +48 519 300 129 Nasza Klasa Sp. z o.o. ul. Gen. J. Bema 2, 50-265 Wrocław Sąd Rejonowy dla Wrocławia - Fabrycznej we Wrocławiu, VI Wydział Gospodarczy Krajowego Rejestru Sądowego, nr KRS:289629, NIP:898-21-22-104, REGON:020586020, Kapitał zakładowy: 67 850,00 PLN signature.asc Description: OpenPGP digital signature
Bug#621027: marked as done (Invalid shell option in start-statd)
From: Luk Claes l...@debian.org To: 621027-d...@bugs.debian.org Subject: Re: Invalid shell option in start-statd Date: Fri, 22 Apr 2011 08:13:56 +0200 Version: 1:1.2.3-2 On 04/22/2011 08:08 AM, Marc Glisse wrote: On Sat, 9 Apr 2011, Marc Glisse wrote: On Sat, 9 Apr 2011, Luk Claes wrote: Do you have rpcbind installed? Do you still have issues with the latest upload (1:1.2.3-2)? No, I appear to have portmap instead. I'll test the new upload (and thus the switch to rpcbind) when I get back It seems to be working fine, thank you. Thanks. Closing this bug. The submitter's original problem was fixed, but start-statd is still wrong. I've reopened this. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Processed: reopening 621027
Processing commands for cont...@bugs.debian.org:
reopen 621027
Bug #621027 {Done: Luk Claes l...@debian.org} [nfs-common] Invalid shell
option in start-statd
'reopen' may be inappropriate when a bug has been closed with a version;
you may need to use 'found' to remove fixed versions.
thanks
Stopping processing here.
Please contact me if you need assistance.
--
621027: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621027
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.13034819454014.transcr...@bugs.debian.org
Bug#623584: initramfs-tools create a wrong directory tree
On Fri, 2011-04-22 at 09:36 +0200, Giuseppe Sacco wrote: Hi, I made a few tests on this report and I found that the loader is not looking at the right directories. Please have a look at this: [...] Please note that on both system (outside of chroot) /lib64 is a link to /lib. I think that's normal; however /lib should be higher up the library search path than /lib64. What does 'ldd /bin/sh' say in the running system? [...] Beside the very last problem (I will intestigate about it), how do initramfs-tools create the lib and lib64 trees? Does it use a configuration file? It uses ldd to find which libraries each executable is linked to, and copies them to the same locations they were found in the running system. (Exception: where the library is optimised for specific CPU features, it substitutes the unoptimised alternate from the parent directory.) However, it does not copy the ld.so configuration files, and it does not unset LD_LIBRARY_PATH. Also, it does not use 'readlink -f' to resolve symbolic links, which I think would solve this particular issue. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Processed: Re: Bug#621027 closed by Luk Claes l...@debian.org (Re: Invalid shell option in start-statd)
Processing commands for cont...@bugs.debian.org: notfixed 621027 1:1.2.3-2 Bug #621027 [nfs-common] Invalid shell option in start-statd Ignoring request to alter fixed versions of bug #621027 to the same values previously set stop Stopping processing here. Please contact me if you need assistance. -- 621027: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621027 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.13034831698290.transcr...@bugs.debian.org
Bug#621027: closed by Luk Claes l...@debian.org (Re: Invalid shell option in start-statd)
notfixed 621027 1:1.2.3-2 stop Debian Bug Tracking System hat am Fri 22. Apr, 06:15 (+) geschrieben: From: Luk Claes l...@debian.org To: 621027-d...@bugs.debian.org Subject: Re: Invalid shell option in start-statd Date: Fri, 22 Apr 2011 08:13:56 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110303 Icedove/3.0.11 Version: 1:1.2.3-2 On 04/22/2011 08:08 AM, Marc Glisse wrote: On Sat, 9 Apr 2011, Marc Glisse wrote: On Sat, 9 Apr 2011, Luk Claes wrote: Do you have rpcbind installed? Do you still have issues with the latest upload (1:1.2.3-2)? No, I appear to have portmap instead. I'll test the new upload (and thus the switch to rpcbind) when I get back It seems to be working fine, thank you. Thanks. Closing this bug. No, it's not fixed: % dpkg -l nfs-common G ^ii ii nfs-common 1:1.2.3-2 NFS support files common to client and server % sed 1q =start-statd #!/bin/sh -p Bye, Jörg. -- UNIX is user friendly, it's just picky about who its friends are signature.asc Description: Digital signature http://en.wikipedia.org/wiki/OpenPGP
Bug#622333: Debian Squeeze hangs with kernel 2.6.32-5-xen-686
Hi, Ian! On Fri, 2011-04-22 at 14:19:32 +0100, Ian Campbell wrote: After upgrading to Squeeze, I am watching a Xen VMHost that after a while it hangs. This did not happen when I was using Xen with Debian Lenny (in this case as with Squeeze, the Xen components are from Debian repositories). In each case I connected a keyboard and monitor to the computer and the screen remained black without answering any key. When this happens, I noticed that the drive activity LED apparently is permanently on. I presume it also stopped responding to network e.g. ssh as well? Yes, the connection to the VMHost like its virtual machines is lost. In fact, one of the domUs has a DHCP server, and when this problem happens, the hosts that are configured with the DHCP server loses network connection. Do the magic-sysrq key combinations produce any output? I didn't get to test it, but I will remember it when it returns to happen. Can you reproduce it or did it just happen the once? If you can repro then attaching and configuring a serial console would be useful, since a) you could see if there was anything printed before the screen went dark and b) you can access the Xen debug keyhandlers only over the serial line. Were you doing anything when it hung or was the system just running in a steady state? It happened several times. Surely I would say that at least five to ten times. The last time that I had to do hard reset was 14 hours ago. Unfortunately I have not a serial cable to connect to that computer (it's a home server), but I'll see if I can get one for more information to provide. I was analyzing the /var/log/messages and the crashes occur at times that do not currently hold any pattern. I notice you are running a 32 bit hypervisor. I would highly recommend using the 64 bit hypervisor (package xen-hypervisor-4.0-amd64) even on i386. You can continue to use your 32 bit dom0 kernel and userspace but the 64 bit hypervisor is much more reliable and better tested etc. Thanks for the suggestion. I've purge the 32-bit hypervisor and I've installed the 64-bit hypervisor. I'll keep you informed. So far, records of dmesg I mentioned are still appearing. [...] -- In particular, I noticed the following lines: -- [0.00] ERROR: Unable to locate IOAPIC for GSI 2 [0.00] ERROR: Unable to locate IOAPIC for GSI 9 [0.004000] [ cut here ] [0.004000] WARNING: at /build/buildd-linux-2.6_2.6.32-31-i386-qYaaJr/linux-2.6-2.6.32/debian/build/source_i386_xen/arch/x86/xen/enlighten .c:726 perf_events_lapic_init+0x28/0x29() Thanks. This is a benign warning, unfortunately I doubt it is related to the hang. Thanks for your reply. Regards, Daniel -- Daniel Bareiro - GNU/Linux registered user #188.598 Proudly running Debian GNU/Linux with uptime: 12:13:33 up 56 days, 17:08, 12 users, load average: 0.08, 0.03, 0.01 signature.asc Description: Digital signature
Bug#620299: replace nscd with unscd closes 620299
Hi, It seems the issues is linked to a loss of connection with the ldap server. I can get the process working back after a connection failure with the ldap serversince I use unscd in replacement of nscd. Regards, Yann -- 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/4db1b17c.2040...@autissier.net
Bug#621803: Add support for /run directory
On Mon, Apr 18, 2011 at 07:38:41PM +0100, Roger Leigh wrote: On Mon, Apr 18, 2011 at 05:58:07PM +, maximilian attems wrote: On Mon, Apr 18, 2011 at 05:43:02PM +0100, rleigh wrote: I didn't see a patch in git, so I've attached a simple one here. This creates /run as a tmpfs, and moves the mount to the rootfs /run as done for other filesystems. please look harder next times! the git archive, don't know where you looked, so here it is: http://git.debian.org/?p=kernel/initramfs-tools.git;a=summary checkout the branch maks/run Ah, found it, thanks. If this is all that is needed in the main initramfs, will it take long to get the /run support into unstable? It looks like this might be a prerequisite for a fully functional udev, and for other tools that store state in the initramfs, and it's a simple and safe change to make. I've raised the severity due to the /run transition being dependent on this being fixed. there is *no* point in posting trivial patches round and round. if you'd build i-t with that branch and have it *well* tested in several different configuration, then that would be a help. What different types of configuration would you like testing? I'll be happy to test, but I'm not sure exactly what you would like varying. Current tests have been on a system with root on LVM on md RAID1 using grub2. I've also tested on a powerpc wheezy system and amd64 unstable kvm VM. No issues found. If you would like any other scenarios testing, I'll be happy to accommodate you if possible. However, given the simple nature of the patch, I'm confident it's working correctly given that it's mounted unconditionally and will be moved onto the host if /run exists in all cases. By the way, could you consider adding this patch to your branch: diff --git a/init b/init index 38c8a5d..cdbfe50 100755 --- a/init +++ b/init @@ -25,7 +25,7 @@ if ! mount -t devtmpfs -o mode=0755 none /dev; then fi mkdir /dev/pts mount -t devpts -o noexec,nosuid,gid=5,mode=0620 none /dev/pts || true -mount -t tmpfs -o nodev,noexec,nosuid,mode=0755 none /run +mount -t tmpfs -o nosuid,size=20%,mode=0755 tmpfs /run mkdir /run/initramfs # Export the dpkg architecture Slightly simpler than the previous patch, but does the same job. Please note that I've now patched initscripts (http://paste.debian.net/114826/ and http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2011-April/004990.html) so that the filesystems mounted in the initramfs and later moved over to the root filesystem are remounted with the mount options specified in /etc/fstab (or /etc/default/tmpfs if no fstab entry exists). In consequence, it's no longer critical that the mount option defaults in the initramfs match the real root filesystem defaults, because they will always be applied by mountkernfs/ mountdevsubfs. So if you choose not to apply this, that's fine--it's just a nice to have addition; the patch as it stands without the above change is equally acceptable. Thanks for doing this. Do we have any ETA on an upload? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Bug#615598: marked as done (linux-image-2.6.37-1-686: EDID data corruption (possible I2C bug))
Your message dated Fri, 22 Apr 2011 22:20:46 +0200 with message-id 20110422202046.GA5026@pisco.westfalen.local and subject line Re: Seems to be fixed in kernel 2.6.38 has caused the Debian Bug report #615598, regarding linux-image-2.6.37-1-686: EDID data corruption (possible I2C bug) 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.) -- 615598: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=615598 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-2.6 Version: 2.6.37-1 Severity: normal Tags: sid I have been running Debian on my laptop for years, and soon (possibly 3 days) after switching from testing/squeeze's version of the kernel (+Xorg + libdrm) to sid's version, my laptop's screen suddenly turned black, and didn't work upon reboot. This is apparently caused by the corruption of my laptop's screen EDID data (the first byte changed from '00' to '1a'). I believe something in the I2C subsystem (or maybe nouveau's use of it) is broken, as the number of invalid EDID reports is quite huge (EDID data is retrieved by nouveau using a DDC2 call, afaik), and there are a few I2C error reports (though much, much less than invalid EDID reports, but I had *none* with 2.6.32-1). More information on the bug I initally filed against nouveau: https://bugs.freedesktop.org/show_bug.cgi?id=34554 Note: I'm running 2.6.37-1 in spite of the corrupted EDID data, thanks to a small hack I've made in DRM to ignore the first byte of retrieved EDID data. -- Package-specific info: ** Version: Linux version 2.6.37-1-686 (Debian 2.6.37-1) (b...@decadent.org.uk) (gcc version 4.4.5 (Debian 4.4.5-10) ) #1 SMP Tue Feb 15 18:21:50 UTC 2011 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.37-1-686 root=UUID=e3d25751-8344-495e-bf99-3ac334f55242 ro quiet nouveau.vbios=PRAMIN splash ** Not tainted ** Kernel log: [19253.263668] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19253.263671] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19253.263674] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19253.263676] [19253.361528] [drm:drm_edid_block_valid] *ERROR* Raw EDID: [19253.361534] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19253.361537] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19253.361540] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19253.361543] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19253.361546] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19253.361549] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19253.361552] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19253.361555] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19253.361557] [19253.361563] nouveau :01:00.0: LVDS-1: EDID block 0 invalid. [19253.361567] [drm] nouveau :01:00.0: DDC responded, but no EDID for LVDS-1 [19283.061493] [drm:drm_edid_block_valid] *ERROR* Raw EDID: [19283.061500] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19283.061503] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19283.061506] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19283.061509] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19283.061512] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19283.061515] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19283.061518] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19283.061521] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19283.061523] [19283.162094] [drm:drm_edid_block_valid] *ERROR* Raw EDID: [19283.162101] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19283.162104] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19283.162107] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19283.162110] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19283.162113] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19283.162116] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19283.162119] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19283.162122] 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [19283.162125] [19283.259880] [drm:drm_edid_block_valid] *ERROR* Raw EDID: [19283.259886] 300 00 00 00 00 00 00 00 00 00 00 00 00
Bug#617364: linux-2.6: lseek() over NFS is returning an incorrect file length under some, circumstances
Could you check back with Joe Conway and ask for commits IDs of the upstream fixes? I've got the following info from Trond Myklebust: The upstream fix is commit 27dc1cd3ad9300f81e1219e5fc305d91d85353f8 (NFS: nfs_wcc_update_inode() should set nfsi-attr_gencount). Greg, please merge 27dc1cd3ad9300f81e1219e5fc305d91d85353f8 into 2.6.32.x (and other supported longterm kernels) It fixes the bug described in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617364 Cheers, Moritz -- 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/20110422202822.GA5376@pisco.westfalen.local
Bug#617364: [stable] Bug#617364: linux-2.6: lseek() over NFS is returning an incorrect file length under some, circumstances
On Fri, Apr 22, 2011 at 10:28:22PM +0200, Moritz Muehlenhoff wrote: Could you check back with Joe Conway and ask for commits IDs of the upstream fixes? I've got the following info from Trond Myklebust: The upstream fix is commit 27dc1cd3ad9300f81e1219e5fc305d91d85353f8 (NFS: nfs_wcc_update_inode() should set nfsi-attr_gencount). Greg, please merge 27dc1cd3ad9300f81e1219e5fc305d91d85353f8 into 2.6.32.x (and other supported longterm kernels) It fixes the bug described in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617364 Now added to the .32 and .33 longterm kernel branches, thanks. greg k-h -- 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/20110422203301.ga32...@kroah.com
Bug#313552: marked as done (kernel-image-2.6.11-alpha: qla1280 driver doesn't work with ISP1020 (PCI ID: 1077:1020))
Your message dated Fri, 22 Apr 2011 22:49:41 +0200 with message-id 20110422204941.GA7427@pisco.westfalen.local and subject line Re: kernel-image-2.6.11-alpha: qla1280 driver doesn't work with ISP1020 (PCI ID: 1077:1020) has caused the Debian Bug report #313552, regarding kernel-image-2.6.11-alpha: qla1280 driver doesn't work with ISP1020 (PCI ID: 1077:1020) 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.) -- 313552: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=313552 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: kernel-image-2.6.11-alpha Version: 2.6.11-1 Severity: important In 2.6.11, qla1280 fails to load on my system with this error: qla1280: QLA1040 found on PCI bus 1, dev 1 PCI: Setting latency timer of device :01:01.0 to 64 qla1280: Failed mbox check qla1280_mailbox_command: Command failed, mailbox0 = 0x0007, mailbox_out0 = 0x4003, istatus = 0x m0 4003, m1 , m2 , m3 aa55 m4 55aa, m5 a5a5, m6 a5a5, m7 a5a5 scsi(0): Failed checksum scsi(0): initialize: pci probe failed! qla1x160: Failed to initialize adapter qla1280: QLA1040 found on PCI bus 1, dev 2 PCI: Setting latency timer of device :01:02.0 to 64 qla1280: Failed mbox check qla1280_mailbox_command: Command failed, mailbox0 = 0x0007, mailbox_out0 = 0x4003, istatus = 0x m0 4003, m1 , m2 , m3 aa55 m4 55aa, m5 a5a5, m6 a5a5, m7 a5a5 scsi(1): Failed checksum scsi(1): initialize: pci probe failed! qla1x160: Failed to initialize adapter Still no 2.6 kernel that works completely on my alpha, alas. The PCI info for this card is: :01:01.0 SCSI storage controller: QLogic Corp. ISP1020 Fast-wide SCSI (rev 01) :01:02.0 SCSI storage controller: QLogic Corp. ISP1020 Fast-wide SCSI (rev 01) :01:01.0 0100: 1077:1020 (rev 01) :01:02.0 0100: 1077:1020 (rev 01) -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: alpha Kernel: Linux 2.6.11-1-generic Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) ---End Message--- ---BeginMessage--- Version: 2.6.38-3 On Tue, Jun 14, 2005 at 03:59:00AM -0700, Steve Langasek wrote: Package: kernel-image-2.6.11-alpha Version: 2.6.11-1 Severity: important In 2.6.11, qla1280 fails to load on my system with this error: Support for the Alpha architecture has been removed from the archive. Closing this bug with the current version in sid. Cheers, Moritz ---End Message---
Bug#524955: marked as done (linux-image-2.6-alpha-generic: kernel usb module (ohci_hcd) fails to load on UP2000+)
Your message dated Fri, 22 Apr 2011 22:47:03 +0200 with message-id 20110422204703.GA6883@pisco.westfalen.local and subject line Re: linux-image-2.6-alpha-generic: kernel usb module (ohci_hcd) fails to load on UP2000+ has caused the Debian Bug report #524955, regarding linux-image-2.6-alpha-generic: kernel usb module (ohci_hcd) fails to load on UP2000+ 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.) -- 524955: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524955 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-image-2.6-alpha-generic Version: 2.6.26+17+lenny1 Severity: important I just upgraded from etch (2.6.18) to lenny (2.6.26) and the USB (Cypress 82c693) on my UP2000+ (alpha ev67 smp) stopped working. When trying to load the ochi_hcd module: ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controler (OHCI) ochi_hcd :00:05.3: OCHI Host Controller ochi_hcd :00:05.3: new USB bus registered, assigned bus number 1 ochi_hcd :00:05.3: request interrupt 25 failed ochi_hcd :00:05.3: USB bus 1 deregistered ochi_hcd :00:05.3: init :00:05.3 fail, -16 ochi_hcd: probe of :00:05.3 failed with error -16 -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (900, 'stable') Architecture: alpha Kernel: Linux 2.6.26-2-alpha-generic Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6-alpha-generic depends on: ii linux-image-2.6.26-2-alpha-ge 2.6.26-15 Linux 2.6.26 image on Alpha linux-image-2.6-alpha-generic recommends no packages. linux-image-2.6-alpha-generic suggests no packages. -- no debconf information ---End Message--- ---BeginMessage--- Version: 2.6.38-3 On Mon, Apr 20, 2009 at 11:04:54PM -0700, Gabriele Gorla wrote: Package: linux-image-2.6-alpha-generic Version: 2.6.26+17+lenny1 Severity: important I just upgraded from etch (2.6.18) to lenny (2.6.26) and the USB (Cypress 82c693) on my UP2000+ (alpha ev67 smp) stopped working. When trying to load the ochi_hcd module: ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controler (OHCI) ochi_hcd :00:05.3: OCHI Host Controller ochi_hcd :00:05.3: new USB bus registered, assigned bus number 1 ochi_hcd :00:05.3: request interrupt 25 failed ochi_hcd :00:05.3: USB bus 1 deregistered ochi_hcd :00:05.3: init :00:05.3 fail, -16 ochi_hcd: probe of :00:05.3 failed with error -16 Support for the Alpha architecture has been removed from the archive. Closing this bug with the current version in sid. Cheers, Moritz ---End Message---
Bug#352765: marked as done (linux-2.6: wrong drivers for tulip PCI IDs on alpha?)
Your message dated Fri, 22 Apr 2011 22:51:12 +0200 with message-id 20110422205112.GA7648@pisco.westfalen.local and subject line Re: linux-2.6: wrong drivers for tulip PCI IDs on alpha? has caused the Debian Bug report #352765, regarding linux-2.6: wrong drivers for tulip PCI IDs on alpha? 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.) -- 352765: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=352765 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-2.6 Version: 2.6.15-6 Currently, the modules.pcimap for DEC tulip chips is as follows: tulip0x1011 0x0009 0x 0x 0x 0x 0x0 tulip0x1011 0x0019 0x 0x 0x 0x 0x0 de2104x 0x1011 0x0002 0x 0x 0x 0x 0x0 de2104x 0x1011 0x0014 0x 0x 0x 0x 0x0 lmc 0x1011 0x0009 0x1376 0x 0x 0x 0x0 lmc 0x1011 0x0009 0x 0x1376 0x 0x 0x0 Presently, neither de2104x nor lmc is being included in the installer images for etch; this is because discover1-data lists de4x5 as the module for *all* of these PCI IDs. With the switch to 2.6 in d-i, this means that a number of common NICs for alpha (0002, 0014, 0009) are not being auto-detected by udev. The de4x5 module *can* be loaded by hand on my own system (1011:0002), and appears to work correctly; this is the driver that I've been using under 2.6 on my installed system. I am also now testing de2104x; so far, it does appear to work. The apparent trade-off between de2104x is that de4x5 does not support full-duplex mode, whereas I have some vague impression that de2104x didn't work on my system in some earlier driver revision. However, the discover1-data changelog doesn't support this; it mentions that 1011:1002 uses de4x5 because of bug #273265, which was about tulip, not de2104x -- and tulip doesn't detect my card at all, so there's no doubt that *that* is the wrong driver. Recent discussion of this issue on debian-alpha included the following response froman Alpha expert at HP: --- From: Jay Estabrook jay.estabr...@hp.com To: debian-al...@lists.debian.org Subject: Re: testing wanted: debian-installer, now with 2.6.15 Date: Mon, 13 Feb 2006 10:53:43 -0500 On Sun, Feb 12, 2006 at 03:41:24AM -0800, Steve Langasek wrote: So should the 21040 and 21041 be switched from de2104x to de4x5, or should de2104x be added to the installer? I seem to recall that I had problems with de2104x on my 21040 as well; and at least in 2.6.15, the tulip driver doesn't work at all for my card, I have to use de4x5. The discover1-data package seems to have de4x5 listed for *all* of these PCI IDs, but I think we may be using the kernel's map now with 2.6 (via udev). I don't know of any problems using tulip on the 2114x chipsets. And I don't think full duplex will significantly increase the throughput of a 2104x chipset, so, yes, I'd think that using de4x5 for any 2104x and tulip fo any 2114x might be the way to go... --- We probably shouldn't make that change in Debian without talking to whoever's responsible for these drivers upstream, though. In the meantime, I'm going to add de2104x into the d-i images. This bug report is opened to collect success/failure reports regarding the current driver mappings, so we can be sure we're making an informed decision about these historically-problematic PCI IDs. For the record, de4x5 is currently not referenced in modules.pcimap at all, so depending on the outcome of this bug report, it may make sense to drop it completely from the 2.6 build... Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vor...@debian.org http://www.debian.org/ signature.asc Description: Digital signature ---End Message--- ---BeginMessage--- Version: 2.6.38-3 On Mon, Feb 13, 2006 at 10:43:17PM -0800, Steve Langasek wrote: Package: linux-2.6 Version: 2.6.15-6 Currently, the modules.pcimap for DEC tulip chips is as follows: tulip0x1011 0x0009 0x 0x 0x 0x 0x0 tulip0x1011 0x0019 0x 0x 0x 0x 0x0 de2104x
Bug#589804: marked as done (Implement missing syscalls on Alpha)
Your message dated Fri, 22 Apr 2011 22:52:39 +0200 with message-id 20110422205238.GA7875@pisco.westfalen.local and subject line Re: Implement missing syscalls on Alpha has caused the Debian Bug report #589804, regarding Implement missing syscalls on Alpha 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.) -- 589804: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589804 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-2.6 Version: 2.6.32-17 Severity: wishlist Tags: patch It would be nice to have the missing syscalls on Alpha wired up to bring it up to date with the other architectures. It was unfortunate that the patch sent upstream to achieve this was missed during the 2.6.32 development window and didn't get merged by Linus unto 2.6.33. I attach the patch patch-alpha-wire-up-syscalls.txt that wires up the missing syscalls on the Alpha architecture and brings it up to date with the other architectures. This patch is a modification of the upstream commits 6e17e8b9fb74b9fb9f6ea331f7f4a049c5b4c4b8 and 21797c599c710d3851d241c4b50690f2482bf618 in that it replaces the recvmmsg syscall with a placeholder as it is not available in 2.6.32. As mentioned in bug report #588409 (which is now closed) support for performance events on Alpha was merged upstream for 2.6.33. I include here the patch patch-alpha-implement-sw-perf-events.txt which is a combination of the upstream commits a582e6f01b90211933e70edcec9bc0bbb1157402 and fcd14b3203b538dca04a2b065c774c0b57863eec and wires up the performance events syscall and provides the Alpha specific code to the perf tools. I have tested both these patches applied to the Debian 2.6.32-17 kernel source (though I did have to disable the buildcheck.py script as the ABI didn't match) and it is running successfully on an Alpha PWS600au. Michael. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information system type : Tsunami system variation: Monet system revision : 0 platform string : COMPAQ Professional Workstation XP1000 ** PCI devices: :00:07.0 ISA bridge [0601]: Contaq Microsystems 82c693 [1080:c693] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 :00:07.1 IDE interface [0101]: Contaq Microsystems 82c693 [1080:c693] (prog-if 80 [Master]) Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 14 Region 0: I/O ports at 01f0 [size=8] Region 1: I/O ports at 03f4 [size=1] Region 4: I/O ports at 9440 [size=16] Kernel driver in use: pata_cypress :00:07.2 IDE interface [0101]: Contaq Microsystems 82c693 [1080:c693] (prog-if 00 []) Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin B routed to IRQ 15 Region 0: I/O ports at 0170 [size=8] Region 1: I/O ports at 0374 [size=1] Region 4: Memory at 0930 (32-bit, non-prefetchable) [disabled] [size=64K] :00:07.3 USB Controller [0c03]: Contaq Microsystems 82c693 [1080:c693] (prog-if 10 [OHCI]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 248, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 10 Region 0: Memory at 0931 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci_hcd :00:0b.0 PCI bridge [0604]: PLX Technology, Inc. PEX8112 x1 Lane PCI Express-to-PCI Bridge [10b5:8112] (rev aa) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 255, Cache Line Size: 64 bytes Bus: primary=00, secondary=01, subordinate=01, sec-latency=255 I/O behind bridge: 8000-8fff Memory behind
Bug#578477: crashes after several days of use
tags 578477 moreinfo thanks On Tue, Apr 20, 2010 at 09:21:02AM +0200, Simon Richter wrote: Package: linux-2.6 Version: 2.6.32-9 Severity: important Tags: sid Hi, I am experiencing strange crashes after a few days of use. These appear to be related to LVM. Serial console output from the crash looks like this: Does this still occur with more recent kernels? Cheers, Moritz -- 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/20110422213511.GA3049@pisco.westfalen.local
Bug#579858: xserver-xorg-video-nouveau: X fails to find nouveau device
tags 579858 moreinfo thanks On Sat, May 01, 2010 at 11:35:33PM +0530, Ritesh Raj Sarraf wrote: Package: xserver-xorg-video-nouveau Version: 1:0.0.15+git20100329+7858345-3 Severity: important Hi, I have been trying to configure nouveau for my nvidia card but looks like I have a very preliminary problem for which I did not find a solution yet. X fails complaining that it could not find any of the device in /dev/dri/cardN On my box, even with nvidia.ko loaded, I do not have the /dev/dri/ folder at all. Any ideas on where I should start investigating ? I did manually load the nouveau.ko driver as it does not autoload. Is it because of a missing udev rule ? Does this still occur with more recent kernels? Cheers, Moritz -- 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/20110422213641.GA3270@pisco.westfalen.local
Processed: Re: crashes after several days of use
Processing commands for cont...@bugs.debian.org: tags 578477 moreinfo Bug #578477 [linux-2.6] crashes after several days of use Added tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 578477: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578477 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.130350809017914.transcr...@bugs.debian.org
Processed: Re: xserver-xorg-video-nouveau: X fails to find nouveau device
Processing commands for cont...@bugs.debian.org: tags 579858 moreinfo Bug #579858 [linux-2.6] xserver-xorg-video-nouveau: X fails to find nouveau device Added tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 579858: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579858 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.130350818018209.transcr...@bugs.debian.org
Bug#581525: rt2860: rt2860 doesn't connect to WPA2 networks
tags 581525 moreinfo thanks On Thu, May 13, 2010 at 02:31:34PM +0200, Miguel Angel Fraile wrote: Package: linux-2.6 Version: 2.6.32-5 Severity: important File: rt2860 It seems it's not possible to connect to WPA2 wireless networks with the squeezix version of the rt2860 module. I've tested it with both network-manager and wicd. Both of them are unable to authenticate with the correct password. Both have NO problems to connect to WPA-PSK networks. Tested with a Buffalo WZR-HP-G300NH router. No problem connecting to that WPA2 network with other devices. The router encryption is set to WPA/WPA2-Mixed TKIP+AES, using a preshared key. Tested also after updating the rt2860 firmware-ralink to the Debian SID version (v0.24). No luck, either. Does this still occur with the final Squeeze kernel or more recent kernels? Cheers, Moritz -- 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/20110422213830.GA3488@pisco.westfalen.local
Processed: Re: rt2860: rt2860 doesn't connect to WPA2 networks
Processing commands for cont...@bugs.debian.org: tags 581525 moreinfo Bug #581525 [linux-2.6] rt2860: rt2860 doesn't connect to WPA2 networks Added tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 581525: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581525 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.130350828818387.transcr...@bugs.debian.org
Bug#623088: Options tried.
Hullo, I have tried advice found on the web about similar problems with Acer 5735Z. This was to add i915.powersave=0 pci=noacpi to the boot line (GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub). This certainly got rid of screen flicker, and reduced the frequency of the system log being flooded / reboot failure, but did not eliminate the problem which still occurs seemingly at random. The longer the computer runs the higher the risk, and it seems to me that having ac power and battery on at the same time increases the risk / frequency. Cheers, Neil
Bug#622333: Debian Squeeze hangs with kernel 2.6.32-5-xen-686
Hi again, Ian. On Friday, 22 April 2011 14:19:32 +0100, Ian Campbell wrote: Were you doing anything when it hung or was the system just running in a steady state? Well, 35 minutes ago I had another hang. Same symptoms: connecting directly a keyboard and monitor, there is no reaction when pressing any key (black screen); loss of connectivity to the dom0 and domUs. Additionally I can comment that this time the crash occurred when I was doing an aptitude update/upgrade in the dom0 and the domUs. I can also comment that the disk activity LED was constantly on (not flashing). After hard reset it seems that something was unconscious in one of the RAIDs, and is currently syncing. In /var/log/messages there is no evidence of any particular event from the previous boot. The same in kern.log and syslog. Regards, Daniel -- Daniel Bareiro - GNU/Linux registered user #188.598 Proudly running Debian GNU/Linux with uptime: 19:44:11 up 5:40, 10 users, load average: 0.00, 0.00, 0.00 signature.asc Description: Digital signature
Bug#622333: Debian Squeeze hangs with kernel 2.6.32-5-xen-686
On Friday, 22 April 2011 20:16:11 -0300, Daniel Bareiro wrote: Were you doing anything when it hung or was the system just running in a steady state? Well, 35 minutes ago I had another hang. Same symptoms: connecting directly a keyboard and monitor, there is no reaction when pressing any key (black screen); loss of connectivity to the dom0 and domUs. Additionally I can comment that this time the crash occurred when I was doing an aptitude update/upgrade in the dom0 and the domUs. I can also comment that the disk activity LED was constantly on (not flashing). After hard reset it seems that something was unconscious in one of the RAIDs, and is currently syncing. In /var/log/messages there is no evidence of any particular event from the previous boot. The same in kern.log and syslog. Here I found a thread [1] with a problem quite like this (although in my case the hardware is different: A8V-MX motherboard and AMD Athlon 64 Processor 3500+) in the xen-users mailing list. And another thread [2] which is derived from the above. I'll try using cpuidle=off or max_cstate=1 at xen cmdline in /boot/grub/grub.conf. Regards, Daniel [1] http://lists.xensource.com/archives/html/xen-users/2010-09/msg00616.html [2] http://lists.xensource.com/archives/html/xen-devel/2010-09/msg00556.html -- Daniel Bareiro - GNU/Linux registered user #188.598 Proudly running Debian GNU/Linux with uptime: 21:07:39 up 7:04, 10 users, load average: 0.08, 0.02, 0.00 signature.asc Description: Digital signature
Bug#622333: Debian Squeeze hangs with kernel 2.6.32-5-xen-686
On Friday, 22 April 2011 21:18:03 -0300, Daniel Bareiro wrote: Here I found a thread [1] with a problem quite like this (although in my case the hardware is different: A8V-MX motherboard and AMD Athlon 64 Processor 3500+) in the xen-users mailing list. And another thread [2] which is derived from the above. I'll try using cpuidle=off or max_cstate=1 at xen cmdline in /boot/grub/grub.conf. [1] http://lists.xensource.com/archives/html/xen-users/2010-09/msg00616.html [2] http://lists.xensource.com/archives/html/xen-devel/2010-09/msg00556.html Another reference from Debian BTS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619317 Regards, Daniel -- Daniel Bareiro - GNU/Linux registered user #188.598 Proudly running Debian GNU/Linux with uptime: 21:51:02 up 7:47, 10 users, load average: 0.10, 0.04, 0.01 signature.asc Description: Digital signature
Bug#607416: Bug #607416: Device table incorrect for drivers/s390/block/dasd_eckd.c: 3880/3390 should be 3880/3380
On Thu, 14 Apr 2011 11:05:37 +0200, Bastian Blank wrote: You know sta...@kernel.org? Use it. Yes, I contacted sta...@kernel.org regarding bug number 550898. But this situation is a little bit different. With 550898, IBM wrote a single git commit to fix a single bug. Asking for that commit to be back-ported was a routine matter. But for bug number 607416 it appears that they didn't do it that way. Thanks to the information provided by Jonathan Nieder, I was able to find the commit for this bug. It is listed below: - commit f85cca6b25971a09efbe4c6a3ae405d40c8f86da Merge: 6f576d5 dd30ac3 Author: Linus Torvalds torva...@linux-foundation.org Date: Mon Feb 21 14:55:49 2011 -0800 Merge branch 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6 * 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6: [S390] net: provide architecture specific NET_SKB_PAD [S390] atomic: use inline asm [S390] correct ipl parameter block safe guard [S390] atomic: use ACCESS_ONCE() for atomic_read() [S390] dasd: correct device table - As far as I can tell, only the last line is applicable to this bug. [S390] dasd: correct device table In other words, instead of producing a single fix for a single bug, they threw the fix in with several other miscellaneous fixes and enhancements. I wish IBM hadn't done it that way, but they did. Therefore, I am unsure as to how to proceed. Do I ask sta...@kernel.org to port the whole commit? (It may have dependencies on previous commits and get complicated rather quickly.) Or do I ask them to cherry pick that one-line change in drivers/s390/block/dasd_eckd.c? I could use some advice here. -- .''`. Stephen Powell : :' : `. `'` `- -- 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/345969826.117662.1303525222133.javamail.r...@md01.wow.synacor.com
Bug#607416: Device table incorrect for drivers/s390/block/dasd_eckd.c: 3880/3390 should be 3880/3380
Hi Stephen, Stephen Powell wrote: commit f85cca6b25971a09efbe4c6a3ae405d40c8f86da Merge: 6f576d5 dd30ac3 Author: Linus Torvalds torva...@linux-foundation.org Date: Mon Feb 21 14:55:49 2011 -0800 Merge branch 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6 * 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6: [S390] net: provide architecture specific NET_SKB_PAD [S390] atomic: use inline asm [S390] correct ipl parameter block safe guard [S390] atomic: use ACCESS_ONCE() for atomic_read() [S390] dasd: correct device table - As far as I can tell, only the last line is applicable to this bug. [S390] dasd: correct device table If you run git log dd30ac3 --grep='dasd: correct device table', then the fix will show up: commit 5da24b7627ff821e154a3aaecd5d60e1d8e228a5 Author: Stefan Haberland stefan.haberl...@de.ibm.com Date: Thu Feb 17 13:13:55 2011 +0100 [S390] dasd: correct device table The 3880 storage control unit supports a 3380 device type, but not a 3390 device type. Reported-by: Stephen Powell zlinux...@wowway.com Signed-off-by: Stefan Haberland stefan.haberl...@de.ibm.com Signed-off-by: Martin Schwidefsky schwidef...@de.ibm.com See http://www.kernel.org/pub/software/scm/git/docs/git-merge.html for details if curious. Do I ask sta...@kernel.org to port the whole commit? (It may have dependencies on previous commits and get complicated rather quickly.) Or do I ask them to cherry pick that one-line change in drivers/s390/block/dasd_eckd.c? I could use some advice here. Presumably that (5da24b76) is the commit to backport; I am not sure which kernels it applies to. Hope that helps, 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/20110423030950.GA17669@elie
