Red Hat Bugzilla – Bug 207892
x86_64f kernel rock bottom
Last modified: 2007-11-30 17:11:44 EST
(this is some sort of followup of bugs 205147,205567)
i still receive system freezes with 2.6.17-1.2187_FC5
when i want to enable a serial console the kernel won't even boot
i now stick with linux for a very long time, but this is the most sadest day in
my life. maybe i will have to switch to ms. i am in the mood to weritea letter
to linux torvalds to ask him what bunch of drunkards is maintaining amd branch
Created attachment 137034 [details]
dmesg on serial console - does not boot but gets stuck in lost ticks
i have currently 3 bugs open with serious kernel-issues.
so far not even one comment of kernel-maintainers
nothing which says e.g.
- we are working on those issues
- you can expect this and that within a period of xxx
- status of upstream maintainer's comments to this and similar issues
what can we learn from this ?
... and YES.
i AM a r4edhat customer and my customers have at present one ES4 and one AS4 in
rhn for production purposes.
one of MY machines with fc5 acts as test-machine and what to expect in the future.
i am definitly NOT CONVINCED TO STICK WITH RH any further ...
Here comes "whatever"...
We work on everything we can as we get to it. However, resources are finite, and
unfortunately, Fedora bugs usually don't get priority/attention over RHEL bugs,
unless its a bug we can easily reproduce and/or it affects a great number of
users. Fedora changes rapidly, and is provided free of charge, but with no
guarantee of support from Red Hat. It boils down to a simple case of economics.
That said, out of curiosity, have you looked into a bios update for your board?
This honestly sounds more like a broken bios than anything else, as we have tons
of users running smp x86_64 systems without a problem. While Asus makes some
relatively nice motherboards, they don't have a great track record when it comes
As an additional note: Bugzilla gets hundreds of bugs a day. Which do you think
is more likely that developers are going to devote time to diagnosing..
a) A politely worded bug report
b) Rants, insults and threats ?
There were some x86-64 timekeeping fixes in the 2.6.18 kernel, try the kernel in
updates-testing. If you manage to get useful traces out of that, boot without
the report_lost_ticks=1 option so that it remains readable.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.
Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.
This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.
Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.
In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed. See bug 207474 for further details.
If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.
If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.
ok, will now switch to 2.6.18-1.2200.
2.6.18-1.2189 results : no change :
- use of serial console yields unbootable so no detailed anylyzing was possible
(also allies to bugs 205147,205567)
instead of posting detailed timer-tick-logs from kernel (kernel with serial
console dies if report-timer-ticks is set too low like 10) :
here a windoze kernel-dump of my vmware-guest : IT IS A TIMER-ISSUE as you can see :
i suppose nothing changed in guts of kernel but kmesgs were removed to simulate
absence of annoyances
TRAP_FRAME: 80548cd0 -- (.trap ffffffff80548cd0)
ErrCode = 00000000
eax=c1161b8a ebx=000002c7 ecx=2e96ec2f edx=00000003 esi=2e93a538 edi=00000003
eip=806d0d8f esp=80548d44 ebp=80548d58 iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206
806d0d8f f7f7 div edi
Resetting default scope
LAST_CONTROL_TRANSFER: from 8059654b to 804f8900
80548c6c 8059654b 0000007f 806d0d8f 2e93a538 nt!KeBugCheck+0x14
80548cc4 8053d3ef 80548cd0 80548d58 806d0d8f nt!Ki386CheckDivideByZeroTrap+0x41
80548cc4 806d0d8f 80548cd0 80548d58 806d0d8f nt!KiTrap00+0x83
80548d58 f9b2d2b0 000002ca 816aacb0 816aab48 hal!HalpPmTimerStallExecProc+0x9f
80548d6c f9b2c501 00000001 817560a8 80548d9c es1371mp!CES1371::PauseDMAChannel+0x100
80548d7c f958664c 816aacb0 00000000 817194a0 es1371mp!InterruptServiceRoutine+0xd9
80548d9c 8054071d 817194a0 006aacb0 00010006 portcls!CKsShellRequestor::`vector
80548d9c f9addc46 817194a0 006aacb0 00010006 nt!KiInterruptDispatch+0x3d
80548e50 80540cc0 00000000 0000000e 00000000 processr!AcpiC1Idle+0x12
80548e54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x10
f9b2d2b0 5f pop edi
please close bug - systems updated to fc6 - no use to follow here
new announcments for revisited timer code in 2.6.20