Bug#286276: kernel-image-2.6.8-9-amd64-k8: Unable to mount md devices
On Tue, Dec 21, 2004 at 10:15:54AM -0800, Marc Singer wrote: > On Mon, Dec 20, 2004 at 02:52:50AM +0100, Goswin von Brederlow wrote: > > Marc Singer <[EMAIL PROTECTED]> writes: > > > > > On running mdadm --assemble /dev/md0 > > > > > > mdadm[4247]: segfault at 002c rip 0804b19e rsp > > > db80 error 4 > > > mdadm[4253]: segfault at 002c rip 0804b19e rsp > > > db80 error 4 > > > > That doesn't mean much. Unaligned access gets reported as such as > > well for example. > > > > Could you paste a gdb stack backtrace preverably after rebuilding > > mdadm with debug info? > > I've had a look at the mdadm side of this problem. It looks like it > is crashing because there is no configuration file. From mdadm.c > > break; > case ASSEMBLE: > if (devs_found == 1 && ident.uuid_set == 0 && > ident.super_minor == UnSet && !scan ) { > /* Only a device has been given, so get details from config > file */ > mddev_ident_t array_ident = conf_get_ident(configfile, > devlist->devname); > mdfd = open_mddev(devlist->devname, array_ident->autof); > > The conf_get_ident() is returning 0 which is then dereferenced by the > open_mddev() call and segfault'ing. configfile is NULL because none > was given. AFAICT, configfile never defaults. And even if it did, > there is no config file on my machine. > > I haven't yet looked into the code within the initrd to see what it > does. It is possible that the only way that my setup can work is if > the md driver is compiled in. > > Still, I wonder about the ioctl errors that I see with fdisk. I took a breif look at initrd and for reference have included how it handles mdadm below. I think that the important bit is that it passes not only the md device but its component devices to mdadm -A (--assemble). It seems to me that as your invocation does not do that, it is going into a code path in mdadm that has a bug in it and thus segfaults. In a nutshell, I don't think it is a kernel problem. -- Horms getraid_mdadm() { mdadm=$(mdadm -D "$device") || { echo "$PROG: mdadm -D $device failed" >&2 exit 1 } eval "$( echo "$mdadm" | awk ' $1 == "Raid" && $2 == "Level" { print "echo " $4; next } $1 == "Number" && $2 == "Major" { start = 1; next } $1 == "UUID" { print "uuid=" $3; start = 0; next } !start { next } $2 == 0 && $3 == 0 { next } { devices = devices " " $NF } END { print "devices='\''" devices "'\''" } ' )" printf '%s\n' $devices > getroot echo mdadm -A /devfs/md/$minor -R -u $uuid $devices \ > md$minor-script echo /sbin/mdadm >&6 }
Bug#286276: kernel-image-2.6.8-9-amd64-k8: Unable to mount md devices
On Wed, Dec 22, 2004 at 03:39:32PM +0900, Horms wrote: > > Still, I wonder about the ioctl errors that I see with fdisk. > > I took a breif look at initrd and for reference have included > how it handles mdadm below. I think that the important bit > is that it passes not only the md device but its component > devices to mdadm -A (--assemble). It seems to me that as your > invocation does not do that, it is going into a code path > in mdadm that has a bug in it and thus segfaults. In a nutshell, > I don't think it is a kernel problem. I forgot to mention that I tried passing the component devices to mdadm along with the /dev/md0. Still a segfault. I haven't tried with the UUID, too. > -- > Horms > > getraid_mdadm() { > mdadm=$(mdadm -D "$device") || { > echo "$PROG: mdadm -D $device failed" >&2 > exit 1 > } > eval "$( > echo "$mdadm" | awk ' > $1 == "Raid" && $2 == "Level" { print "echo " $4; > next } > $1 == "Number" && $2 == "Major" { start = 1; next } > $1 == "UUID" { print "uuid=" $3; start = 0; next } > !start { next } > $2 == 0 && $3 == 0 { next } > { devices = devices " " $NF } > END { print "devices='\''" devices "'\''" } > ' > )" > > printf '%s\n' $devices > getroot > echo mdadm -A /devfs/md/$minor -R -u $uuid $devices \ > > md$minor-script > echo /sbin/mdadm >&6 > }
Bug#286276: kernel-image-2.6.8-9-amd64-k8: Unable to mount md devices
On Wed, Dec 22, 2004 at 03:39:32PM +0900, Horms wrote: > On Tue, Dec 21, 2004 at 10:15:54AM -0800, Marc Singer wrote: > > On Mon, Dec 20, 2004 at 02:52:50AM +0100, Goswin von Brederlow wrote: > > > Marc Singer <[EMAIL PROTECTED]> writes: > > > > > > > On running mdadm --assemble /dev/md0 > > > > > > > > mdadm[4247]: segfault at 002c rip 0804b19e rsp > > > > db80 error 4 > > > > mdadm[4253]: segfault at 002c rip 0804b19e rsp > > > > db80 error 4 > > > > > > That doesn't mean much. Unaligned access gets reported as such as > > > well for example. > > > > > > Could you paste a gdb stack backtrace preverably after rebuilding > > > mdadm with debug info? > > > > I've had a look at the mdadm side of this problem. It looks like it > > is crashing because there is no configuration file. From mdadm.c > > > > break; > > case ASSEMBLE: > > if (devs_found == 1 && ident.uuid_set == 0 && > > ident.super_minor == UnSet && !scan ) { > > /* Only a device has been given, so get details from > > config file */ > > mddev_ident_t array_ident = conf_get_ident(configfile, > > devlist->devname); > > mdfd = open_mddev(devlist->devname, array_ident->autof); > > > > The conf_get_ident() is returning 0 which is then dereferenced by the > > open_mddev() call and segfault'ing. configfile is NULL because none > > was given. AFAICT, configfile never defaults. And even if it did, > > there is no config file on my machine. > > > > I haven't yet looked into the code within the initrd to see what it > > does. It is possible that the only way that my setup can work is if > > the md driver is compiled in. > > > > Still, I wonder about the ioctl errors that I see with fdisk. > > I took a breif look at initrd and for reference have included > how it handles mdadm below. I think that the important bit > is that it passes not only the md device but its component > devices to mdadm -A (--assemble). It seems to me that as your > invocation does not do that, it is going into a code path > in mdadm that has a bug in it and thus segfaults. In a nutshell, > I don't think it is a kernel problem. > > -- > Horms > > getraid_mdadm() { > mdadm=$(mdadm -D "$device") || { > echo "$PROG: mdadm -D $device failed" >&2 > exit 1 > } > eval "$( > echo "$mdadm" | awk ' > $1 == "Raid" && $2 == "Level" { print "echo " $4; > next } > $1 == "Number" && $2 == "Major" { start = 1; next } > $1 == "UUID" { print "uuid=" $3; start = 0; next } > !start { next } > $2 == 0 && $3 == 0 { next } > { devices = devices " " $NF } > END { print "devices='\''" devices "'\''" } > ' > )" > > printf '%s\n' $devices > getroot > echo mdadm -A /devfs/md/$minor -R -u $uuid $devices \ > > md$minor-script > echo /sbin/mdadm >&6 > } So, if I understand correctly, if I were to add the UUID of the devices then I'd probably have a working solution? I can certainly try that.
Bug#286276: kernel-image-2.6.8-9-amd64-k8: Unable to mount md devices
On Wed, Dec 22, 2004 at 03:39:32PM +0900, Horms wrote: > I took a breif look at initrd and for reference have included > how it handles mdadm below. I think that the important bit > is that it passes not only the md device but its component > devices to mdadm -A (--assemble). It seems to me that as your > invocation does not do that, it is going into a code path > in mdadm that has a bug in it and thus segfaults. In a nutshell, > I don't think it is a kernel problem. Adding the UUID to the mdadm command line allows MD to assemble the raid. So, that answers the question "why doesn't mdadm assembled once the machine is booted." Now, the question is this: with the md and raid modules added to the initrd, why doesn't initrd find and start the raid array? > > -- > Horms > > getraid_mdadm() { > mdadm=$(mdadm -D "$device") || { > echo "$PROG: mdadm -D $device failed" >&2 > exit 1 > } > eval "$( > echo "$mdadm" | awk ' > $1 == "Raid" && $2 == "Level" { print "echo " $4; > next } > $1 == "Number" && $2 == "Major" { start = 1; next } > $1 == "UUID" { print "uuid=" $3; start = 0; next } > !start { next } > $2 == 0 && $3 == 0 { next } > { devices = devices " " $NF } > END { print "devices='\''" devices "'\''" } > ' > )" > > printf '%s\n' $devices > getroot > echo mdadm -A /devfs/md/$minor -R -u $uuid $devices \ > > md$minor-script > echo /sbin/mdadm >&6 > }
Bug#286803: kernel-source-2.6.9: Kind of a memory leak in kernel 2.6?
Package: kernel-source-2.6.9 Version: 2.6.9-3 Severity: normal Hi. I do not even know if this is a bug. I can only say that the kernel does not behave according to my expectations. The problem is not easy to explain, nor easy to reproduce. I'll try to explain with increasing detail. Stop to read whenever you can tell if my expectations are wrong, or you know what the bug is. My situation is the following: I work as a developer for MySQL AB. I have to work with a couple of source trees. One or more for each MySQL version, depending on the number of projects I am working on. I need to ./configure, make, test, edit, grep through sources, make, test and so forth. My expectation was that a lot of RAM would provide much memory for the file system cache. That way, I hoped, lots of disk reads would become unnecessary and everything would go faster. The problem is that this did not work out. Every time when I run a make on a MySQL source tree, I "loose" some of my memory. More specifically spoken, the amount of memory, called "Active" increases, while "Cached" decreases (names are taken from /proc/meminfo). Just to avoid misunderstandings: "Active" does not fall back to what it was before the the make process started. After running MySQL makes a couple of times, "Active" occupies about 80 to 90% of the RAM. After that, it does not grow any more. Nevertheless, only a small fraction of my expensive RAM is left for the file system cache. Fortunately, it is possible to "get back" the "lost" memory by massive file system operations. But this implies disk reads, which I wanted to diminish. This problem, which might be a bug or a misunderstanding of how Linux uses RAM, is _not_ new to kernel 2.6.9. I watched it at least with 2.6.8 and 2.6.7. I am not sure about earlier versions, since I do not work with MySQL that long yet. I did not yet report the problem, since I thought that everyone has already noticed it and it would be solved in the next version. Today I buried that hope, sat down and wrote this report. My hope is that a kernel developer has special tools to analyze, what kind of pages are left over as "Active" after the make. So he would find a bug and make me happy with the next kernel version. Or that someone tells me to switch on or off some kernel parameter or something alike. I prepared two ways to reproduce the problem. Step 1.) and 2.) use a MySQL source tree and build a binary. Step 3.) is an alternative way without MySQL sources, but it is much less efficient to reproduce the memory "leak". Before starting, my file system cache is beautifully filled: sleep 40 && cat /proc/meminfo MemTotal: 2075608 kB MemFree: 94448 kB Buffers:244608 kB Cached:1555968 kB SwapCached: 0 kB Active: 256340 kB Inactive: 1598516 kB HighTotal: 1179072 kB HighFree:74432 kB LowTotal: 896536 kB LowFree: 20016 kB SwapTotal: 1052248 kB SwapFree: 1052248 kB Dirty: 0 kB Writeback: 0 kB Mapped: 71880 kB Slab: 101580 kB Committed_AS:91712 kB PageTables: 1212 kB VmallocTotal: 114680 kB VmallocUsed: 14352 kB VmallocChunk:99316 kB 1.) Get a MySQL source tree and build a MySQL version: You need quite current versions of the autotools. I have: ii autoconf 2.59-8 ii automake1.7 1.7.9-6 ii libtool 1.5.6-2 wget http://ftp.gwdg.de/pub/misc/mysql/Downloads/MySQL-4.0/mysql-4.0.23.tar.gz tar xzf mysql-4.0.23.tar.gz cd mysql-4.0.23 sleep 40 && cat /proc/meminfo > meminfo-1.txt BUILD/compile-pentium-debug-max # runs about 10 to 20 minutes sleep 40 && cat /proc/meminfo > meminfo-2.txt The result is (meminfo-1, meminfo-2, difference, unchanged rows left out): diff -y meminfo-1.txt meminfo-2.txt | perl -n -e 's/^(.{13}\s+)(\d+) kB\s+\|\s.{13}(\s+)(\d+).*// && printf("%s%s kB%s%s kB = %10d\n", $1, $2, $3, $4, $4-$2)' MemFree: 94448 kB 175308 kB = 80860 Buffers:244724 kB 283420 kB = 38696 Cached:1555968 kB 1178168 kB =-377800 Active: 256416 kB 869988 kB = 613572 Inactive: 1598628 kB 902712 kB =-695916 HighFree:74432 kB 107328 kB = 32896 LowFree: 20016 kB67980 kB = 47964 Dirty: 8 kB49672 kB = 49664 Mapped: 71956 kB72804 kB =848 Slab: 101584 kB 102960 kB = 1376 Which, if I understand correctly, means that the active memory increased by 600 MB. The file system cache "lost" 370 MB, wich is OK of course, since the build processes needed memory during their work. I expected that a second build on the same tree would result in no major changes in the memory printout. The active memory, used during the first run, should be reused for the second run. And the cache should stay at 1GB (unless I build two or more trees at once). But: 2.) After building MySQL once like above you can concentrate on the sm
Bug#286803: kernel-source-2.6.9: Kind of a memory leak in kernel 2.6?
MySQL Development wrote: [snip] > The problem is that this did not work out. Every time when I run a make on a > MySQL source tree, I "loose" some of my memory. More specifically spoken, the > amount of memory, called "Active" increases, while "Cached" decreases (names > are taken from /proc/meminfo). Just to avoid misunderstandings: "Active" does > not fall back to what it was before the the make process started. After > running MySQL makes a couple of times, "Active" occupies about 80 to 90% of > the RAM. After that, it does not grow any more. Nevertheless, only a small > fraction of my expensive RAM is left for the file system cache. Have you tried to adjust /proc/sys/vm/vfs_cache_pressure ? linux/Documentation/filesystems/proc.txt might be worth a read. Thiemo
Bug#284356: SONAME bumping and d-i
Hi, I have put together the packages that I would like to upload as kernel-source-2.4.27 2.4.27-7 and kernel-image-2.4.27-i386 2.4.27-7. This includes increasing the SONAME to 2. Could anyone who is interesetd please take a look. http://debian.vergenet.net/pending/ Andreas, let me know when you are ready to go with 2.6. -- Horms
Blank console text with kernel 2.6.8 and 2.6.9
Hi, I want to upgrade my debian SID/kernel 2.4 to kernel 2.6. If i use kernel-image-2.6.x : no problem, but, if i build my own kernel (from debian source), i loose konsoles text (Alt F1 - F6) ! During the boot process, just after the line "Calculating modules dependencies ...", the screen becomes blank with vertical lines (unreadable) ? No problem with Xfree. But konsoles (Alt F1-F6) stays unreadables. My config : MB K7S5A (SiS 735)/ Duron 1300 / Matrox MGA G400 AGP I try to play with vga=xxx in lilo.conf but without success. This is what i do : # apt-get update # apt-get install kernel-image-2.6.8-1-k7 No problem here if i reboot i get konsoles # apt-get update # apt-get install kernel-source-2.6.8 # cd /usr/src/kernel-source-2.6.8 # make menuconfig -> load /boot/config-2.6.8-1-k7 -> save # make-kpkg --append_to_version -1-gr --initrd --revision GR.1.0 kernel-image # cd .. # dpkg -i kernel-image-2.6.8-1-gr_GR.1.0_i386.deb # reboot With this new kernel i loose konsoles ... (note: idem with 2.6.9) Thanks Guy Roussin
Re: Bug#286276: kernel-image-2.6.8-9-amd64-k8: Unable to mount md devices
On Wed, 2004-12-22 at 01:23 -0800, Marc Singer wrote: > On Wed, Dec 22, 2004 at 03:39:32PM +0900, Horms wrote: > > I took a breif look at initrd and for reference have included > > how it handles mdadm below. I think that the important bit > > is that it passes not only the md device but its component > > devices to mdadm -A (--assemble). It seems to me that as your > > invocation does not do that, it is going into a code path > > in mdadm that has a bug in it and thus segfaults. In a nutshell, > > I don't think it is a kernel problem. > > Adding the UUID to the mdadm command line allows MD to assemble the > raid. So, that answers the question "why doesn't mdadm assembled once > the machine is booted." > > Now, the question is this: with the md and raid modules added to the > initrd, why doesn't initrd find and start the raid array? I have an outstanding bug with this same issue. Except, I used udevd, it wasn't creating the /dev nodes soon enough. I had to revert to non-udevd /dev. This solved the mounting problems after the initrd mounted the root fs, which all md (mirrored). with udev, mdadm could not find anything except /. The following is what I have working beautifully. [EMAIL PROTECTED]:~$ df FilesystemSize Used Avail Use% Mounted on /dev/md1 1.9G 60M 1.9G 4% / tmpfs 475M 0 475M 0% /dev/shm /dev/md0 139M 4.6M 134M 4% /boot /dev/md4 9.6G 18M 9.6G 1% /home /dev/md3 972M 656K 972M 1% /tmp /dev/md5 15G 179M 15G 2% /usr /dev/md2 9.6G 239M 9.3G 3% /var Dunno if it is related. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: Problem with XFS and/or VM deadlock in 2.6.8
On Wed, Dec 22, 2004 at 09:16:00AM -0500, Lennart Sorensen wrote: > I have been having trouble with the filesystem apparently locking up on > a P4 2.8GHz HT machine (1GB ram, dual 120G SATA in raid1 with LVM on > top). > > It locks up when I try and delete a lot of small files at once. > Yesterday I tried to go delete a build dir for gcc-3.3 and while waiting > for that 1.1GB to be deleted, went to delete a few other source dirs. > When it got down to about 38M left for gcc-3.3 it stopped getting any > further and top just showed rm in state D. A few other rm's eventually > hit that state too. > > When I went to reboot the machine to get it back to working normally, I > noticed the console had a bunch of messages from XFS and the VM. So I > saved the messages in the hopes someone can figure something out to make > this go away. > > Kernel version: 2.6.8-1-686-smp v2.6.8-10 (Debian sarge/sid build). All this should be fixed in 2.6.10-rc3. The XFS code in Debian's 2.6.8 is very much out of data and has various problems, but 2.6.8 is already really old and the various required core code changes make it hard to backport the XFS fixes.
Re: Problem with XFS and/or VM deadlock in 2.6.8
On Wed, Dec 22, 2004 at 06:21:03PM +, Christoph Hellwig wrote: > All this should be fixed in 2.6.10-rc3. The XFS code in Debian's 2.6.8 > is very much out of data and has various problems, but 2.6.8 is already > really old and the various required core code changes make it hard to > backport the XFS fixes. Well I will keep an eye out for when 2.6.10 is released then and upgrade to that. As long as it is a known and fixed problem I can live with that. It hasn't been and issue for me more than once a month or so when I go on major cleanup hunts. I was starting to think I had to convert to ext3 which would be quite a hassle. Len Sorensen
kernel-patch-powerpc-2.6.9_2.6.9-2_powerpc.changes UNACCEPT
Rejected: Rejected: kernel-image-power3-smp_2.6.9-2_powerpc.deb: old version (100) in unstable >= new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-patch-powerpc-2.6.9_2.6.9-2_all.deb: old version (2.6.9-3) in unstable >= new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-patch-powerpc-2.6.9_2.6.9-2.dsc: old version (2.6.9-3) in unstable >= new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-build-2.6.9-powerpc-smp_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable >= new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-build-2.6.9-power3-smp_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable >= new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-build-2.6.9-power3_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable >= new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-power3_2.6.9-2_powerpc.deb: old version (100) in unstable >= new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-2.6.9-powerpc_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable >= new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-2.6.9-power3-smp_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable >= new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-powerpc_2.6.9-2_powerpc.deb: old version (100) in unstable >= new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-2.6.9-power3_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable >= new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-power4-smp_2.6.9-2_powerpc.deb: old version (100) in unstable >= new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-build-2.6.9-powerpc_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable >= new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-2.6.9-power4_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable >= new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-2.6.9-powerpc-smp_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable >= new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-power4_2.6.9-2_powerpc.deb: old version (100) in unstable >= new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-build-2.6.9-power4_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable >= new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-build-2.6.9-power4-smp_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable >= new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-2.6.9-power4-smp_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable >= new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-powerpc-smp_2.6.9-2_powerpc.deb: old version (100) in unstable >= new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-headers-2.6.9_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable >= new version (2.6.9-2) targeted at unstable. === Despite being ACCEPTed, this package failed the database sanity checks at the time of install. This should only happen rarely and in corner-cases (a binary upload of a package which has since been melanie'd for example), so no code to do the necessary unaccept actions has been written. These actions (e.g. bug reopening, announcement rescinding, etc.) will have to be done by hand. Also, the files have been left in the accepted directory; please deal with them as well.
Bug#285430: Patch for mkinitrd and the a100u2w
Here's a patch that fixed the mkinitrd script in my case and allowed it to successfully build an image with the a100u2w module: --- mkinitrd2004-12-22 14:31:35.0 -0800 +++ mkinitrd-a100 2004-12-22 14:30:15.0 -0800 @@ -516,5 +516,6 @@ s/^GVP11$/gvp11/; t s/^INI9100U$/initio/; t - s/^INIA100$/inia100/; t + s/^INIA100$/a100u2w/; t + s/^inia100$/a100u2w/; t s/^mac5380$/mac_scsi/; t s/^MVME147$/mvme147/; t -- Seth "ad aster per aspera" Mattinen [EMAIL PROTECTED]
Bug#286915: kernel-image-2.6.9-9-amd64-k8: 32 bit Alsa utilities do not work against 64 bit kernel
Package: kernel-image-2.6.9-9-amd64-k8 Version: 2.6.9-4 Severity: important When trying to start or use alsa I get the following errors: ioctl32(alsactl:4613): Unknown cmd fd(3) cmd(80045500){00} arg(d85c) on /dev/snd/controlC0 ioctl32(alsactl:5672): Unknown cmd fd(3) cmd(80045500){00} arg(d39c) on /dev/snd/controlC0 ioctl32(alsamixer:5673): Unknown cmd fd(3) cmd(80045500){00} arg(d4bc) on /dev/snd/controlC0 ioctl32(aplay:5674): Unknown cmd fd(3) cmd(80045500){00} arg(d33c) on /dev/snd/controlC0 ioctl32(aplay:5733): Unknown cmd fd(3) cmd(80045500){00} arg(d33c) on /dev/snd/controlC0 ioctl32(speaker-test:5740): Unknown cmd fd(3) cmd(80045500){00} arg(d0cc) on /dev/snd/controlC0 ioctl32(speaker-test:5741): Unknown cmd fd(3) cmd(80045500){00} arg(d0cc) on This, of course, means that ALSA cannot be used, as all volumes are by default 0, meaning that even if you could make sound, which does not appear to be the case, then you would not be able to hear it anyway. For reference, I have the 1.0.7-2 alsa-utils installed. Cheers, Paul -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 2.6.9-9-amd64-k8 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages kernel-image-2.6.9-9-amd64-k8 depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii initrd-tools 0.1.74 tools to create initrd image for p ii module-init-tools 3.1-rel-2 tools for managing Linux kernel mo -- no debconf information