Re: [Lenny] linux-image-2.6.26-1-openvz-amd64 kernel panic on boot
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 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 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: > 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 Wed, Feb 25, 2009 at 03:33:04PM +0100, Cedric Jeanneret wrote: > > > 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-26-1-openvz-amd64-kernel-panic.html > > > > > > As nobody answer to him, I'm trying to find some things in here. > > > > > > FYI, openvz.org kernel runs nicely (ovzkernel-2.6.18-amd64-smp), but as it's a bit old... we really want to use debian's packages... > > > > > > Thanks in advance. > > > > > > C. > > > > > > -- > > > Cédric Jeanneret | System Administrator > > > 021 619 10 32| Camptocamp SA > > > cedric.jeanne...@camptocamp.com | PSE-A / EPFL > > > > > > > > > -- > Cédric Jeanneret | System Administrator > 021 619 10 32| Camptocamp SA > cedric.jeanne...@camptocamp.com | PSE-A / EPFL -- Cédric Jeanneret | System Administrator 021 619 10 32| Camptocamp SA cedric.jeanne...@camptocamp.com | PSE-A / EPFL -- --- Inguza Technology AB --- MSc in Information Technology / o...@inguza.comAnnebergsslingan 37\ | o...@debian.org 654 65 KARLSTAD| | http://inguza.com/Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Lenny] linux-image-2.6.26-1-openvz-amd64 kernel panic on boot
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: > 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 Wed, Feb 25, 2009 at 03:33:04PM +0100, Cedric Jeanneret wrote: > > > 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-26-1-openvz-amd64-kernel-panic.html > > > > > > As nobody answer to him, I'm trying to find some things in here. > > > > > > FYI, openvz.org kernel runs nicely (ovzkernel-2.6.18-amd64-smp), but as > > > it's a bit old... we really want to use debian's packages... > > > > > > Thanks in advance. > > > > > > C. > > > > > > -- > > > Cédric Jeanneret | System Administrator > > > 021 619 10 32| Camptocamp SA > > > cedric.jeanne...@camptocamp.com | PSE-A / EPFL > > > > > > > > > -- > Cédric Jeanneret | System Administrator > 021 619 10 32| Camptocamp SA > cedric.jeanne...@camptocamp.com | PSE-A / EPFL -- --- Inguza Technology AB --- MSc in Information Technology / o...@inguza.comAnnebergsslingan 37\ | o...@debian.org 654 65 KARLSTAD| | http://inguza.com/Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Lenny] linux-image-2.6.26-1-openvz-amd64 kernel panic on boot
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 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: > > 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 Wed, Feb 25, 2009 at 03:33:04PM +0100, Cedric Jeanneret wrote: > > > > 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-26-1-openvz-amd64-kernel-panic.html > > > > > > > > As nobody answer to him, I'm trying to find some things in here. > > > > > > > > FYI, openvz.org kernel runs nicely (ovzkernel-2.6.18-amd64-smp), but as > > > > it's a bit old... we really want to use debian's packages... > > > > > > > > Thanks in advance. > > > > > > > > C. > > > > > > > > -- > > > > Cédric Jeanneret | System Administrator > > > > 021 619 10 32| Camptocamp SA > > > > cedric.jeanne...@camptocamp.com | PSE-A / EPFL > > > > > > > > > > > > > > > -- > > Cédric Jeanneret | System Administrator > > 021 619 10 32| Camptocamp SA > > cedric.jeanne...@camptocamp.com | PSE-A / EPFL > > > -- Cédric Jeanneret | System Administrator 021 619 10 32| Camptocamp SA cedric.jeanne...@camptocamp.com | PSE-A / EPFL signature.asc Description: PGP signature
Re: [Lenny] linux-image-2.6.26-1-openvz-amd64 kernel panic on boot
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 Wed, Feb 25, 2009 at 03:33:04PM +0100, Cedric Jeanneret wrote: > > 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-26-1-openvz-amd64-kernel-panic.html > > > > As nobody answer to him, I'm trying to find some things in here. > > > > FYI, openvz.org kernel runs nicely (ovzkernel-2.6.18-amd64-smp), but as > > it's a bit old... we really want to use debian's packages... > > > > Thanks in advance. > > > > C. > > > > -- > > Cédric Jeanneret | System Administrator > > 021 619 10 32| Camptocamp SA > > cedric.jeanne...@camptocamp.com | PSE-A / EPFL > > > -- Cédric Jeanneret | System Administrator 021 619 10 32| Camptocamp SA cedric.jeanne...@camptocamp.com | PSE-A / EPFL signature.asc Description: PGP signature
Bug#511334: debian-installer: S390 boot fails on Flex-ES machine
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 "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Re: dmesg timestamps vs uptime
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 bond0 -tt -vvv -n "(dst host raider or src host raider)" -s 192 | head -3; dmesg | tail -1; grep -e 'now' -e '\.clock' /proc/sched_debug ; echo -n "date :"; date +'%s.%N'; echo -n "uptime:"; cat /proc/uptime 1235620965.207560 IP (tos 0x0, . ... [259941.257724] device eth1 left promiscuous mode now at 250362660.852703 msecs .clock : 250362660.973307 .clock : 250362661.008877 date :1235620965.387909070 uptime:250362.67 232514.99 so indeed /proc/uptime is close (or is) what is in .clock in sched_debug, but how could I get those 259941.257724? I am sorry if that is something obvious and RTFM -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-1412 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dmesg timestamps vs uptime
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: > > * Difference between dmesg timestamp and /proc/uptime > > $> tcpdump -i bond0 -tt -vvv -n "(dst host raider or src host raider)" -s 192 > | head -3; dmesg | tail -1; echo "/proc/uptime"; cat /proc/uptime > ... > [250851.259481] device eth1 left promiscuous mode > /proc/uptime > 241764.70 224706.33 > > so I have timestamp in kernel messages bigger than uptime > > I wonder why is that? different clock source? any other drift? Different clock source. > or may be 'kernel time' in dmesg is some kind of tick, not time per se? It's a scheduler timestamp, which is an approximation to real time but due to internal requirements of the scheduler may run slightly fast. Timestamps in the kernel log help to show how close together events occurred, but nothing more. > * Is there an easy way to convert (reliably ;)) timestamp in dmesg to > time since epoch (with mksec precision of cause), so I could easily compare > with output in strace and alike. Not really, but you can get a scheduler timestamp from /proc/sched_debug which may help in correlating them. Ben. signature.asc Description: This is a digitally signed message part
Re: dmesg timestamps vs uptime
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 monitor those 'semi stable' clocks so later on provide more or less reliable and consistent conversion into time since epoch. On Wed, 25 Feb 2009, Yaroslav Halchenko wrote: > * Difference between dmesg timestamp and /proc/uptime > * Is there an easy way to convert (reliably ;)) timestamp in dmesg to > time since epoch (with mksec precision of cause), so I could easily compare > with output in strace and alike. > Thanks in advance -- Yaroslav Halchenko Ph.D. Student CS Dept. NJIT -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
dmesg timestamps vs uptime
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 -vvv -n "(dst host raider or src host raider)" -s 192 | head -3; dmesg | tail -1; echo "/proc/uptime"; cat /proc/uptime ... [250851.259481] device eth1 left promiscuous mode /proc/uptime 241764.70 224706.33 so I have timestamp in kernel messages bigger than uptime I wonder why is that? different clock source? any other drift? or may be 'kernel time' in dmesg is some kind of tick, not time per se? * Is there an easy way to convert (reliably ;)) timestamp in dmesg to time since epoch (with mksec precision of cause), so I could easily compare with output in strace and alike. Thanks in advance -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-1412 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik signature.asc Description: Digital signature
Bug#514292: linux-image-2.6.28-1-amd64: Bad page state in process 'emacs'
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 Feb 2009 17:26:41 +0100, maximilian attems wrote: >>> how easily can you reproduce!? >>> if easily please consider to tell bugzilla.kernel.org >>> and let us know the bug number. This afternoon with linux-image-2.6.28-1-amd64_2.6.28-2~snapshot.12850: Emacs and two other bash processes were running in a screen session, plus a Conkeror one. The oops happened after having issued an `apt-get update`, so I would say it is not at all related to Emacs. Should I report it upstream? Any other hint to a possible solution? PS, I have not reported other oops since my last mail because I switched back to linux-image-2.6.26-1-amd64_2.6.26-14~snapshot.12720: no oops at all with this version. Thx, bye, Gismo / Luca apt-get-oops_20090225-1.syslog.gz Description: syslog extract for apt-get oops pgpPyvnS0ydbE.pgp Description: PGP signature
Bug#517158: linux-source-2.6.28: PGP ".sign" file remained in sources
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. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-vl-deb-ws (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-source-2.6.28 depends on: ii binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina ii bzip2 1.0.5-1 high-quality block-sorting file co Versions of packages linux-source-2.6.28 recommends: ii gcc 4:4.3.2-2 The GNU C compiler ii libc6-dev [libc-dev] 2.7-18 GNU C Library: Development Librari ii make 3.81-5 The GNU version of the "make" util Versions of packages linux-source-2.6.28 suggests: ii kernel-package11.015 A utility for building Linux kerne ii libncurses5-dev [ncurses- 5.7+20081213-1 developer's libraries and docs for ii libqt3-mt-dev 3:3.3.8b-5 Qt development files (Threaded) -- no debconf information -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#367026: Nope, stll doesn't work
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 fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org signature.asc Description: PGP signature
Re: Kernel Panic installing on SGI Indy
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 caches switching to a 32-bit kernel is a good > > > idea to get best performance but we should probably enable the R4000 > > > workaround automatically in Kconfig for 64-bit Indy kernels. > > > > isn't there a gcc needed, which supports all workarounds ? What about > > the performance impact of that workarounds ? > > They definately will have some performance impact but the only person > who may have some experience with that is probably Maciej. I haven't benchmarked the difference as when correctness is required the performance hit is secondary. The hit is taken only if the workarounds are actually activated -- there is nothing hardcoded in the patches and the "-mno-daddi" and "-mdaddi" options switch the workarounds on and off respectively. The default is "-mno-daddi" if "-mfix-r4000" or "-mfix-r4400" was specified; "-mdaddi" otherwise. Technically all 64-bit immediate additions are converted to a sequence of an immediate load to a temporary register (which is really a 32-bit addition to $zero) followed by a 64-bit register addition. Plus $t8 is marked as fixed in GCC because the compiler is not (or at least wasn't at the time I prepared the workaround) prepared to allocate a scratch register for branches (an extra spare register is needed to load the target address of an out-of-range branch being relaxed). It takes one temporary register away from the pool available and will certainly affect allocation in some cases and therefore performance. > As I recall only a part of the workarounds needed is supported by an > unpatched gcc but again Maciej will know more. Correct -- the changes to work around the buggy DADDIU instructions proved too invasive for long-term maintenance upstream. Two patches are required, for binutils and GCC respectively. Some handcoded assembly code which uses ".set noat" may not build anymore and require modifications. I have made source RPM packages of patched tools available at: ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/SRPMS/ -- the newest version of GCC is gcc-4.1.2-8.src.rpm and for binutils this is binutils-2.18-4.src.rpm -- look for patches named *-mips-nodaddi-*. Binary packages are available there in a neigbour directory too, in case you wanted to try something quickly. ;) Because of various more and less recent circumstances I haven't ported the patches to newer versions of the respective tools (sorry), but I intend to do so at some point in the future. Let me know if I can be of assistance. Maciej -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#505174: linux-image-2.6.26-1-686: After installed vmware-tools, the mouse stuck in debian (i'm running vmware workstation 6.5 in Win XP)
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 > debian lenny, the mouse stuck in debian lenny! > I've seen this as well, but since vmware seems to have caused it, and their software is most definitely non-free, I don't think this is a bug in Linux or anything else Debian needs to care about. FWIW, you can work around this by editing your xorg.conf and replacing vmmouse with mouse. noah signature.asc Description: Digital signature
Bug#511334: debian-installer: S390 boot fails on Flex-ES machine
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. At any rate, it's always some timer routine. So, this may just be telling us that the kernel keeps setting a timer waiting for something to happen, waking up, seeing that whatever hasn't happened, and trying again. But there's another hunch I'm testing: The default ticks Hz value on this kernel was 250. This problem has only appeared on Flex and Hercules. What these have in common is that they're emulated s390 machines, and they're very much slower than the real iron. Might it be that having the jiffy timer popping every 4 ms is interacting badly with what is, effectively, a very very slow variable-clock machine? If that's the case, turning off timer ticks (i.e. CONFIG_NO_HZ=y) may be enough to let me boot, which would be cool. I don't know if that will work on Hercules (or in an LPAR) though. For whatever it's worth, on the etchnhalf system /proc/sys/kernel/hz_timer is 0, which I *think* means the on-demand timer is enabled. Unfortunately, on my system it takes a lot of hours to build a kernel, so I'm not going to be able to test these hypotheses fast. Adam -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#517130: linux-modules-extra-2.6: Potential GPL violations
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 likely, that the archive may end up containing binaries for which the source has expired. This was dealt with (quietly) for lenny by the ftpteam auditing the build logs and binaries to check that the sources were all present, and inserting the source entries into the special lenny-r0 suite to ensure that they will be retained even if their source packages are revised in a stable point release. The ftpteam considers this a RC bug for squeeze and an improved manner of handling the source dependencies for these modules must be found. At FOSDEM, preliminary discussions were held regarding adding a method by which binary packages could declare that they were built using a particular version of another source or binary package so that the archive can track this and ensure that the relevant source is kept around. This will of course require some dpkg-dev and dak changes and consensus that the idea is a sane one before it can be implemented. A proposal will be sent to debian-devel@ soon. Whichever solution is arrived at needs to deal with the problem at all points in the release cycle, not just at stable or point releases. Thanks, Mark (on behalf of the ftpteam) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#517122: libc6: very slow access/open/... syscalls on NFS mounted files
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.322673 10008 332 171 stat 25.461.9557757190 27228 open 16.581.2733616006 212 162 access 12.250.940696 649 1449 1 lstat 1.060.081252 16250 5 1 unlink 0.780.060004 30002 2 link whenever on another node (with no problem): % time seconds usecs/call callserrors syscall -- --- --- - - 66.350.008808 0 18427 read 9.080.001206 0 52497 rt_sigprocmask 5.730.000761 2234 clone 3.530.000468 1 342 180 stat 3.480.000462 0 235420 close 3.290.000437 0 90828 open 2.830.000376 0 1410 1 lstat 2.450.000325 56834 wait4 > reassign 517122 linux-2.6 > retitle 517122 linux-2.6: very slow access/open/... syscalls on NFS mounted > files > thanks > > whenever on other nodes it takes just 0.0001 or so > This time is the time the userland (ie libc6) waits before getting an > answer. -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-1412 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#516734: Same goes here: linux-headers-2.6.28 uninstallable due to unmet dependency on linux-kbuild-2.6.28
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/ It was funny how people were people everywhere you went, even if the people concerned weren't the people the people who made up the phrase ``people are people everywhere'' had traditionally thought of as people. -- Terry Pratchet, The Fifth Elephant Vincent, listening to Know Your enemy (Rage Against the Machine) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#517122: libc6: very slow access/open/... syscalls on NFS mounted files
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#517122: libc6: very slow access/open/... syscalls on NFS mounted files Changed Bug title to `linux-2.6: very slow access/open/... syscalls on NFS mounted files' from `libc6: very slow access/open/... syscalls on NFS mounted files'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Kernel Panic installing on SGI Indy
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 8k caches switching to a 32-bit kernel is a good > idea to get best performance but we should probably enable the R4000 > workaround automatically in Kconfig for 64-bit Indy kernels. isn't there a gcc needed, which supports all workarounds ? What about the performance impact of that workarounds ? Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea.[ RFC1925, 2.3 ] -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511334: debian-installer: S390 boot fails on Flex-ES machine
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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Lenny] linux-image-2.6.26-1-openvz-amd64 kernel panic on boot
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) 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-26-1-openvz-amd64-kernel-panic.html > > As nobody answer to him, I'm trying to find some things in here. > > FYI, openvz.org kernel runs nicely (ovzkernel-2.6.18-amd64-smp), but as it's > a bit old... we really want to use debian's packages... > > Thanks in advance. > > C. > > -- > Cédric Jeanneret | System Administrator > 021 619 10 32| Camptocamp SA > cedric.jeanne...@camptocamp.com | PSE-A / EPFL -- - Ola Lundqvist --- / o...@debian.org Annebergsslingan 37 \ | o...@inguza.com 654 65 KARLSTAD | | http://inguza.com/ +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[Lenny] linux-image-2.6.26-1-openvz-amd64 kernel panic on boot
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-26-1-openvz-amd64-kernel-panic.html As nobody answer to him, I'm trying to find some things in here. FYI, openvz.org kernel runs nicely (ovzkernel-2.6.18-amd64-smp), but as it's a bit old... we really want to use debian's packages... Thanks in advance. C. -- Cédric Jeanneret | System Administrator 021 619 10 32| Camptocamp SA cedric.jeanne...@camptocamp.com | PSE-A / EPFL signature.asc Description: PGP signature
Bug#517072: MODULES=dep fails w/ luks over cciss devices
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 over the cciss device.
As bug #507619 describes:
"dep_add_modules() expects to find a /sys/block/cciss/c0d0p file, but
it should be trying /sys/block/cciss!c0d0"
It also mentions:
"fyi, I suspect this may also apply to old-style smart array devices,
where device names are similar, but use 'ida' intead of 'cciss' -
e.g. /dev/ida/c0d0p1."
The following patch fixes it for me (on cciss) and should also fix it
for ida devices:
--- /usr/share/initramfs-tools/hook-functions.orig 2009-02-25
13:59:04.0 +0100
+++ /usr/share/initramfs-tools/hook-functions 2009-02-25
14:00:50.0 +0100
@@ -259,7 +259,13 @@
block=$(awk "/^${block}/{print substr(\$5, 1, 4);
exit}" \
/proc/mdstat)
fi
- block=${block%[0-9]*}
+ # luks or lvm on cciss or ida
+ if [ "${block#cciss}" != "${block}" ] \
+ || [ "${block#ida}" != "${block}" ]; then
+ block="${block%p*}"
+ else
+ block=${block%[0-9]*}
+ fi
# md root new naming scheme /dev/md/X
elif [ "${root#/dev/md/}" != "${root}" ]; then
root=${root#/dev/md/}
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514418: [FIX]: ultra45 boot failing...
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 do that for r1. OK so here is a tentative patch to fall back to the fbdev driver on sparc. I'd appreciate if people could test it against lenny's xorg-server, and/or suggest better ways to do this. Cheers, Julien 0001-Add-an-fbdev-screen-as-a-fallback-on-sparc.patch Description: application/mbox
Re: Kernel Panic installing on SGI Indy
* 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 Indy, which will hopefully be named Whistle upon > successful installation, experienced a kernel panic very shortly after > downloading the netboot file (though it's much less frustrating having > something like this occur early in the installation process). > > The output was something along the lines of: > > Checking for multiply shift/bug? bug present? yes. workaround present? no. > There might have been a line here but I forget what it was. > Kernel Panic! > Enable CPU_R4000_WORKAROUNDS to rectify. > > A Google search of "CPU_R4000_WORKAROUNDS debian" (not in quotes) returns > one page of results referring to mostly if not all debian kernel image > configuration files. > > It was suggested to me on the Debian support IRC channel that I might > email debian-kernel-list to notify of the problem and to seek feedback. > > In any case, the CPU_R4000_WORKAROUNDS flag is referred to in two > sections of all of the Google search results (which are pretty much all > some file called Kconfig): > "config MACH_DECSTATION" and "config CPU_R4000_WORKAROUNDS" > > However, it isn't referred to in the "config SGI_IP22" section. This > machine, meanwhile, is detected as SGI_IP22 by the bootloader. Ralf, Thomas, any comments? -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#517048: Clock problem with live migration
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-8:~# uname -a Linux xen-8 2.6.26-1-xen-amd64 #1 SMP Sat Jan 10 20:39:26 UTC 2009 x86_64 GNU/Linux xen-8:~# xm list NameID Mem VCPUs State Time(s) Domain-0 0 500 8 r- 2559.1 flashstream-001 86 250 2 -b 6.9 xen-5:~# uptime 12:36:53 up 12 days, 15 min, 1 user, load average: 0.00, 0.00, 0.00 xen-5:~# xm list NameID Mem VCPUs State Time(s) Domain-0 0 500 8 r- 448967.8 xen-5:~# uname -a Linux xen-5 2.6.26-1-xen-amd64 #1 SMP Sat Jan 10 20:39:26 UTC 2009 x86_64 GNU/Linux # Everyone is synced ... xen-8:~# date Tue Feb 24 12:37:17 CET 2009 xen-5:~# date Tue Feb 24 12:37:18 CET 2009 flashstream-001:~# date Tue Feb 24 12:37:19 CET 2009 # let's migrate the domU from xen-8 to xen-5 xen-8:/etc/xen# xm migrate flashstream-001 -l 10.20.0.5 On the domU : flashstream-001:~# date Tue Feb 24 12:41:35 CET 2009 # Migration is here flashstream-001:~# date Sat Mar 7 15:13:05 CET 2009 I don't encounter the bug when I use the 2.6.18-6-xen kernel from etch. I tryed to do "echo 1 > /proc/sys/xen/independent_wallclock" everywhere it's possible (in dom0 or domU), it don't change anything. Setting the clocksource to jiffies in the domU fix the problem, but it have a resolution of 4ms which sux :(. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.26-1-xen-amd64 Locale: lang=fr...@euro, lc_ctype=fr...@euro (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processed: severity of 517013 is important
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. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
