Bug#317756: Framebuffer settings
On Mon, 25 Jul 2005, Dave Love wrote: That does get me the pointer under X. When X shuts down, it leaves traces of the desktop around a shrunken version of the console in the middle of the display; I don't know if that's expected. Well, at least we have a workaround. Are such kernel args actually documented anywhere? Only in the module source, I'm afraid. You can do something like grep -i module_par drivers/video/aty/atyfb_base.c to see all the the options supported by the atyfb driver and their (very short) descriptions. Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Conflict during boot between genrtc and rtc also in 2.6.8-2
Processing commands for [EMAIL PROTECTED]: found 319755 2.6.8-2 Bug#319755: linux-image-2.6.12-1-686: conflict during boot between genrtc and rtc Bug marked as found in version 2.6.8-2. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312973: kernel-image-2.6.11-1-686: 2.6.12 -- no dice
Package: kernel-image-2.6.11-1-686 Version: 2.6.11-7 Followup-For: Bug #312973 I tested with 2.6.12, and it still drifts. There appears to be no difference in how the drift amount is selected on boot; sometimes it drifts a lot, sometimes a little. Still. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages kernel-image-2.6.11-1-686 depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii fileutils 5.2.1-2The GNU file management utilities ii initrd-tools 0.1.81.1 tools to create initrd image for p ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo kernel-image-2.6.11-1-686 recommends no packages. -- no debconf information --- [This E-mail scanned for viruses by Declude Virus] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319657: marked as done (linux-image-2.6.12-1-686: /vmlinuz and /initrd symlinks were botched after installing 2.6.12)
Your message dated Wed, 27 Jul 2005 22:47:10 -0700 with message-id [EMAIL PROTECTED] and subject line Bug#319657: fixed in kernel-package 9.004 has caused the attached Bug report 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 I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 23 Jul 2005 18:47:13 + From [EMAIL PROTECTED] Sat Jul 23 11:47:13 2005 Return-path: [EMAIL PROTECTED] Received: from qix.demiurgestudios.com [12.151.131.245] by spohr.debian.org with esmtp (Exim 3.36 1 (Debian)) id 1DwP1k-0001Mo-00; Sat, 23 Jul 2005 11:47:13 -0700 Received: from localhost ([127.0.0.1] helo=mole.internal.demiurgestudios.com) by qix.demiurgestudios.com with esmtp (Exim 3.35 #1 (Debian)) id 1DwP1j-0005SI-00; Sat, 23 Jul 2005 14:47:11 -0400 Received: by mole.internal.demiurgestudios.com (Postfix, from userid 501) id 339BB41E30C; Sat, 23 Jul 2005 14:47:08 -0400 (EDT) Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Andrew Moise [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: linux-image-2.6.12-1-686: /vmlinuz and /initrd symlinks were botched after installing 2.6.12 X-Mailer: reportbug 3.15 Date: Sat, 23 Jul 2005 14:47:08 -0400 Message-Id: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 Package: linux-image-2.6.12-1-686 Version: 2.6.12-1 Severity: normal After installing linux-image, the automatic run of lilo failed. I found that that had been because my /vmlinuz symlink pointed to '/boot/-2.6' and my /initrd.img to '/boot/-2.6'. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- no debconf information --- Received: (at 319657-close) by bugs.debian.org; 28 Jul 2005 06:17:55 + From [EMAIL PROTECTED] Wed Jul 27 23:17:55 2005 Return-path: [EMAIL PROTECTED] Received: from katie by spohr.debian.org with local (Exim 3.36 1 (Debian)) id 1Dy1Ec-0006r0-00; Wed, 27 Jul 2005 22:47:10 -0700 From: Manoj Srivastava [EMAIL PROTECTED] To: [EMAIL PROTECTED] X-Katie: $Revision: 1.56 $ Subject: Bug#319657: fixed in kernel-package 9.004 Message-Id: [EMAIL PROTECTED] Sender: Archive Administrator [EMAIL PROTECTED] Date: Wed, 27 Jul 2005 22:47:10 -0700 Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-CrossAssassin-Score: 5 Source: kernel-package Source-Version: 9.004 We believe that the bug you reported is fixed in the latest version of kernel-package, which is due to be installed in the Debian FTP archive: kernel-package_9.004.dsc to pool/main/k/kernel-package/kernel-package_9.004.dsc kernel-package_9.004.tar.gz to pool/main/k/kernel-package/kernel-package_9.004.tar.gz kernel-package_9.004_all.deb to pool/main/k/kernel-package/kernel-package_9.004_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Manoj Srivastava [EMAIL PROTECTED] (supplier of updated kernel-package package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 28 Jul 2005 00:13:15 -0500 Source: kernel-package Binary: kernel-package Architecture: source all Version: 9.004 Distribution: unstable Urgency: low Maintainer: Manoj Srivastava [EMAIL PROTECTED] Changed-By: Manoj Srivastava [EMAIL PROTECTED] Description: kernel-package - A utility for building Linux kernel related Debian packages. Closes: 319452 319515 319543 319632
Processed: Re: Bug#320053: kernel-image-2.6.8-2-686: Installing it with sarge leads to failing at booting next time
Processing commands for [EMAIL PROTECTED]: reassign 298623 kernel-source-2.6.8 Bug#298623: kernel oops on load of i810_audio in gateway 7320GZ laptop Bug#287411: 2.4/2.6 kernel oops on load of i810_audio in hp pavilion ze4900 laptop Bug reassigned from package `kernel' to `kernel-source-2.6.8'. reassign 320053 kernel-source-2.6.8 Bug#320053: kernel-image-2.6.8-2-686: Installing it with sarge leads to failing at booting next time Bug reassigned from package `kernel-image-2.6.8-2-686' to `kernel-source-2.6.8'. severity 320053 normal Bug#320053: kernel-image-2.6.8-2-686: Installing it with sarge leads to failing at booting next time Severity set to `normal'. merge 298623 320053 Bug#298623: kernel oops on load of i810_audio in gateway 7320GZ laptop Bug#320053: kernel-image-2.6.8-2-686: Installing it with sarge leads to failing at booting next time Bug#287411: 2.4/2.6 kernel oops on load of i810_audio in hp pavilion ze4900 laptop Merged 287411 298623 320053. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 upload
On Wed, Jul 27, 2005 at 11:20:29PM +0200, Goswin von Brederlow wrote: Horms [EMAIL PROTECTED] writes: We seem to be running around in circles here. If an image package depends on kernel-tree-x.y.z-N, then kernel-source-x.y.z can be updated and the image can still be rebuilt, verbatim. Let me try and illustrate by example: * kernel-source-2.6.8 version 2.6.8-1 is released * kernel-image-2.6.8-i386 version 2.6.8-1 is released with a dependancy on kernel-tree-2.6.8-1 * kernel-source-2.6.8 version 2.6.8-2 is released * kernel-image-2.6.8-i386 is not updated, but can still be rebuilt using kernel-source-2.6.8 version 2.6.8-1 or version 2.6.8-2 Now, if di could use the kernel-tree dependancies, then kernel-source can be updated and the di images can still be rebuilt. -- Horms But that all went out the window with the linux-2.6 source upload. Now it is linux-2.6 version 2.6.12-1 getting replaced by 2.6.13-1 and kernel-tree-2.6.12-1 is repalced by kernel-tree-2.6.13-1. No more 2.6.12 source for the images. Yes, that would obviously be a problem, though this might be solvable by coordinating upgrading the upstream version between the kernel and d-i teams. Upstream movement is unlikely to occur close to release, and Franz Pop already mentioned that nightly builds were acceptable for most other times. And D-I does not have a depends or build-depends on the tree anyway as it downloads the precompiled debs, unpacks them and repack them differently as udebs. The best and only solution sofar is to megre the linux-kernel-di-arch udebs into the linux-2.6 package and get them build directly when the source is compiled. I tend to aggree, though I believe Franz Pop, or perhaps some of the other d-i team members have reason for keeping these images separate. Perhaps they could reiterate them here. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: i915 DRI broken after suspend/resume
On Fri, Jul 29, 2005 at 01:08:53AM +1000, Drew Parsons wrote: On Wed, 2005-07-27 at 18:29 +0900, Horms wrote: On Wed, Jul 27, 2005 at 10:45:20AM +0200, David MartÃnez Moreno wrote: El Martes, 26 de Julio de 2005 05:20, Drew Parsons escribió: Intel video driver (855GM etc) support is broken in Debian (linux-tree-2.6 v2.6.12-1, xserver-xorg v6.8.2.dfsg.1-4) at the moment. That's the i810 Xserver driver using the i915 kernel drm module. This is a known bug, reported at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159960 and https://bugzilla.ubuntu.com/show_bug.cgi?id=7787 and http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg21138.html A kernel patch to i915 is also needed (provided by dri.freedesktop.org, exact urls mentioned in the Redhat bug report). They seem more like tarballs with new drivers than patches. Which makes it somewhat difficult to isolate the fix. Ah, sorry about that. I had just assumed they were patches for this specific problem. I hope the patches turn up soon then (or the fixes find their way properly into upstream source). No problem, though I was secretly hoping you had the patches :) Is there any value in the patches been added to the debian kernel at this stage? And more to the point, is there any information on the status of this change in the upstream (linus) kernel. Plenty of value ;) So those of us with this hardware can use their laptops properly :) I guess you mean whether or not the fix is already in 2.6.13, which I can't confirm. What I ment was, has the situation stabalised? If there are patches that work, lets get them in. But if they DRI stuff is in a phase of broken/fixed on a weekly basis, I'd rather wait for the dust to settle a bit. Or at the very least, for some patches to appear on upstream's radar. Mind you, my situation has now become even more confused. Yesterday I updated the BIOS in the hope of fixing other problems (the laptop regularly freezes after 10-15 mins on battery after being unplugged from AC power), and now resume from S3 does not work - the entire system (never mind DRI) is now frozen on resume ;( :( -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312973: kernel-image-2.6.11-1-686: 2.6.12 -- no dice
On Wed, Jul 27, 2005 at 06:07:06PM -0500, Chris Howie wrote: Package: kernel-image-2.6.11-1-686 Version: 2.6.11-7 Followup-For: Bug #312973 I tested with 2.6.12, and it still drifts. There appears to be no difference in how the drift amount is selected on boot; sometimes it drifts a lot, sometimes a little. Still. Thanks for the follow up. I am less suspicious of it being a debian problem and more suspicious of it being an upstream problem. Though I am still entirely unsure what to do about it, other than booting with noacpi. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320256: (kernel-image-2.4.27-2-k6: FTBFS on its intended target) : more info
I tried to build this kernel on a newer PIV. This dos *not* build with gcc 4.0 or gcc 3.4, but *does* build with gcc 3.3 I'll try this on the target machine, and let you know. -- Emmanuel Charpentier[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320053: kernel-image-2.6.8-2-686: Installing it with sarge leads to failing at booting next time
reassign 298623 kernel-source-2.6.8 reassign 320053 kernel-source-2.6.8 severity 320053 normal merge 298623 320053 thanks On Wed, Jul 27, 2005 at 05:40:59PM +0200, stefan wrote: hi thx for your answer... i don't see why this bug is related to me... another developer just mailed me and showed me this bugreport: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298623 and this is exactly my problem g Yes, I think you are correct, I have merged these bugs accordingly. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320091: kernel-image-2.6.8-2-386: Boot fails with a syntax error in /scripts/ext3-add-journal.sh
On Wed, 27 Jul 2005, Horms wrote:
And I do wonder if this script should be on the initrd image at all.
Could you poke around for difference between your working initrd
image for kernel-image-2.6.8-1-386 and the broken one for
kernel-image-2.6.8-2-386?
There are some--probably best I just give you the scripts:
--- kernel-image-2.6.8-1 initrd /scripts/ext3-add-journal.sh --
#!/bin/sh
cd /
mount -nt proc proc proc
rootdev=$(cat proc/sys/kernel/real-root-dev)
cmdline=$(cat /proc/cmdline)
umount -n proc
if [ $rootdev != 256 ]; then
mount -nt tmpfs tmpfs /dev2
mount -nt proc proc /proc
mount -nt devfs devfs /devfs /dev/null 21
get_device
mount_device
if test -f /mnt/etc/fstab ; then
ext3root=`awk '!/^ *#/ { if (($2 == /) ($3 == ext3)) {print
$1;}}' /mnt/etc/fstab`
ext2root=`awk '!/^ *#/ { if (($2 == /) ($3 == ext2)) {print
$1;}}' /mnt/etc/fstab`
fi
umount -n /devfs /dev/null 21
umount -n /mnt /dev/null 21
if test -n $ext3root -o -n $ext2root ; then
mount -nt tmpfs tmpfs /etc
echo /etc/fstab
echo /etc/mtab
if test -n $ext3root ; then
/sbin/tune2fs -O has_journal /dev2/root2 /dev/null 21
else
/sbin/tune2fs -O ^has_journal /dev2/root2 /dev/null 21
fi
umount -n /etc
fi
umount -n /dev2
umount -n /proc /dev/null 21
fi
---
--- kernel-image-2.6.8-2 initrd /scripts/ext3-add-journal.sh --
#!/bin/sh
#
# /usr/share/e2fsprogs/initrd.ext3-add-journal
#
cd /
mount -nt proc proc proc
rootdev=$(cat proc/sys/kernel/real-root-dev)
cmdline=$(cat /proc/cmdline)
umount -n proc
if [ $rootdev != 256 ]; then
mount -nt tmpfs tmpfs /dev2
get_device
roottype=`/bin/e2initrd_helper -r /dev2/root2`
if test -n $roottype ; then
mount -nt tmpfs tmpfs /etc
echo /etc/fstab
echo /etc/mtab
if test $roottype = ext3 ; then
/sbin/tune2fs -O has_journal /dev2/root2 /dev/null 21
else
/sbin/tune2fs -O ^has_journal /dev2/root2 /dev/null 21
fi
umount -n /etc
fi
umount -n /dev2
umount -n /proc /dev/null 21
fi
---
This script is generated when your run mkinitrd image.
Right. I'm assuming that mkinitrd gets run during the kernel-image .deb
install, since it clearly contains local information.
...Also, almost
eveything on the longer list seems bogus - though harmless.
Yes, there is a ton of crap there, though I notice that it correctly
identified that I need the pwc driver for my webcam. However, it then
seems to have decided that I may need the webcam during the boot, in
case I can't wait to chat until / is mounted
...So the
problem would seem to be mkinitrd, which is hardly a surprise - we know
that code is problematic and we are working on replacing it for etch.
It wouldn't be the first time I had trouble with automatic module
detection. When I installed that Gentoo system I mentioned the live CD
initrd found my firewire chipset and my PCI ethernet card and decided to
install drivers for ethernet-over-firewire. I am still surprised I
eventually figured out how to get the network up.
Knoppix always works, I don't know how it does it.
Actually, just changing MODULES from most to dep might work.
Sadly, no. I ran it as-is with MODULES=most and then with MODULES=dep,
both fail the same way. Doing a diff on the initrd filesystems they
create suggests that MODULES doesn't affect the contents of loadmodules
(mostly--using 'dep' actually added the loop driver to the list, but it
may have noticed that I had it loaded because the initrd from the 'most'
run was mounted on the loopback device already--is it smart enough to do
that?), but only which modules are actually present in the initrd for
loading. When I diffed them the 'dep' version had many fewer actual .ko
objects present, but the same (almost, as I said) loadmodules script.
Would I be correct in guessing that there was a revision to the mkinitrd
script in the last couple of months? That would not only explain why
the 2.6.8-1 kernel works but also some odd problems I saw when I went to
learn a little bit about make-kpkg the Debian way of building kernels.
2. Mount the image, copy it to a fresh directory,
trim down loadmodules, and make a fresh initrd image
using mkcramfs.
This was my first thought too. I created a series of test images using
the /scripts/ext3-add-journal.sh script from both kernel packages and with
different loadmodules scripts: the 2.6.8-2 version, the same script with
siimage removed, the 2.6.8-1 version, and the 2.6.8-2 version with the usb
audio and non-SATA SCSI stuff removed as well. No joy. All fail in the
same way (except for the messages after the kernel panic, but that's just
because it continues to load
Bug#319979: proc_usb_info.txt.gz: added blank lines to reflect current format
On Thu, Jul 28, 2005 at 03:05:25AM +0800, Dan Jacobson wrote: Well all I know is tell upstream that 2.6 proc_usb_info.txt needs those blank lines if they aren't there already... as I am unfamiliar with upstream. I took a closer look at your patch, and to be honest, other than the last three fragments that add a blank line between E:... and T:... I can't see what it does, other than perhaps adding some extra whitepace, that seems spurious. I personally don't think the spaces between the E:... and T:... lines are neccessary, its just the dump of a log, but I can see why you would want them. I have attached the latest version of this file from upstream to this mail for reference. If you want to submit you change upstream, please read this http://linux.yyz.us/patch-format.html Sorry its a bit long winded, but its probably easier for me to just give you the link than try and explain it. I'd send it to linux-usb-devel@lists.sourceforge.net and CC Andrew Morton [EMAIL PROTECTED] If you are not comfortable with this, please make a unified diff of your change (diff -u), follow the instructions in step 5. Sign your work, and send it here, I will be happy to forward it on. However, I can't in any way gaurantee success. H If it is in 2.6.12 then it is already in unstable. Say, on sid all I see is 11 being the highest. Not that I can download any of them on my modem. 12 has recently been added. ftp://ftp.debian.org/debian/pool/main/l/linux-2.6/ I agree that downloading that behemouth is a bit of an ask. -- Horms /proc/bus/usb filesystem output === (version 2003.05.30) The usbfs filesystem for USB devices is traditionally mounted at /proc/bus/usb. It provides the /proc/bus/usb/devices file, as well as the /proc/bus/usb/BBB/DDD files. **NOTE**: If /proc/bus/usb appears empty, and a host controller driver has been linked, then you need to mount the filesystem. Issue the command (as root): mount -t usbfs none /proc/bus/usb An alternative and more permanent method would be to add none /proc/bus/usb usbfs defaults 0 0 to /etc/fstab. This will mount usbfs at each reboot. You can then issue `cat /proc/bus/usb/devices` to extract USB device information, and user mode drivers can use usbfs to interact with USB devices. There are a number of mount options supported by usbfs. Consult the source code (linux/drivers/usb/core/inode.c) for information about those options. **NOTE**: The filesystem has been renamed from usbdevfs to usbfs, to reduce confusion with devfs. You may still see references to the older usbdevfs name. For more information on mounting the usbfs file system, see the USB Device Filesystem section of the USB Guide. The latest copy of the USB Guide can be found at http://www.linux-usb.org/ THE /proc/bus/usb/BBB/DDD FILES: Each connected USB device has one file. The BBB indicates the bus number. The DDD indicates the device address on that bus. Both of these numbers are assigned sequentially, and can be reused, so you can't rely on them for stable access to devices. For example, it's relatively common for devices to re-enumerate while they are still connected (perhaps someone jostled their power supply, hub, or USB cable), so a device might be 002/027 when you first connect it and 002/048 sometime later. These files can be read as binary data. The binary data consists of first the device descriptor, then the descriptors for each configuration of the device. That information is also shown in text form by the /proc/bus/usb/devices file, described later. These files may also be used to write user-level drivers for the USB devices. You would open the /proc/bus/usb/BBB/DDD file read/write, read its descriptors to make sure it's the device you expect, and then bind to an interface (or perhaps several) using an ioctl call. You would issue more ioctls to the device to communicate to it using control, bulk, or other kinds of USB transfers. The IOCTLs are listed in the linux/usbdevice_fs.h file, and at this writing the source code (linux/drivers/usb/devio.c) is the primary reference for how to access devices through those files. Note that since by default these BBB/DDD files are writable only by root, only root can write such user mode drivers. You can selectively grant read/write permissions to other users by using chmod. Also, usbfs mount options such as devmode=0666 may be helpful. THE /proc/bus/usb/devices FILE: --- In /proc/bus/usb/devices, each device's output has multiple lines of ASCII output. I made it ASCII instead of binary on purpose, so that someone can obtain some useful data from it without the use of an auxiliary program. However, with an auxiliary program, the numbers in the first 4 columns of each T: line (topology info: Lev,
Bug#320312: Taking LVM snapshots can lead to an unuseable system
Package: kernel-image-2.6.8-2-686 Version: 2.6.8-16 Severity: critical In sarge I was unable to take any lvm snapshots until I manually loaded the dm-snapshot kernel module with modprobe. I took a snapshot of my /usr filesystem, but didn't remove the snapshot with lvremove before rebooting. After reboot, not only is the snapshot unavailable, but also the original filesystem. This makes the system unusable until the snapshot can be removed. If I boot kernel-image-2.4.27-2-686, (which fortunately I also had installed), I don't need to manually load dm-snapshot. Perhaps this is an lvm bug instead? http://www.redhat.com/archives/dm-devel/2004-August/msg00015.html Many thanks, Alex
Re: 2.6.12 upload
On Tue, Jul 26, 2005 at 03:26:04PM +0200, Goswin von Brederlow wrote: The problem is that the DAK will update linux-2.6, kernel-tree-x.y.z-n and kernel-image packages without any regards to linux-kernel-di. They will become out of sync and end up without source - GPL violation. Last I checked, dak was being reeducated so that it could be told about udebs it needed to keep around due to them being in initrd builds. The same approach could be used fairly easily to keep kernel source around until the corresponding udebs have been rebuilt. The main problem with moving udebs into the kernel build process, I think, is that the installer team needs to be able to change their structure relatively frequently; for example, the exact balance of modules in various udebs affects whether it's possible to build installer floppies and other media with space restrictions. Historically, having the udebs be controlled by the d-i team made sense. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 upload
On Thu, Jul 28, 2005 at 04:49:01PM +0900, Horms wrote: I tend to aggree, though I believe Franz Pop, or perhaps some of the other d-i team members have reason for keeping these images separate. Perhaps they could reiterate them here. Mostly two reasons: - Changes in the d-i packages don't trigger a complete rebuild. - There are more then 200 different binary packages. Bastian -- Insufficient facts always invite danger. -- Spock, Space Seed, stardate 3141.9 signature.asc Description: Digital signature
Bug#320091: kernel-image-2.6.8-2-386: Boot fails with a syntax error in /scripts/ext3-add-journal.sh
More info. I have a couple of other kernels that I tend to forget because they break my sound config. One is a custom build with IDE DMA and realtime-lsm support, and more interestingly the other is a stock Debian 2.6.8-2-k7. I realized sometime in the middle of the night that looking at the loadmodules list for this broken kernel has told me how to fix the audio problems in the other kernels, so they can now be regarded as working as well as 2.6.8-1-386 does. In any case they boot. 2.6.8-2-k7 has the same ext3-add-journal script as 2.6.8-2-386 and it works, so that script doesn't seem like a good candidate for the problem. Similarly, the way I fixed the audio problems was to copy over the short loadmodules list from 2.6.8-1-386. Since they all boot with it and 2.6.8-2-386 doesn't, I doubt playing with the modules will fix it either. That frankly runs me about out of ideas, so I hope it suggests some further options to you. I would rather not just say fine, run 2.6.8-2-k7 then because while I was building the custom kernel I had a lot of trouble with builds that had the same problem 2.6.8-2-386 does, so I fear there is a problem that I don't understand and that will pop up again and prevent me from doing security upgrades sometime in the future. Dustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#319546: isl3890 firmware upload fails when udev 0.063-1 is installed
reassign 319546 kernel-image-2.6.12-i386 thanks On Jul 23, Paolo Alexis Falcone [EMAIL PROTECTED] wrote: Using the stock Debian 2.6.12-1-686-smp kernel, the upload firmware sequence for the isl3890 (as used by the prism54 module) fails when udev 0.063-1 is installed. The firmware loads normally without the udev package installed. This also does not happen with older versions of the kernel with udev. Looks like this is a kernel bug, the firmware loader is sensitive to timing. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
linux-kernel-di udebs [Was: Re: 2.6.12 upload]
Bastian Blank [EMAIL PROTECTED] writes: On Thu, Jul 28, 2005 at 04:49:01PM +0900, Horms wrote: I tend to aggree, though I believe Franz Pop, or perhaps some of the other d-i team members have reason for keeping these images separate. Perhaps they could reiterate them here. Mostly two reasons: - Changes in the d-i packages don't trigger a complete rebuild. - There are more then 200 different binary packages. Bastian At the start changes have been common and modules have been added or removed or packages been split or joined. But hasn't that settled down now? Aren't the linux-kernel-di udebs consistent enough to be handled by kernel-source uploads? I've CCed debian-boot to get a broader opinion. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#320053: kernel-image-2.6.8-2-686: Installing it with sarge leads to failing at booting next time
owner 320053 ! thanks On Thursday 28 July 2005 08:48, Horms wrote: i don't see why this bug is related to me... another developer just mailed me and showed me this bugreport: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298623 and this is exactly my problem g Yes, I think you are correct, I have merged these bugs accordingly. Thanks for that. FYI, I plan to work with the submitter in an attempt to isolate this issue, check if a fix is available in 2.6.12 or from ALSA CVS or else report the bug there and track it. Cheers, FJP pgpBngTNKak4w.pgp Description: PGP signature
Processed: Re: Bug#320053: kernel-image-2.6.8-2-686: Installing it with sarge leads to failing at booting next time
Processing commands for [EMAIL PROTECTED]: owner 320053 ! Bug#320053: kernel-image-2.6.8-2-686: Installing it with sarge leads to failing at booting next time Bug#287411: 2.4/2.6 kernel oops on load of i810_audio in hp pavilion ze4900 laptop Bug#298623: kernel oops on load of i810_audio in gateway 7320GZ laptop Owner recorded as Frans Pop [EMAIL PROTECTED]. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: system noise when using ACPI module processor
Processing commands for [EMAIL PROTECTED]: clone 284213 -1 Bug#284213: system noise when using ACPI module processor Bug 284213 cloned as bug 320366. reassign -1 kernel-source-2.6.11 Bug#320366: system noise when using ACPI module processor Bug reassigned from package `kernel-source-2.6.8' to `kernel-source-2.6.11'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309964: drive appears confused (ireason = 0x01) and linux hangs
Maximilian Attems wrote: the kernelversion of the dmesg you posted and the initial bugreport are different. the dmesg seems to be selfcompiled. Oh that can be but it's the same problem with a selfcompiled kernel and a debian kernel. did you try latest 2.6.12 from unstable? did it help? yes I did a try but there are the same problems. I'm also testing the current development git-kernel snapshots with still no change. Follow this thread I've started on the kernel-dev list: http://article.gmane.org/gmane.linux.kernel/303955 There seems to be a problem with wrong irq bindings for some boards with newer kernels. http://article.gmane.org/gmane.linux.kernel/317636 Regards, Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309961: irq 18: nobody cared!
Maximilian Attems wrote: as this seems the same machine concerned by another bug. did you try newer 2.6.12 from unstable? yes, no change and same problems. I'm also testing the current development git-kernel snapshots with still no change. Follow this thread I've started on the kernel-dev list: http://article.gmane.org/gmane.linux.kernel/303955 There seems to be a problem with wrong irq bindings for some boards with newer kernels. http://article.gmane.org/gmane.linux.kernel/317636 are you overclocking? no try to boot with the noacpi or noapic kernel parameter. no change. See the thread above - I tested some kernel parameters and added the complete syslog. Regards, Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320379: Errors during initrd loading when / is on LVM over RAID
Package: kernel
Tags: patch
After switching from a 2.4.27 to 2.6.8 kernel for an old desktop Iuse as
a server, I noticed the following messages on console and kern.log.
Note: the errors are not harmful, just ugly; the system boots normally.
kernel: Inspecting /boot/System.map-2.6.8-2-686
kernel: Loaded 27390 symbols from /boot/System.map-2.6.8-2-686.
kernel: Symbols match kernel version 2.6.8.
kernel: No module symbols loaded - kernel modules not enabled.
kernel: ould not append to parent for /disc
kernel: devfs_mk_dir: invalid argument.4devfs_mk_dev: could not append to
parent for /disc
last message repeated 151 times
Cleaned for a missing \n in a printk and with added debug printk's in
fs/devfs/base.c, this looks like:
kernel: devfs_mk_dir: invalid argument, buf: .
kernel: _devfs_append_entry: -EEXIST for :disc
kernel: devfs_mk_dev: could not append to parent for /disc
(repeated)
The last error is a consequence of the error in devfs_mk_dir, so can
be ignored. The basic problem is that buf is empty.
Tracing back I ended up in fs/partitions/check.c, which has the following code
in function register_disk:
/* No minors to use for partitions */
if (disk-minors == 1) {
if (disk-devfs_name[0] != '\0')
devfs_add_disk(disk);
return;
}
/* always add handle for the whole disk */
devfs_add_partitioned(disk);
This looks unlogical: why does the first statement check for empty
disk-devfs_name and is the second one called blindly?
Changing the last statement to:
if (disk-devfs_name[0] != '\0')
devfs_add_partitioned(disk);
else
printk(KERN_WARNING %s: No devfs_name for %s.\n,
__FUNCTION__, disk-disk_name);
resulted in the errors disappearing and the following log output:
kernel: register_disk: No devfs_name for md_d0.
kernel: register_disk: No devfs_name for md_d64.
kernel: register_disk: No devfs_name for md_d128.
kernel: register_disk: No devfs_name for md_d192.
kernel: register_disk: No devfs_name for md_d4.
kernel: register_disk: No devfs_name for md_d68.
kernel: register_disk: No devfs_name for md_d132.
kernel: register_disk: No devfs_name for md_d196.
(repeated to md_d255)
I've debugged using kernel version 2.6.8, but a check showed this code is
unchanged in 2.6.11 and 2.6.12.
Please review my reasoning. If I'm correct, the attached patch may fix
the errors (and fix the missing \n). If you think the patch is correct,
I would appreciate advice how best to get it upstream.
The other option would of course be that something is more fundamentally
broken and that disk-devfs_name should be filled in these cases, but
I doubt that.
Cheers,
FJP
--- fs/partitions/check.c.orig 2005-05-19 12:52:23.0 +0200
+++ fs/partitions/check.c 2005-07-29 00:36:04.523385998 +0200
@@ -348,7 +348,8 @@
}
/* always add handle for the whole disk */
- devfs_add_partitioned(disk);
+ if (disk-devfs_name[0] != '\0')
+ devfs_add_partitioned(disk);
/* No such device (e.g., media were just removed) */
if (!get_capacity(disk))
--- fs/devfs/base.c.orig 2005-07-29 00:32:03.329992027 +0200
+++ fs/devfs/base.c 2005-07-29 00:32:52.08934 +0200
@@ -1644,7 +1644,7 @@
va_start(args, fmt);
n = vsnprintf(buf, 64, fmt, args);
if (n = 64 || !buf[0]) {
- printk(KERN_WARNING %s: invalid argument., __FUNCTION__);
+ printk(KERN_WARNING %s: invalid argument.\n, __FUNCTION__);
return -EINVAL;
}
pgprwNCXbOLeJ.pgp
Description: PGP signature
