Howdy,
The problem just occurred again with 2.6.22-5.
--
Matt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Our records come with unlimited use rights and we have data for many other
specialties and professions. Contact me today as we have some deals
for this week only that I think you're really going to like ;-) My number is
(206) 202-3520
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a su
I still have the same problem with the current kernel.
The exact same system was working great with Debian Sarge and 2.6.8-2 kernel
Current problem system: Debian Etch
Linux version 2.6.18-5-686 (Debian 2.6.18.dfsg.1-13etch4)
([EMAIL PROTECTED]) (gc
c version 4.1.2 20061115 (prerelease) (Debian
On Thu, Nov 08, 2007 at 11:37:51AM -0800, Chris Poon wrote:
> Hello,
>
> It seems that the kernel package for sparc64 have the loop driver built-in
> instead of being a module, which makes loop-aes unusable - can't load either
> the loop.ko or the loop-aes.ko, kernel that the module export duplica
On Thu, Nov 08, 2007 at 08:09:11PM +0100, [EMAIL PROTECTED] wrote:
> Hi all:
>
> In Debian 4.0r1, the following 2 links in /sbin point to
> insmod.modutils, but that tool is not installed by default, and it
> probably would never be with a modern kernel (but please bear in mind
> that I'm a newcom
Hello,
It seems that the kernel package for sparc64 have the loop driver built-in
instead of being a module, which makes loop-aes unusable - can't load either
the loop.ko or the loop-aes.ko, kernel that the module export duplicate
symbol loop_register_transfer (owned by kernel), and trying to moun
Hi all:
In Debian 4.0r1, the following 2 links in /sbin point to
insmod.modutils, but that tool is not installed by default, and it
probably would never be with a modern kernel (but please bear in mind
that I'm a newcomer in this area).
lrwxrwxrwx 1 root root 15 2007-10-23 13:49 kallsyms -> insm
On Thu, Nov 08, 2007 at 11:21:18AM -0600, Barb Smith wrote:
> After reading through the documentation it seems I'd be better off
> compiling my own kernel then using a Debian one. I've never had this sort
> of problem on any distro I have ever used.
>
well the trouble that you are experienci
After reading through the documentation it seems I'd be better off
compiling my own kernel then using a Debian one. I've never had this sort
of problem on any distro I have ever used.
On Thu, 08 Nov 2007 11:08:44 -0600, maximilian attems <[EMAIL PROTECTED]> wrote:
[ please keep the bug rep
[ please keep the bug report on cc, that is not private, cool thanks ]
On Thu, Nov 08, 2007 at 10:43:56AM -0600, Barb Smith wrote:
> usb 1-2: new full speed USB device using ohci_hc and address 3
> usb 1-2: configuration #1 chosen from 1 choice
> usb 2-2: new low speed USB device using ohci_hcd an
Package: initramfs-tools
Version: 0.90a
Severity: wishlist
Currently, mkinitramfs hardcodes the assumption that all kernel modules
have been installed to /lib/modules/`uname -r`. This assumption does not
hold for development builds of kernels, which are to be booted on other
machines.
As discuss
On Thu, Nov 08, 2007 at 09:26:01AM -0600, Barb Smith wrote:
> That stopped that problem but now it freezes at
> drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
>
can you post a bit more of that log,
as aboves looks fine and may just be a mouse / keyboard loading.
also you could try to
That stopped that problem but now it freezes at
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
On Thu, 08 Nov 2007 06:39:05 -0600, Debian Bug Tracking System
<[EMAIL PROTECTED]> wrote:
Thank you for the additional information you have supplied regarding
this problem report. It ha
On Thu, Nov 08, 2007 at 06:21:30AM -0600, Barb Smith wrote:
> pn initramfs-tool (no description available)
> ii yaird 0.0.12-24 Yet Another mkInitRD
ah so yaird bwarfs, well that is expected somehow.
apt-get install initramfs-tools and shot a
update-initramfs -u -k
where
pn initramfs-tool (no description available)
ii yaird 0.0.12-24 Yet Another mkInitRD
debian:/home/mystified# cat /etc/kernel-img.conf
# Kernel image management overrides
# See kernel-img.conf(5) for details
do_symlinks = yes
relative_links = yes
do_bootloader = no
do_boot
Would it then be (more) correct, or at least more acceptable, to add
'#ifndef __KERNEL__' or similar to the glibc header file?
How would that interact with the earlier statement from Aurelien Jarmo
earlier in the discussion that
The definition of the structure ustat in sys/ustat.h is associated
On Thu, Nov 08, 2007 at 05:34:58AM -0600, Barb Smith wrote:
> This issue has not been resolved. I am still awaiting instructions as to
> how I can accomplish what needs to be done.
>
what initramfs are you using?
please post:
dpkg -l yaird initramfs-tools
cat /etc/kernel-img.conf
i never saw t
This issue has not been resolved. I am still awaiting instructions as to
how I can accomplish what needs to be done.
On Tue, 06 Nov 2007 13:51:02 -0600, Debian Bug Tracking System
<[EMAIL PROTECTED]> wrote:
Thank you for the additional information you have supplied regarding
this problem
Hi,
do we have confirmation, that this fixes our problems with the sparc
buildd? If yes, i would say, lets reschedule another round of kernels
for r2.
Martin
Greetings
Martin
On Wed Nov 07, 2007 at 11:41:11 +0100, Bernd Zeimetz wrote:
> Original Message
> From: [EMAIL PROTECT
reassign 449095 fglrx-driver
retitle 449095 [regression] fglrx-driver hangs the system on suspend-to-disk
found 449095 8.40.4-2
thanks
maximilian attems wrote:
Hello,
Sorry for the wrong assignment. I Installed 2.6.22-3 and managed to suspend and
restore the system ok. After a reboot I installed
Processing commands for [EMAIL PROTECTED]:
> reassign 449095 fglrx-driver
Bug#449095: linux-image-2.6.22-2-amd64: [regression] 2.6.22-2 hangs system when
trying to suspend-to-disk
Bug reassigned from package `linux-image-2.6.22-2-amd64' to `fglrx-driver'.
> retitle 449095 [regression] fglrx-driv
21 matches
Mail list logo
