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 small
fraction of the build
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
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.
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
