Re: LI-2.6.15-1-686 Wont Boot After Modem Driver Inatall Attempts
Leonard Chatagnier wrote: Consider ths issue solved, but clarify your comment above about the patch available. Is it specifically a patch, a Linuxant updated driver or a new module package for Debian as I'm a little vague on this? Also is it available now or when if you know? I was talking about this: http://www.linuxant.com/drivers/hsf/downloads-patches.php However, that's for the HSF driver; I think you're using HCF. In any case, the correction will be included in the next version of both drivers, which are expected to be released very soon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
hey kernel
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349354: initramfs-tools - kernel -udev dependency loop
severity 349354 critical thanks On Sun, Jan 22, 2006 at 05:27:43PM +0300, Nikita V. Youshchenko wrote: Package: initramfs-tools,kernel,udev Currently: - recent linux-image packages depend on 'initramfs-tools | yaird | linux-initramfs-tool', so initramfs-tools is the 'default' alternative - initramfs-tools depends on recent udev - recent udev refuses to install unless recent kernel is running This loop needs to be broken somehow. Indeed. This means that we could as well make yaird the default again, since in both case we need to first upgrade the kernel to a recent 2.6, and then only can we upgrade the the kernel. So, this absolutely needs to be solved, thus raising the severity to critical :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#349354: initramfs-tools - kernel -udev dependency loop
Processing commands for [EMAIL PROTECTED]: severity 349354 critical Bug#349354: initramfs-tools - kernel -udev dependency loop Severity set to `critical'. 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#349123: Is mkvmlinuz a ramdisk creator?
On Tue, Jan 24, 2006 at 10:35:43AM +0100, Simon Richter wrote: Hi, Paul TBBle Hampson wrote: Reading the manpage of mkvmlinuz indicates it can _include_ an initrd in its output, but doesn't indicate it can assemble a ramdisk from scripts + modules + fairy dust. (Or whatever it is they use...) Yes, that was badly worded. If it is rightfully not detected as a ramdisk creator because it isn't one, then the problem of not depending on one still remains, however. Bah, the kernel depends on a ramdisk creator, so there should be no problem. The ramdisk can be provided by the user and can be any kind of random ramdisk tool, this is used for example by d-i which builds his own ramdisk. Furthermore mkvmlinuz can be used to build zImage kernels without ramdisk. So, no there is no need for a dependency on a ramdisk creator. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349123: Is mkvmlinuz a ramdisk creator?
Hi, Sven Luther wrote: Bah, the kernel depends on a ramdisk creator, so there should be no problem. Not for linux-image-2.6.15-1-powerpc: Package: linux-image-2.6.15-1-powerpc State: installed Automatically installed: yes Version: 2.6.15-3 Priority: optional Section: base Maintainer: Debian Kernel Team debian-kernel@lists.debian.org Uncompressed Size: 47,9M Depends: module-init-tools (= 0.9.13), mkvmlinuz (= 18) Suggests: linux-doc-2.6.15 | linux-source-2.6.15 Provides: linux-image-2.6, linux-image Description: Linux kernel 2.6.15 image on powerpc-class machines Simon signature.asc Description: OpenPGP digital signature
Bug#349123: Is mkvmlinuz a ramdisk creator?
On Fri, Jan 27, 2006 at 08:56:37PM +0100, Simon Richter wrote: Hi, Sven Luther wrote: Bah, the kernel depends on a ramdisk creator, so there should be no problem. Not for linux-image-2.6.15-1-powerpc: Yeah, sorry, noticed only later that the bug was against the kernels and not against mkvmlinuz. Anyway, can you mark this bug RC please ? We need to fix it before this package enters testing, i will have a look tomorrow, and we need to fix this for -4. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#120116: Greetings,
Hows it been going, [EMAIL PROTECTED] We spoke a few days ago and I'd like to confirm everything now. Please go over the information below and let me know if you have any questions. woowuqq.com/?a=ereetdust We are accepting your form. Your status has been accepted. We need to confirm your details one more time. Just check the URL above and fill out our last form. Thanks, [EMAIL PROTECTED] Adrian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349123: Is mkvmlinuz a ramdisk creator?
On Fri, Jan 27, 2006 at 11:26:04PM +0100, Jonas Smedegaard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 27 Jan 2006 20:37:51 +0100 Sven Luther [EMAIL PROTECTED] wrote: On Tue, Jan 24, 2006 at 10:35:43AM +0100, Simon Richter wrote: Hi, Paul TBBle Hampson wrote: Reading the manpage of mkvmlinuz indicates it can _include_ an initrd in its output, but doesn't indicate it can assemble a ramdisk from scripts + modules + fairy dust. (Or whatever it is they use...) Yes, that was badly worded. If it is rightfully not detected as a ramdisk creator because it isn't one, then the problem of not depending on one still remains, however. Bah, the kernel depends on a ramdisk creator, so there should be no problem. The ramdisk can be provided by the user and can be any kind of random ramdisk tool, this is used for example by d-i which builds his own ramdisk. Furthermore mkvmlinuz can be used to build zImage kernels without ramdisk. So, no there is no need for a dependency on a ramdisk creator. I agree. But perhaps a suggests then? And suggest a kernel image too? No, i don't think this is needed. The kernel should be fixed though to again include the dependency on yaird or initramfs-tools, don't know who of maks or waldi broke that though :) Will fix tomorrow in any case. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: severity set down to serious on Steve's request.
Processing commands for [EMAIL PROTECTED]: severity 349354 serious Bug#349354: initramfs-tools - kernel -udev dependency loop Severity set to `serious'. 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#347711: kernel: linux-image-2.6.15-1-amd64-generic panics when pppd is run
I wrote (Saturday 28 January 2006 3:55 pm): Hi! Sorry, KMail giving me crap, links are: http://bugzilla.kernel.org/show_bug.cgi?id=5857 http://lkml.org/lkml/2006/1/15/113 http://bugzilla.kernel.org/attachment.cgi?id=7086action=view Peace, Brendon pgp1YKFpcLmI4.pgp Description: PGP signature
Bug#349765: linux-2.6.14-2-alpha-generic: please support the prctl syscall
On Tue, Jan 24, 2006 at 10:42:06PM -0500, Kyle McMartin wrote: On Tue, Jan 24, 2006 at 07:06:00PM -0800, Steve Langasek wrote: So please make it work; knowing this exists and should be supported, I'm not willing to hack up prctl's source to use __NR_osf_setsysinfo instead. :) Bleh. Untested, as I don't have an alpha. arch/alpha/kernel/traps.c already contained jazz to check if the various TIF_ were set, they were just lacking a convenient way to set things. You probably need to make prctl() know which bits to twiddle. After changing addr to value, compiles fine; prctl -q runs ok now, prctl --unaligned=signal doesn't have any effect. You say that it's going to be the prctl() function in the kernel that needs further tweaks? 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/ signature.asc Description: Digital signature
Bug#349765: linux-2.6.14-2-alpha-generic: please support the prctl syscall
On Fri, Jan 27, 2006 at 10:19:55PM -0800, Steve Langasek wrote: After changing addr to value, compiles fine; prctl -q runs ok now, prctl --unaligned=signal doesn't have any effect. You say that it's going to be the prctl() function in the kernel that needs further tweaks? I'm not sure, I'd recommend adding a printk to GET/SET_UNALIGN_CTL to see if the correct values are being set to flags, barring that I'll take a look at alpha's unaligned handler and see if I missed something when I said shouldn't need any other work. Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Adjusting tags/severity/package
Processing commands for [EMAIL PROTECTED]: tags 347711 upstream patch Bug#347711: kernel: linux-image-2.6.15-1-amd64-generic panics when pppd is run There were no tags set. Tags added: upstream, patch severity 347711 important Bug#347711: kernel: linux-image-2.6.15-1-amd64-generic panics when pppd is run Severity set to `important'. reassign 347711 linux-2.6 Bug#347711: kernel: linux-image-2.6.15-1-amd64-generic panics when pppd is run Bug reassigned from package `kernel' to `linux-2.6'. 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#349765: linux-2.6.14-2-alpha-generic: please support the prctl syscall
After changing addr to value, compiles fine; prctl -q runs ok now, prctl
--unaligned=signal doesn't have any effect. You say that it's going to be
the prctl() function in the kernel that needs further tweaks?
I suspect this is the problem:
(linux/prctl.h)
# define PR_UNALIGN_NOPRINT 1 /* silently fix up unaligned user
accesses */
# define PR_UNALIGN_SIGBUS 2 /* generate SIGBUS on unaligned user
access */
(asm-parisc/processor.h asm-ia64/processor.h)
#define PARISC_UAC_NOPRINT (1UL 0) /* see prctl and unaligned.c */
#define PARISC_UAC_SIGBUS (1UL 1)
IE, NOPRINT is set by 1, and SIGBUS set by 2.
on alpha, because it's reusing the OSF/1 crap, the order is
NOPRINT, NOFIX, SIGNAL, ie: 1, 2, 4.
I don't know what the best way to fix this is, but something like
this patch will probably help,
Index: prctl-1.4/prctl.c
===
--- prctl-1.4.orig/prctl.c 2003-03-05 13:52:32.0 -0500
+++ prctl-1.4/prctl.c 2006-01-28 01:47:20.0 -0500
@@ -67,6 +67,11 @@
printf( --fpemu=[silent|signal|default]\n);
}
+#ifdef __alpha__
+#undef PR_UNALIGN_SIGBUS
+#define PR_UNALIGN_SIGBUS 4
+#endif /* __alpha__ */
+
int set_unaligned(int prctl_val)
{
int alignval, retval;
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
