Processing commands for cont...@bugs.debian.org:
> severity 517013 important
Bug#517013: linux-image-2.6.26-1-686: Suspected PS/2 device problem causes
system to hang
Severity set to `important' from `critical'
>
End of message, stopping processing here.
Please contact me if you need assistance
Package: linux-image-2.6.26-1-xen-amd64
Version: 2.6.26-13
Severity: important
When I migrate a domain from an host to another (which both run
the 2.6.26-1-xen-amd64 kernel), with the packaged xen 3.2.1-2,
the migrated domU have his time shifted by the timedelta of the
2 dom0 uptime.
# Demo :
xen
* Jacob Richard Beauregard [2009-02-24 22:12]:
> Well, this email regards one of the SGI Indys. With the first SGI Indy,
> now named Bell, I successfully installed Debian via netboot, though the
> partitioning step of the installation was a bit tricky. However, when
> netbooting the other SGI I
On Mon, 2009-02-09 at 12:49 +0100, Julien Cristau wrote:
> On Mon, 2009-02-09 at 01:21 -0800, David Miller wrote:
> > No, I would have said that if time is tight at least we can use
> > "fbdev" as the Xorg driver for PCI devices on sparc until we have a
> > better fix for Xorg.
>
> We can probably
Package: initramfs-tools
Version: 0.92o
Severity: important
Tags: patch
I needed to run update-initramfs w/ MODULES=dep (for some 15M BIOS size
limitation w/ lilo on an HP server), turns out that I found the same bug
as #507619 (please refer to it for details), except that I have a LUKS
format ove
Hello,
I just installed lenny on a new server (dell poweredge 2950) and wanted to use
the debian openvz kernel... Unfortunately, I'm just unable to boot the server
on it.
Poking on google, I found someone with exactly the same problem:
http://fixunix.com/debian/548482-bug-503097-linux-image-2-6-
Hi Cedric
This bug has been forwarded to http://bugzilla.openvz.org/show_bug.cgi?id=930
Unfortunatly the solution is not yet known.
Best regards,
// Ola
On Wed, Feb 25, 2009 at 03:33:04PM +0100, Cedric Jeanneret wrote:
> Hello,
>
> I just installed lenny on a new server (dell poweredge 2950) a
Fails on released Lenny as well.
I'm installing the kernel sources now to see if I can, in fact, build
a working 2.6.26 in an otherwise-Lenny environment.
If I get something that works on FLEX-ES I'd like for someone to try
it on Hercules.
Adam
--
To UNSUBSCRIBE, email to debian-kernel
On Wed, Feb 25, 2009 at 12:53:17PM +, Ralf Baechle wrote:
> You're getting this error message for the attempt to run a 64-bit kernel
> on certain very old R4000 revisions. So either run a 32-bit kernel,
> switch to newer version of the R4000 or to another MIPS CPU. For a
> processor with just
Processing commands for cont...@bugs.debian.org:
> reassign 517122 linux-2.6
Bug#517122: libc6: very slow access/open/... syscalls on NFS mounted files
Bug reassigned from package `libc6' to `linux-2.6'.
> retitle 517122 linux-2.6: very slow access/open/... syscalls on NFS mounted
> files
Bug#51
Hello,
Please fix this problem as soon as possible, as it prevents me, and
other people depending on kernel modules built using, for instance,
module-assistant from using the newer kernel.
Cheers,
Vincent
--
Vincent Fourmond, Debian Developer
http://vince-debian.blogspot.com/
I
Thank you Aurelien,
I should have RTFM more closely. Also I've ran strace -c which is
claimed to report time spent in kernel...
on that "slow" system it is
% time seconds usecs/call callserrors syscall
-- --- --- - -
43.253.32
Package: linux-modules-extra-2.6
Version: 2.6.26-6
Severity: serious
Dear all,
Shortly before the lenny release, it was noted that the
binary packages produced by linux-modules-extra-2.6 contain absolutely
no relation to the source with which they were built. It is therefore
possible, and indeed
Well, my custom kernel (in which, on a hunch, I turned off timer
ticks) is still building, but I now have this diagnostic information:
If you (under VM) do a CP D P ALL you see that you're generally in
scheduler_tick, sometimes in account_user_time_scaled, sometimes
tick_switch_to_oneshot.
On Wed, Feb 25, 2009 at 11:27:56PM +, Orlando Agostinho wrote:
> Package: linux-image-2.6.26-1-686
> Version: 2.6.26-13
> Followup-For: Bug #505174
Why is the is a followup for 505174? It doesn't seem at all related.
>
> I have vmware workstation 6.5 running in WIN XP. After, installed
> d
On Wed, 25 Feb 2009, Ralf Baechle wrote:
> > > You're getting this error message for the attempt to run a 64-bit kernel
> > > on certain very old R4000 revisions. So either run a 32-bit kernel,
> > > switch to newer version of the R4000 or to another MIPS CPU. For a
> > > processor with just 8k
In response to your query; I don't have the Logitech mouse anymore but
I just tested and Microsoft mice don't work so it probably is still not
working for any serial mice.
--
And that's my crabbing done for the day. Got it out of the way early,
now I have the rest of the afternoon to sniff frag
Package: linux-source-2.6.28
Version: 2.6.28-1
Severity: minor
Not sure if this is intential or not, but after unpacking linux-source-2.6.28,
I found a file patch-2.6.28.5-6.bz2.sign in the root of source directory.
Never saw this in previous kernel sources - so just thought to report it.
-- Sys
Hi there!
Small note: while this bug has been reassigned to linux-2.6, I think it
strictly belongs to the linux-image-2.6.28-1-amd64, read the PS below
for the reason.
On Mon, 16 Feb 2009 12:20:02 +0100, Luca Capello wrote:
> On Sun, 15 Feb 2009 19:12:22 +0100, Luca Capello wrote:
>> On Tue, 10 F
My today reported (and reassigned to linux2.6) bug #517122
doesn't gimme rest. One of the problem of analysis of traces is that
some times are recorded since epoch, some are the kernel's "uptime".
what puzzles me is:
* Difference between dmesg timestamp and /proc/uptime
$> tcpdump -i bond0 -tt -
I guess kernel/sched_clock.c gave me the answer to the 1st question...
even answered why I saw some timestamps jumping backwards while I was
monitoring debug msgs of RPC + NFS , I guess they came from different
CPUs
now I wonder if there is a tool which would "work" along some other
process and mo
On Wed, 2009-02-25 at 20:47 -0500, Yaroslav Halchenko wrote:
> My today reported (and reassigned to linux2.6) bug #517122
> doesn't gimme rest. One of the problem of analysis of traces is that
> some times are recorded since epoch, some are the kernel's "uptime".
> what puzzles me is:
>
> * Diffe
Hi Ben,
Thanks -- that is a nice pointer (i.e. /proc/sched_debug), but I still
can't match everything up in my mind... could you gimme a little hint?
I guess the .clock (in sched_debug) is the interesting one, but it
doesn't match up to the "time" reported by the kernel...
$> sudo tcpdump -i bon
Turning off the timer gets slightly farther, but hangs at 038c18,
which is in raise_softirq .
So that's not it.
Next step: turning the timer back down to 100 Hz. Doubt that's going
to help.
Adam
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsub
Thanks a lot.
I'll follow this bug on openvz.
Regards
C.
On Wed, 25 Feb 2009 17:53:09 +0100
Ola Lundqvist wrote:
> Hi Cedric
>
> This bug has been forwarded to http://bugzilla.openvz.org/show_bug.cgi?id=930
> Unfortunatly the solution is not yet known.
>
> Best regards,
>
> // Ola
>
> On W
Yup, at every boot... How can I have the full hangup log ? what can I provide
to help? as this server is emtpy for now (but not for long..), I can reboot it
several times. I can use it today.
Regards,
C.
On Thu, 26 Feb 2009 07:54:12 +0100
Ola Lundqvist wrote:
> Hi again
>
> The problem wit
Hi again
The problem with the previous bug report was that it was hard to reproduce
reliably. Your help may be helpful in this regard as I understand that
you have problem every time. Is that correct?
Best regards,
// Ola
On Thu, Feb 26, 2009 at 07:47:28AM +0100, Cedric Jeanneret wrote:
> Thank
Hi Cedric
Please take contact with Kir Kolyshkin . He know which
designer to contact about this issue.
Best regards,
// Ola
Quoting Cedric Jeanneret :
Yup, at every boot... How can I have the full hangup log ? what can
I provide to help? as this server is emtpy for now (but not for
l
28 matches
Mail list logo