Bug#406166: linux-image-2.6.18-3-k7: Kernel BUG appeared in syslog [rt.ursine.ca #540]
Package: linux-image-2.6.18-3-k7 Version: 2.6.18-8 Severity: normal I received a rather severe looking kernel BUG in my syslog after playing UT2004. The gaming session ended around the time the BUG appeared in the syslog, with the game locking up completely, freezing in place. I was able to successfully restart X.org with A-C-Bksp without any apparent ill effects to the system. -- /var/log/syslog snippet Jan 8 22:13:33 ursine kernel: [ cut here ] Jan 8 22:13:33 ursine kernel: kernel BUG at mm/slab.c:595! Jan 8 22:13:33 ursine kernel: invalid opcode: [#1] Jan 8 22:13:33 ursine kernel: SMP Jan 8 22:13:33 ursine kernel: Modules linked in: nls_iso8859_1 nls_cp437 vfat fat visor usbserial usb_storage ppdev vmnet vmmon nvidia bnep rfcomm hidp l2cap bluetooth button ac battery ipv6 ext3 jbd mbcache dm_snapshot dm_mirror dm_mod softdog lp joydev snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul bt878 snd_emu10k1 snd_ac97_codec snd_ac97_bus snd_bt87x snd_util_mem snd_hwdep snd_pcm_oss snd_pcm snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq tuner tvaudio bttv video_buf firmware_class ir_common compat_ioctl32 i2c_algo_bit btcx_risc tveeprom snd_timer snd_seq_device snd emu10k1_gp videodev v4l1_compat v4l2_common snd_page_alloc soundcore gameport parport_pc parport rtc psmouse serio_raw shpchp pci_hotplug pcspkr i2c_nforce2 i2c_core nvidia_agp agpgart sbp2 evdev tsdev eth1394 jfs 8139too sd_mod ide_cd cdrom usbhid sata_nv libata scsi_mod ohci1394 ieee1394 via_velocity crc_ccitt 8139cp mii ehci_hcd generic ohci_hcd amd74xx ide_core usbcore therma Jan 8 22:13:33 ursine kernel: processor fan Jan 8 22:13:33 ursine kernel: CPU: 0 Jan 8 22:13:33 ursine kernel: EIP: 0060:[kmem_cache_free+41/109] Tainted: P VLI Jan 8 22:13:33 ursine kernel: EFLAGS: 00210202 (2.6.18-3-k7 #1) Jan 8 22:13:33 ursine kernel: EIP is at kmem_cache_free+0x29/0x6d Jan 8 22:13:33 ursine kernel: eax: 802c ebx: 0020 ecx: c28df1c0 edx: c164a8a0 Jan 8 22:13:33 ursine kernel: esi: f25457a0 edi: f25457a0 ebp: dcd47e00 esp: ee11ddec Jan 8 22:13:33 ursine kernel: ds: 007b es: 007b ss: 0068 Jan 8 22:13:33 ursine kernel: Process ut2004-bin (pid: 26609, ti=ee11c000 task=e98b7000 task.ti=ee11c000) Jan 8 22:13:33 ursine kernel: Stack: 0020 f25457a0 dcd47e60 c0278d9e ee11deb4 f37a1520 0120 Jan 8 22:13:33 ursine kernel: 0001 0001 ffa1 ee11de94 0f9c Jan 8 22:13:33 ursine kernel: 0001 c016aaa3 Jan 8 22:13:33 ursine kernel: Call Trace: Jan 8 22:13:33 ursine kernel: [unix_stream_recvmsg+829/1186] unix_stream_recvmsg+0x33d/0x4a2 Jan 8 22:13:33 ursine kernel: [core_sys_select+405/679] core_sys_select+0x195/0x2a7 Jan 8 22:13:33 ursine kernel: [do_sock_read+174/183] do_sock_read+0xae/0xb7 Jan 8 22:13:33 ursine kernel: [sock_aio_read+83/97] sock_aio_read+0x53/0x61 Jan 8 22:13:33 ursine kernel: [dma_pool_free+119/277] dma_pool_free+0x77/0x115 Jan 8 22:13:33 ursine kernel: [do_sync_read+182/241] do_sync_read+0xb6/0xf1 Jan 8 22:13:33 ursine kernel: [hrtimer_try_to_cancel+60/66] hrtimer_try_to_cancel+0x3c/0x42 Jan 8 22:13:33 ursine kernel: [autoremove_wake_function+0/45] autoremove_wake_function+0x0/0x2d Jan 8 22:13:33 ursine kernel: [sock_ioctl+401/435] sock_ioctl+0x191/0x1b3 Jan 8 22:13:33 ursine kernel: [sock_ioctl+0/435] sock_ioctl+0x0/0x1b3 Jan 8 22:13:33 ursine kernel: [do_ioctl+28/93] do_ioctl+0x1c/0x5d Jan 8 22:13:33 ursine kernel: [vfs_read+176/321] vfs_read+0xb0/0x141 Jan 8 22:13:33 ursine kernel: [sys_read+60/99] sys_read+0x3c/0x63 Jan 8 22:13:33 ursine kernel: [sysenter_past_esp+86/121] sysenter_past_esp+0x56/0x79 Jan 8 22:13:33 ursine kernel: Code: ff ff 57 89 d7 8d 92 00 00 00 40 89 c1 c1 ea 0c 56 c1 e2 05 03 15 90 53 37 c0 53 8b 02 f6 c4 40 74 03 8b 52 0c 8b 02 84 c0 78 08 0f 0b 53 02 76 ef 29 c0 39 4a 18 74 08 0f 0b 6a 0d 76 ef 29 c0 Jan 8 22:13:33 ursine kernel: EIP: [kmem_cache_free+41/109] kmem_cache_free+0x29/0x6d SS:ESP 0068:ee11ddec -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (1000, 'unstable'), (999, 'experimental'), (500, 'testing'), (400, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-k7 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages linux-image-2.6.18-3-k7 depends on: ii coreutils 5.97-5.2 The GNU core utilities ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii initramfs-tools [linux-initra 0.85e tools for generating an initramfs ii module-init-tools 3.3-pre4-1 tools for managing Linux kernel mo ii yaird [linux-initramfs-tool] 0.0.12-18 Yet Another mkInitRD Versions of packages linux-image-2.6.18-3-k7 recommends: ii libc6-i686 2.3.6.ds1-9 GNU C Library: Shared libraries [i -- debconf information:
Re: Compiling User-Mode-Linux kernel
On Mon, January 8, 2007 11:03 pm, Gordon Haverland said: On Monday 08 January 2007 14:07, Mattia Dongili wrote: On Mon, Jan 08, 2007 at 12:43:00PM -0700, Gordon Haverland wrote: [...] probably you missed `make clean mrproper` before building UML. I've tried: make-kpkg clean make clean make mrproper make clean mrproper and all continue to die in exactly the same place. Different version of gcc being used? well, this can't cause a file not found error :) Anyway I'm using etch's default 4.1 CC arch/um/os-Linux/skas/process.o arch/um/os-Linux/skas/process.c: In function 'copy_context_skas0': arch/um/os-Linux/skas/process.c:328: error: 'PAGE_SHIFT' undeclared (first use in this function) ... DOH! oh, now I remember :) we have a fix in the user-mode-linux package see here: http://svn.debian.org/wsvn/pkg-uml/trunk/src/user-mode-linux/de bian/patches/?rev=0sc=0 I'll continue to plug away at this (waiting for drywall compound to dry) for a while, but if someone has a pointer, I would be glad to see it. :-) you may also want to try build the user-mode-linux from source by yourself, eg: apt-get source user-mode-linux cd user-mode-*; dpkg-buildpackage -uc -us -b -rfakeroot I think I'll download this and try it. But I would imagine I first need to compile the UML kernel? Oh well, lots of fun. :-) No, this is taken care by the package itself, IOW the user-mode-linux debian's package contains the UML kernel. BTW: we have a dedicated list ([EMAIL PROTECTED]) if you need help -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#406166: linux-image-2.6.18-3-k7: Kernel BUG appeared in syslog [rt.ursine.ca #540]
Processing commands for [EMAIL PROTECTED]: tags 406166 moreinfo Bug#406166: linux-image-2.6.18-3-k7: Kernel BUG appeared in syslog [rt.ursine.ca #540] There were no tags set. Tags added: moreinfo 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#406166: linux-image-2.6.18-3-k7: Kernel BUG appeared in syslog [rt.ursine.ca #540]
tags 406166 moreinfo thanks On Tue, Jan 09, 2007 at 12:10:45AM -0800, Paul Johnson wrote: I received a rather severe looking kernel BUG in my syslog after playing UT2004. The gaming session ended around the time the BUG appeared in the syslog, with the game locking up completely, freezing in place. I was able to successfully restart X.org with A-C-Bksp without any apparent ill effects to the system. The kernel is tainted. You have to reproduce this without proprietary modules. Bastian -- There are certain things men must do to remain men. -- Kirk, The Ultimate Computer, stardate 4929.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406181: linux-2.6: RAID1 repair is broken
Package: linux-2.6 Version: 2.6.18-8 Severity: normal This is a followup to an issue initially reported to the mdadm package as bug 405919. As there is really a separate kernel issue, Martin asked me to file a separate bug. The RAID1 repair process is currently a no-op. The upstream maintainer for the kernel MD driver sent a patch which worked for me: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405919;msg=17 Regarding the other kernel issue I had reported under bug 405919 (inverted cmd_match(page, repair) condition), note that it's already fixed in debian's kernel version. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.36 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6 build problems due to kernel-package
On Mon, 8 Jan 2007 22:38:46 +0100, Frederik Schueler [EMAIL PROTECTED] said: Hello, Looking at what happened to the last 2.6.20rc4 snapshots - build logs are here: http://stats.buildserver.net/build.php?arch=pkg=linux-2.6 I suggest we get rid of kernel-package in the linux-2.6 build process ASAP, because it keeps breaking linux-2.6 builds on most if not every upstream release(-candidate). If it is indeed kernel-package that is breaking at every upstream release, can you mention the bug numbers associated with the breakages? It is not at all apparent to me that kernel-package is as buggy as it would appear from the tone above. For example, what is the current problem with k-p, in your view? manoj -- When the game-master smiles, it's already too late. Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6 build problems due to kernel-package
On Mon, 8 Jan 2007 22:38:46 +0100, Frederik Schueler [EMAIL PROTECTED] said: Hello, Looking at what happened to the last 2.6.20rc4 snapshots - build logs are here: http://stats.buildserver.net/build.php?arch=pkg=linux-2.6 I suggest we get rid of kernel-package in the linux-2.6 build process ASAP, because it keeps breaking linux-2.6 builds on most if not every upstream release(-candidate). Heh. This is typical of the usual k-p bashing. The build logs for i386 show that the error occurred here: , | dh_installdirs 'boot' | /usr/bin/make -f debian/rules.real \ | install-image-i386-none-486-plain_image \ | DIR='debian/build/build-i386-none-486' | INSTALL_DIR='/build/buildd/17438-0/linux-2.6-2.6.20~rc4/debian/linux-image-2.6.20-rc4-486/boot' | REAL_VERSION='2.6.20-rc4-486' | ... | cd debian/build/build-i386-none-486; env -u ABINAME -u ARCH -u SUBARCH -u FLAVOUR -u VERSION -u LOCALVERSION -u MAKEFLAGS make modules_install INSTALL_MOD_PATH=/build/buildd/17438-0/linux-2.6-2.6.20~rc4/debian/linux-image-2.6.20-rc4-486 | | ... ` Which is not k-p code, but seems like linux-2.6 code. But, of course, k-p is to blame, and must be removed from the build process. Why do I even bother? manoj -- Let every man teach his son, teach his daughter, that labor is honorable. Robert G. Ingersoll Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6 build problems due to kernel-package
On Mon, Jan 08, 2007 at 10:38:46PM +0100, Frederik Schueler wrote: Looking at what happened to the last 2.6.20rc4 snapshots - build logs are here: I found the source of the problem. Our own code fails with: | rm: cannot remove `/build/buildd/17438-0/linux-2.6-2.6.20~rc4/debian/linux-image-2.6.20-rc4-486/lib/modules/2.6.20-rc4-486/build': No such file or directory It tries to remove something which should be there always. Some lines up, the kernel supplied makefiles executes depmod. | if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map -b /build/buildd/17438-0/linux-2.6-2.6.20~rc4/debian/linux-image-2.6.20-rc4-486 -r 2.6.20-rc4; fi But the used release info is wrong. Now it is clear that it uses the wrong info through the whole build. linux-2.6 uses a localversion file to append the flavour informations to the upstream version. There is a comment in the code which says | # skip backup files (containing '~') and our version contains one, so it just ignores anything. Bastian -- Where there's no emotion, there's no motive for violence. -- Spock, Dagger of the Mind, stardate 2715.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
loadkeys in early userspace (using initramfs-tools)
Hi,
Just like cryptsetup the uswsusp package needs to interact with the
user via the keyboard in early userspace. For people with non-us
keyboards that can be problematic because loadkeys hasn't run yet.
I found out that cryptsetup already solved the problem in its
initramfs-{hook,script}. To not duplicate your work wouldn't it be
better to split that functionality of and put it in the initramfs-tools
package?
What do you think?
grts Tim
For reference, the code I'm referring to follows,
[ In hooks/cryptroot
]===
prepare_keymap() {
local env charmap
# Allow the correct keymap to be loaded if possible
if [ ! -x /bin/loadkeys ] || [ ! -r /etc/console/boottime.kmap.gz ];
then
return 1
fi
copy_exec /bin/loadkeys /bin/
cp /etc/console/boottime.kmap.gz $DESTDIR/etc/
# Check for UTF8 console
if [ ! -x /usr/bin/kbd_mode ]; then
return 0
fi
if [ -r /etc/environment ]; then
env=/etc/environment
elif [ -r /etc/default/locale ]; then
env=/etc/default/locale
else
return 0
fi
for var in LANG LC_ALL LC_CTYPE; do
value=$(egrep ^[^#]*${var}= $env | tail -n1 | cut -d= -f2)
eval $var=$value
done
charmap=$(LANG=$LANG LC_ALL=$LC_ALL LC_CTYPE=$LC_CTYPE locale charmap)
if [ $charmap = UTF-8 ]; then
copy_exec /usr/bin/kbd_mode /bin/
fi
return 0
}
[ In scripts/local-top/cryptroot
]
load_keymap()
{
local opts
opts=-q
# Should terminal be in UTF8 mode?
if [ -x /bin/kbd_mode ]; then
/bin/kbd_mode -u
opts=$opts -u
fi
# Load custom keymap
if [ -x /bin/loadkeys -a -r /etc/boottime.kmap.gz ]; then
loadkeys $opts /etc/boottime.kmap.gz
fi
}
signature.asc
Description: PGP signature
Bug#404794: linux-image-2.6.18-3-686: Pb while trying ioctl on /dev/net/tun (module tun)
Same problem here with linux-image-2.6.18-3-amd64: [EMAIL PROTECTED]:~$ uname -a Linux marcopolo 2.6.18-3-amd64 #1 SMP Mon Dec 4 17:04:37 CET 2006 x86_64 GNU/Linux
Re: loadkeys in early userspace (using initramfs-tools)
Tim Dijkstra [EMAIL PROTECTED] writes:
Hi,
Just like cryptsetup the uswsusp package needs to interact with the
user via the keyboard in early userspace. For people with non-us
keyboards that can be problematic because loadkeys hasn't run yet.
I found out that cryptsetup already solved the problem in its
initramfs-{hook,script}. To not duplicate your work wouldn't it be
better to split that functionality of and put it in the initramfs-tools
package?
What do you think?
I do like this proposal and the change looks simple enough to try to
be pushed on Etch. Do you see any problem with that Max?
--
O T A V I OS A L V A D O R
-
E-mail: [EMAIL PROTECTED] UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://otavio.ossystems.com.br
-
Microsoft sells you Windows ... Linux gives
you the whole house.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-cryptsetup-devel] loadkeys in early userspace (using initramfs-tools)
On Tue, January 9, 2007 15:20, Tim Dijkstra said:
Just like cryptsetup the uswsusp package needs to interact with the
user via the keyboard in early userspace.
...
I found out that cryptsetup already solved the problem in its
initramfs-{hook,script}. To not duplicate your work wouldn't it be
better to split that functionality of and put it in the initramfs-tools
package?
What do you think?
I discussed adding loadkeys to initramfs-tools earlier and the
initramfs-tools maintainer disagreed (which is why I implemented it
directly in cryptsetup).
I'm not opposed to a shared solution at all, but I suggest you check with
the initramfs-tools maintainer (see bugs 337663 and 376393 for reference).
Perhaps he is of another opinion now that at least two different initramfs
users need the keymap.
One solution would be to change initramfs-tools to allow other
initramfs-using packages to specify that they need a localized keymap so
that it can be conditionally included in the initramfs image.
This could be done e.g. by including a per-package file such as
/usr/share/initramfs-tools/conf.d/{cryptsetup,uswsusp} which contains the
line KEYMAP=y (this would also be flexible enough to allow other
customizations in the future).
This would also allow users to specify that they want the keymap to be
included even if there is no package which needs it (by creating such a
file themselves).
--
David Härdeman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 404447
Processing commands for [EMAIL PROTECTED]: tags 404447 + pending Bug#404447: ixp4xx: open source network driver behavingly badly under load, can cause corruption There were no tags set. Tags added: pending End of message, 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: [Pkg-cryptsetup-devel] loadkeys in early userspace (using initramfs-tools)
David Härdeman [EMAIL PROTECTED] writes: What do you think? ... One solution would be to change initramfs-tools to allow other initramfs-using packages to specify that they need a localized keymap so that it can be conditionally included in the initramfs image. Another possible solution might add one initramfs-plugin-loadkeys package and then both depending of it. That would allow us to provide plugins for initramfs-tools and share code between all programs using same feature. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house.
Re: [Pkg-cryptsetup-devel] loadkeys in early userspace (using initramfs-tools)
heya David,
On Tue, Jan 09, 2007 at 04:30:45PM +0100, David Härdeman wrote:
On Tue, January 9, 2007 15:20, Tim Dijkstra said:
snipp
I discussed adding loadkeys to initramfs-tools earlier and the
initramfs-tools maintainer disagreed (which is why I implemented it
directly in cryptsetup).
I'm not opposed to a shared solution at all, but I suggest you check with
the initramfs-tools maintainer (see bugs 337663 and 376393 for reference).
Perhaps he is of another opinion now that at least two different initramfs
users need the keymap.
yup.
One solution would be to change initramfs-tools to allow other
initramfs-using packages to specify that they need a localized keymap so
that it can be conditionally included in the initramfs image.
This could be done e.g. by including a per-package file such as
/usr/share/initramfs-tools/conf.d/{cryptsetup,uswsusp} which contains the
line KEYMAP=y (this would also be flexible enough to allow other
customizations in the future).
agreed, the default beeing KEYMAP=n.
This would also allow users to specify that they want the keymap to be
included even if there is no package which needs it (by creating such a
file themselves).
or just setting it in /etc/initramfs-tools/conf.d/keymap or in
/etc/initramfs-tools/initramfs.conf.
this code is good tested by uswsusp, but it's a feature enhancement.
i'll queue it up for the post-etch queue.
best regards
--
maks
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406166: linux-image-2.6.18-3-k7: Kernel BUG appeared in syslog [rt.ursine.ca #540]
On Tuesday 09 January 2007 01:04, Bastian Blank wrote: tags 406166 moreinfo thanks On Tue, Jan 09, 2007 at 12:10:45AM -0800, Paul Johnson wrote: I received a rather severe looking kernel BUG in my syslog after playing UT2004. The gaming session ended around the time the BUG appeared in the syslog, with the game locking up completely, freezing in place. I was able to successfully restart X.org with A-C-Bksp without any apparent ill effects to the system. The kernel is tainted. You have to reproduce this without proprietary modules. How? UT2004 depends on nvidia. -- Paul Johnson Email and IM (XMPP Google Talk): [EMAIL PROTECTED] pgpxmdomPMuq3.pgp Description: PGP signature
Bug#354231: marked as done (linux-image-2.6.15-1-k7: not working DMA and cpufreq on a HP ZV6100)
Your message dated Tue, 9 Jan 2007 17:27:14 +0100 with message-id [EMAIL PROTECTED] and subject line Bug#354231: linux-image-2.6.15-1-k7: not working DMA and cpufreq on a HP ZV6100 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) ---BeginMessage--- Package: linux-image-2.6.15-1-k7 Version: 2.6.15-4 Severity: important The problem affects also 2.6.15-1-486 and the 2.6.8-386 from sarge !!! if i try to set dma with hdparm -d1 it says: HDIO_SET_DMA failed: Operation not permitted even giving as boot options no success. the HW however is fine since using a live ubuntu with 2.6.12 i can issue the cmmand and it is recognized. I think the problem on cpufreq that says that there is not the device driver is a son of the same father. -- 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.15-1-k7 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages linux-image-2.6.15-1-k7 depends on: ii module-init-tools 3.2.2-2tools for managing Linux kernel mo ii yaird [linux-initramfs-tool] 0.0.12-3 Yet Another mkInitRD Versions of packages linux-image-2.6.15-1-k7 recommends: ii libc6-i6862.3.5-13 GNU C Library: Shared libraries [i -- debconf information: linux-image-2.6.15-1-k7/postinst/depmod-error-initrd-2.6.15-1-k7: false linux-image-2.6.15-1-k7/postinst/bootloader-error-2.6.15-1-k7: linux-image-2.6.15-1-k7/postinst/old-initrd-link-2.6.15-1-k7: true linux-image-2.6.15-1-k7/preinst/abort-install-2.6.15-1-k7: linux-image-2.6.15-1-k7/postinst/create-kimage-link-2.6.15-1-k7: true linux-image-2.6.15-1-k7/postinst/depmod-error-2.6.15-1-k7: false linux-image-2.6.15-1-k7/preinst/already-running-this-2.6.15-1-k7: linux-image-2.6.15-1-k7/preinst/initrd-2.6.15-1-k7: linux-image-2.6.15-1-k7/preinst/elilo-initrd-2.6.15-1-k7: true linux-image-2.6.15-1-k7/postinst/old-dir-initrd-link-2.6.15-1-k7: true linux-image-2.6.15-1-k7/postinst/bootloader-test-error-2.6.15-1-k7: linux-image-2.6.15-1-k7/preinst/abort-overwrite-2.6.15-1-k7: linux-image-2.6.15-1-k7/preinst/lilo-initrd-2.6.15-1-k7: true linux-image-2.6.15-1-k7/prerm/would-invalidate-boot-loader-2.6.15-1-k7: true linux-image-2.6.15-1-k7/postinst/kimage-is-a-directory: linux-image-2.6.15-1-k7/preinst/lilo-has-ramdisk: linux-image-2.6.15-1-k7/preinst/bootloader-initrd-2.6.15-1-k7: true linux-image-2.6.15-1-k7/preinst/failed-to-move-modules-2.6.15-1-k7: linux-image-2.6.15-1-k7/prerm/removing-running-kernel-2.6.15-1-k7: true linux-image-2.6.15-1-k7/preinst/overwriting-modules-2.6.15-1-k7: true linux-image-2.6.15-1-k7/postinst/old-system-map-link-2.6.15-1-k7: true ---End Message--- ---BeginMessage--- On Mon, Jan 08, 2007 at 05:36:00PM +0100, Leonardo Boselli wrote: I have tried: now the bug is no longer present (or, at least, i have not been able to notice it ...) -- Leonardo Boselli On Mon, 1 Jan 2007, maximilian attems wrote: can we have an update if that bug is still affecting linux image 2.6.18? thanks thanks for the feedback, closing. -- maks ---End Message---
Bug#337663: [Pkg-cryptsetup-devel] loadkeys in early userspace (using initramfs-tools)
On Tue, 9 Jan 2007 17:25:05 +0100
maximilian attems [EMAIL PROTECTED] wrote:
On Tue, Jan 09, 2007 at 04:30:45PM +0100, David Härdeman wrote:
One solution would be to change initramfs-tools to allow other
initramfs-using packages to specify that they need a localized keymap so
that it can be conditionally included in the initramfs image.
This could be done e.g. by including a per-package file such as
/usr/share/initramfs-tools/conf.d/{cryptsetup,uswsusp} which contains the
line KEYMAP=y (this would also be flexible enough to allow other
customizations in the future).
agreed, the default beeing KEYMAP=n.
This would also allow users to specify that they want the keymap to be
included even if there is no package which needs it (by creating such a
file themselves).
or just setting it in /etc/initramfs-tools/conf.d/keymap or in
/etc/initramfs-tools/initramfs.conf.
this code is good tested by uswsusp, but it's a feature enhancement.
i'll queue it up for the post-etch queue.
Tested by cryptroot. But anyway, good to hear your are going to add this.
I'm CC-ing the original bug as a reminder.
TIA,
Tim Dijkstra
signature.asc
Description: PGP signature
Re: Solving the linux-2.6 firmware issue
On Mon, Jan 08, 2007 at 07:49:19PM -0800, Jeff Carr wrote: I've not seen conclusive evidence that the keyspan firmware file is not the best effort of freeness. This firmware may not be modified and may only be used with Keyspan hardware. That cannot be considered a best effort of freeness. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Solving the linux-2.6 firmware issue
On 01/09/07 11:50, dann frazier wrote: On Mon, Jan 08, 2007 at 07:49:19PM -0800, Jeff Carr wrote: I've not seen conclusive evidence that the keyspan firmware file is not the best effort of freeness. This firmware may not be modified and may only be used with Keyspan hardware. That cannot be considered a best effort of freeness. Well, that's a nice sound byte, but I think it's not so easy. I hope you would agree that it's the best effort of the kernel developers! They are certainly working as hard as possible to support this hardware. Lets focus on keyspan. For one, it looks like Keyspan might have been (and might still be) trying to make progress. These firmware files are old. As the years went on, it seems like at some point someone (from within keyspan) figured out how to describe some of firmware functionality as code. So it looks like there was some forward progress. It's still likely that the raw hex values are generated by some hardware guys and there isn't any understanding of what they really mean -- or what they mean makes no sense or can't be described in C. This happens all the time. The hardware guys could have quit, been fired or died and the knowledge lost. What doesn't make sense to me is to throw out stuff like this because we don't have the code. Lots of other hardware like this has this same non-free stuff on chips inside of it that we can't see the binary. I don't see any way around problems like this. Do you have any suggestions here? The problems are very complicated to solve. What is best for the free software movement going forward in your opinion? Pragmatically, Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Solving the linux-2.6 firmware issue
On Tue, Jan 09, 2007 at 03:22:51PM -0800, Jeff Carr wrote: What is best for the free software movement going forward in your opinion? Discussing this, if you must discuss it at all, on a discussion list. That means -project or -kernel, but not -release, please. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Solving the linux-2.6 firmware issue
(Removing -release, as requested) On Tue, Jan 09, 2007 at 03:22:51PM -0800, Jeff Carr wrote: What doesn't make sense to me is to throw out stuff like this because we don't have the code. aiui, its being dropped out of main because it is not legal for us or our users to modify it in its current form - not because its current form is a hex blob. All of your arguments deal with the latter issue. I can't legally use this driver to drive my own non-keyspan device and I cannot make changes to the hex to fix a bug or add a feature for my Keyspan device. I'm not a lawyer, but its also questionable to me whether or not the license permits us to distribute it an the the non-free modules package. If you'd like to help improve the situation, I suggest lobbying Keyspan to license their blob under the GPL. You can add me to the list of customers unhappy with the situation - I own a USA-19QW. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scheduling linux-2.6 2.6.18-9
On Wed, Jan 03, 2007 at 08:32:36AM +0100, maximilian attems wrote: current open issues (please add if you know more): - bcm43xx ?backports? - hp amd64 acpi blacklists I don't see any follow-ups from anyone adding more. How about these two issues in particular -- is there any progress on them, or is any help needed? well as you probably know there are different wireless stacks around. bcm43xx main dev does not happen with the one that is currently used in the stock kernel so this is a bit of a red herring and afaik not resolved upstream until alternative stack is due to be merged.. according to sjoerd bcm43xx troubles happen lot less often. have checked latest git state and didn't see meaningfull patches that we miss, but i might be wrong and have no test box myself. I'm afraid this doesn't clear anything up for me at all. I don't know what bcm43xx main dev refers to. Is the summary basically that the only known fixes for the bcm43xx problems involve large changes to the wireless stack (obviously not something we want to try to backport)? the acpi blacklist is just a matter of doing it for my laptop seeing that acpi is disabled and then doing a similar patch for this kind of laptops. if someone wants to chimme in feel free. we have collected all the relevant dmidecode output. Ok, so it's just a matter of doing it :), has this been done now or shall I look into this? 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. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404823: boot log
hey Francesco, Can you provide a boot log, and note where the pauses occur? Its probably easiest to do this with a serial console. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402667: marked as done (linux-image-2.6.18-3-686: IBM ThinkPad X40 (APM) fails to power off on shutdown)
Your message dated Tue, 9 Jan 2007 16:38:31 -0700 with message-id [EMAIL PROTECTED] and subject line Bug#402667: close this bug 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) ---BeginMessage--- Package: linux-image-2.6.18-3-686 Version: 2.6.18-7 Severity: normal Hoping to fix some Xorg problems, I recently upgraded from a 2.6.15 kernel to the latest 2.6.18 kernel. Unfortunately, using the new kernel, my machine no longer powers off when executing shutdown -h now As shown in the attached output of dmesg, I added some apm stuff to the kernel command line: root=/dev/hda1 ro apm=on apm=power-off vga=792 cachesize=1024 acpi=off but this had no effect. Power off on shutdown worked fine on my 2.6.15 kernel. If you want, I can install 2.6.16 and 2.6.17 and tell you exactly where things went off the rails. Please let me know if there's any other information I can provide that would help diagnose the problem. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages linux-image-2.6.18-3-686 depends on: ii coreutils 5.97-5 The GNU core utilities ii debconf [debconf-2.0] 1.5.8 Debian configuration management sy ii initramfs-tools [linux-initra 0.85b tools for generating an initramfs ii module-init-tools 3.3-pre3-1 tools for managing Linux kernel mo Versions of packages linux-image-2.6.18-3-686 recommends: ii libc6-i686 2.3.6.ds1-8 GNU C Library: Shared libraries [i -- debconf information: linux-image-2.6.18-3-686/postinst/bootloader-error-2.6.18-3-686: linux-image-2.6.18-3-686/postinst/old-dir-initrd-link-2.6.18-3-686: true linux-image-2.6.18-3-686/postinst/kimage-is-a-directory: linux-image-2.6.18-3-686/postinst/old-system-map-link-2.6.18-3-686: true linux-image-2.6.18-3-686/postinst/create-kimage-link-2.6.18-3-686: true linux-image-2.6.18-3-686/postinst/bootloader-test-error-2.6.18-3-686: linux-image-2.6.18-3-686/preinst/abort-overwrite-2.6.18-3-686: linux-image-2.6.18-3-686/postinst/old-initrd-link-2.6.18-3-686: true shared/kernel-image/really-run-bootloader: true linux-image-2.6.18-3-686/preinst/elilo-initrd-2.6.18-3-686: true linux-image-2.6.18-3-686/preinst/lilo-initrd-2.6.18-3-686: true linux-image-2.6.18-3-686/postinst/depmod-error-initrd-2.6.18-3-686: false linux-image-2.6.18-3-686/preinst/bootloader-initrd-2.6.18-3-686: true linux-image-2.6.18-3-686/prerm/removing-running-kernel-2.6.18-3-686: true linux-image-2.6.18-3-686/prerm/would-invalidate-boot-loader-2.6.18-3-686: true linux-image-2.6.18-3-686/preinst/abort-install-2.6.18-3-686: linux-image-2.6.18-3-686/preinst/overwriting-modules-2.6.18-3-686: true linux-image-2.6.18-3-686/preinst/initrd-2.6.18-3-686: linux-image-2.6.18-3-686/preinst/lilo-has-ramdisk: linux-image-2.6.18-3-686/preinst/already-running-this-2.6.18-3-686: linux-image-2.6.18-3-686/postinst/depmod-error-2.6.18-3-686: false linux-image-2.6.18-3-686/preinst/failed-to-move-modules-2.6.18-3-686: Linux version 2.6.18-3-686 (Debian 2.6.18-7) ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)) #1 SMP Mon Dec 4 16:41:14 UTC 2006 BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 5f6e (usable) BIOS-e820: 5f6e - 5f6f7000 (ACPI data) BIOS-e820: 5f6f7000 - 5f6f9000 (ACPI NVS) BIOS-e820: 5f70 - 6000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ff80 - 0001 (reserved) 630MB HIGHMEM available. 896MB LOWMEM available. On node 0 totalpages: 390880 DMA zone: 4096 pages, LIFO batch:0 Normal zone: 225280 pages, LIFO batch:31 HighMem zone: 161504 pages, LIFO batch:31 DMI present. Allocating PCI resources starting at 7000 (gap: 6000:9ec0) Detected 1196.163 MHz processor. Built 1 zonelists. Total pages: 390880 Kernel command line: root=/dev/hda1 ro apm=on apm=power-off vga=792 cachesize=1024 acpi=off Found and enabled local APIC! mapped APIC to d000 (fee0) Enabling
Bug#405467: linux-image-2.6.18-3-amd64: uses 100% CPU time handling hardware interrupts from parallel port
On Thu, Jan 04, 2007 at 12:15:29PM +0100, Ludovic Brenta wrote: I am not a Linux kernel developer; I am a Debian developer. The purpose of this bug report is to document an issue (and its workaround) in Debian Etch. Even if the bug is fixed upstream, it is still present in Debian Etch at this time, and will affect other people for as long as the buggy kernel is in Debian Etch. hey Ludovic, I've been keeping a matrix of such things for ProLiant systems here: http://wiki.debian.org/HP/ProLiant What do you think about adding a HP/Laptops section for stuff like this? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387498: not reproducible on hppa either
I tried to reproduce on an hppa system running latest etch bits:
[EMAIL PROTECTED]:~$ uname -a
Linux hppa 2.6.18-3-parisc #1 Mon Dec 4 09:17:59 MST 2006 parisc
GNU/Linux
[EMAIL PROTECTED]:~$ cat t.c
int
main(int argc,char * argv[]) {return system(argv[1]);}
[EMAIL PROTECTED]:~$ cc -g t.c -o t
[EMAIL PROTECTED]:~$ ./t echo g
g
[EMAIL PROTECTED]:~$ echo $?
0
[EMAIL PROTECTED]:~$ cc -g -pg t.c -o t
[EMAIL PROTECTED]:~$ ./t echo g
g
I also cannot reproduce on a parisc64 system.
So, I'm gonna go ahead and close this bug. Please reopen if you are
still able to reproduce.
--
dann frazier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387498: marked as done ([hppa] system() hangs when compiled with -pg (gprof profiling))
Your message dated Tue, 9 Jan 2007 21:06:40 -0700
with message-id [EMAIL PROTECTED]
and subject line not reproducible on hppa either
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)
---BeginMessage---
Package: libc6
Version: 2.3.6-16
Severity: serious
Greetings!
Is there any quick workaround here -- this is holding up
gcl/maxima/acl2/axiom.
Take care,
=
[EMAIL PROTECTED]:~$ cat t.c
int
main(int argc,char * argv[]) {return system(argv[1]);}
[EMAIL PROTECTED]:~$ [EMAIL PROTECTED]:~$ cc -g t.c -o t
[EMAIL PROTECTED]:~$ ./t echo g
g
[EMAIL PROTECTED]:~$ echo $?
0
[EMAIL PROTECTED]:~$ cc -g -pg t.c -o t
[EMAIL PROTECTED]:~$ ./t echo g
[1]+ Stopped ./t echo g
[EMAIL PROTECTED]:~$ cat t.c
int
main(int argc,char * argv[]) {return system(argv[1]);}
[EMAIL PROTECTED]:~$ [EMAIL PROTECTED]:~$ cc -g t.c -o t
[EMAIL PROTECTED]:~$ ./t echo g
g
[EMAIL PROTECTED]:~$ echo $?
0
[EMAIL PROTECTED]:~$ cc -g -pg t.c -o t
[EMAIL PROTECTED]:~$ ./t echo g
[1]+ Stopped ./t echo g
--
Camm Maguire[EMAIL PROTECTED]
==
The earth is but one country, and mankind its citizens. -- Baha'u'llah
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.4.25
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages libc6 depends on:
ii tzdata2006g-2Time Zone and Daylight Saving Time
libc6 recommends no packages.
-- no debconf information
---End Message---
---BeginMessage---
I tried to reproduce on an hppa system running latest etch bits:
[EMAIL PROTECTED]:~$ uname -a
Linux hppa 2.6.18-3-parisc #1 Mon Dec 4 09:17:59 MST 2006 parisc
GNU/Linux
[EMAIL PROTECTED]:~$ cat t.c
int
main(int argc,char * argv[]) {return system(argv[1]);}
[EMAIL PROTECTED]:~$ cc -g t.c -o t
[EMAIL PROTECTED]:~$ ./t echo g
g
[EMAIL PROTECTED]:~$ echo $?
0
[EMAIL PROTECTED]:~$ cc -g -pg t.c -o t
[EMAIL PROTECTED]:~$ ./t echo g
g
I also cannot reproduce on a parisc64 system.
So, I'm gonna go ahead and close this bug. Please reopen if you are
still able to reproduce.
--
dann frazier
---End Message---
Re: How do I build a XEN kernel with make-kpkg
Rainer Koenig [EMAIL PROTECTED] writes: Ok. Next try. Finding some sort of HowTos on the net, one describing that I need the XEN source package that applies patches to the kernel and then compile it. Whatever I do with 2.6.18 the kernel build process exits with errors that show me that something is very wrong in the kernel source tree. So I'm stuck, but I wonder: There IS a package linux-image-2.6.18-3-xen-686 so it SHOULD be possible to build such an image. But HOW can I do that? Is there any sort of magic spell that I have to say before building it or am I just missing an important point? The debian patch package is incompatible to make-kpkg. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382699 I was sure I did send in the workaround for xen but can't see it in the BTS. So here we go again (CCing the bug). As a quick fix for xen do: mkdir /usr/src/kernel-patches/all/2.6.18/xen/ cat /usr/src/kernel-patches/all/2.6.18/apply/xen EOF #!/bin/sh echo Applying debian patch with xen parts if [ -z $KPKG_ARCH ]; then KPKG_ARCH=$(dpkg-architecture -qDEB_HOST_ARCH) fi /usr/src/kernel-patches/all/2.6.18/apply/debian --arch $KPKG_ARCH --subarch xen EOF cat /usr/src/kernel-patches/all/2.6.18/unpatch/xen EOF #!/bin/sh set -e upstream=2.6.18 exec /usr/src/kernel-patches/all/$upstream/apply/debian $upstream-0 EOF chmod a+x /usr/src/kernel-patches/all/2.6.18/apply/xen /usr/src/kernel-patches/all/2.6.18/unpatch/xen After that you can use make-kpkg --added-patches xen clean make-kpkg --added-patches xen kernel-image The same can be done for vserver and xen-vserver. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Old SPARC kernel bugs
On Mon, Jan 08, 2007 at 08:52:08PM +0100, Martin Michlmayr wrote: There are some very old bug reports regarding SPARC kernels. I don't know if it actually makes sense to look at them but can someone either do that or close them. If any of these still apply in 2.6, please reassign to linux-2.6 Thanks for the note, Martin. kernel-image-2.2.20-sun4cdm: 90549 90549: normal: SS2 Problem kernel-image-2.2.20-sun4dm-smp: 193613 193613: normal: kernel-image-2.2.20-sun4dm-smp_9_sparc.deb doesn't see both processors kernel-image-2.2.20-sun4u: 71436 71436: normal: kernel-image-2.2.17-sun4u: Kernel panic in headless systems This is against woody kernel, and woody has been removed from archive recently, so I guess it's safe to close them. kernel-image-2.4.19-sun4u: 178026 178026: normal: kernel-image-2.4.19-sun4u: rtc module not loaded, hwclock fails rtc module works fine in the latest kernels, so I'll close this one too. If anyone still experiences any problems, described in these bugs with etch/sid kernels, please file a new bug with detailed information on how to reproduce it. 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]
