So maybe others can use this and help us understand later the
"why" of it.
Well, timing (clock and event) is possibly even more critical for smp
architecture than for single cpu systems. Trying to run k7-smp-
systems with originally 1981 based timers ("pit") as clocksource
seems to be st
Hello all,
I've done as Alexander has suggested:
added a boot option in /boot/grub/menu.lst
snip>
title Debian GNU/Linux, kernel 2.6.18-4-k7
root(hd0,0)
kernel /vmlinuz-2.6.18-4-k7 root=/dev/sda2 ro clocksource=tsc
initrd /initrd.img-2.6.18-4-k7
savedefault
rebo
I can live single processor for a while. So yes reduction of severity is
okay for me. But, I'm thinking that there are a number of k7-smp servers
that are the truck horses of various clusters (esp. universities and
small research groups) who mayn't tolerate the loss of utility.
matthew
Hello again,
i hope, i may take the liberty of presenting you a working solution.
So the late grave bug (sorry for this again!) hopefully will be
closed quite soon.
a) testing info
Running 2.6.18-4-k7 without "nosmp" i looked what clocksources are
actually available and which one is us
Hello Steve,
uptime with "nosmp" so far: 57 min. Everything runs fine and
smoothly. Of course overall system load is about 5 percent (average)
to 20 percent (peak) higher than usual - man, i do love and miss
smp.. :D
Just kidding, i can easily live happily either with "nosmp" or
parti
On Sun, Feb 25, 2007 at 09:26:10AM +0100, Alexander Schories wrote:
> >OOI, does booting with 'nosmp' affect this hang problem for either
> >of you?
> Will try this right now and give you response within 1h.
> In the meantime, do you think the clocksource - as described above -
> could be the
Hello,
Um, not exactly helpful; you're now reporting a bug at a severity
that makes
it a release blocker, at a point where the final kernel for etch r0 is
supposed to already be uploaded and there is limited time to consult
upstream about it. In the future, please report such bugs when you
Steve Langasek wrote:
On Sat, Feb 24, 2007 at 03:21:58PM +0100, Alexander Schories wrote:
Um, not exactly helpful; you're now reporting a bug at a severity that makes
it a release blocker, at a point where the final kernel for etch r0 is
supposed to already be uploaded and there is limi
On Sat, Feb 24, 2007 at 03:21:58PM +0100, Alexander Schories wrote:
> Ever since kernel 2.6.18-* hit the debian testing and unstable
> ftp-stores my system totally freezes right after 5 to 10 minutes
> uptime with *any* of the 2.6.18-*-kernel-packages.
> NO logfile entry is left. NO panic or such
Exact same problem here! Has been for 3 months. Ubuntu2.6.15-28-k7 is
okay as were the -16 series kernels (did not try -17's). I now have to
go back to 2.6.18-4-i486 to get it to run and live without smp (I wiped
the -16-k7 stuff out [stupidly]).
Debian SID /Tyan Thunder 7X S2468UGN /Athlon 240
Dear maintainers,
after looking around in dmesg and other logs i finally found a
disparity:
While linux-image-2.6.17-2-k7 is booting with following clock:
#Real Time Clock Driver v1.12ac
#Generic RTC Driver v1.07
The linux-image-2.6.18-4-k7 uses pit as clocksource:
#Time: pit clocksourc
Package: linux-image-2.6.18-3-k7
Version: linux-image-2.6.18-3-k7 and linux-image-2.6.18-4-k7
Severity: grave
Justification: renders package unusable
linux-image-2.6.18-3-k7 and linux-image-2.6.18-4-k7 total system
freeze after max. 10 minutes uptime
Dear maintainers,
strange trouble since 6
12 matches
Mail list logo
