On Fri, Apr 06, 2007 at 07:19:25PM +0100, Christian Kujau wrote:
> On Wed, 4 Apr 2007, Christian Kujau wrote:
> >>Maybe it's a real locking problem. Here are some more
> >>suggestions for testing (if you don't find anything better):
> >>- try without SMP, so: 'acpi=off lapic nosmp'
>
> We were able to have our hosting provider to replace the 8139too with a
> E100, the onboard r8169 stayed of course. After this, the box came back
> fine...only to lock up again shortly after :(
>
> So again we spoke to our hosting provider and they just took out the 2
> SATA disks and put them in a completely new system: amd64 dualcore
> again, 2 GB ram, r8169 onboard NIC, e100 pci-slot NIC. Now booting
> 2.6.20.4 and even 2.6.18-4-k7 (the debian kernel) with IOAPIC eabled
> seems to work, meaning the box is up since yesterday evening and
> interrupts are shared. Not equally, but still:
>
> # cat /proc/interrupts
> CPU0 CPU1
...
> 16: 157 575579 IO-APIC-fasteoi eth0
> 17: 3812553 1 IO-APIC-fasteoi eth1
...
Yes! Nobody can deny they are shared. It's a miracle they
don't lockup now!
> While this is a good thing, we now have different problems: our 2nd sata
> drive is not usable any more, but we again we doubt hardware problems,
> because this disk has been replaced already back in the old box...
>
> but yes, this seem to be different problems, for the curious among
> you I've put details here: http://nerdbynature.de/bits/2.6.20.4/db2/
I don't want to waste your time for experiments, so don't
feel obliged to respond or try this all, but here are
some impressions - what I'd do:
- these disk errors look serious and there is no reason
to try anything else without removing such disk and
testing it in some other place,
- the configs are changed, but they sometimes include many
"risky" options like: X86_MCE, HOTPLUG, ACPI_BATTERY,
ACPI_BUTTON, ACPI_PROCESSOR, ENABLE_MEMORY_HOTPLUG etc.;
I doubt you need IDE at all: probably SATA_VIA and PATA_VIA
should be enough for your disks; with such problems I'd start
with absolute minimum - and no drivers for other models
(BTW - maybe I'm wrong, but isn't AMD64 MK-8?),
- if, with some config, a lockup is expected soon, I'd
turn off any watchdogs, turn on many debugging - e.g.
lockdep, and try to wait and get some oops during a lockup
(sometime it needs a few minutes, sometime SYSRQ is helpful);
without this you could never be sure it'll work or your
hardware would work at half speed with unnecessarily
turned off options.
> Thanks to all who have replied,
And I thank you for cooperation and interesting problems.
But I doubt anybody here is satisfied with anything but:
"it's working" (and your hardware doesn't look so special
it shouldn't work).
Cheers,
Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
