On Tue, 03 Feb 2009 12:58:36 -0500
Sam Ruby <rubys@xxxxxxxxxxxxxxxx> wrote:
Andrew Morton wrote:On Thu, 22 Jan 2009 08:37:01 -0500 Sam Ruby <rubys@xxxxxxxxxxxxxxxx> wrote:My understanding is that APCI and APIC are two different things.
Hardware summary: http://tinyurl.com/ap79raJoin the ever-growing noapic club :(
APIC details: http://intertwingly.net/stories/2009/01/22/
Note acpidump.err: Wrong checksum for OEMB!
Messages on boot using Intrepid, Jaunty Alpha 3, or Fedora 10:
[ 0.296001] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
[ 0.296001] Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with apic=debug and send a report. Then try booting with the 'noapic' option.
[ 0.296001]
Able to get past this issue using "noapic", at which point things mostly work,
I assume this is an ACPI problem. Or at least, a BIOS problem which
ACPI can solve for us.
They sure are. But it is ACPI which communicates with the BIOS to tell
the kernel about the APIC, hwo it's wired up, etc.
Although in this case it looks like the problem might be with the
mp-bios tables, which ACPI does not handle. In which case it would be
core x86 code which will have to fix this up, not ACPI.
Did you try updating the BIOS?
I see no messages to /var/log/messages while doing the following (which involves rsync'ing a 2618793984 byte file from an NTFS to ext3 drive on the same machine:but rsync of large iso images result in corrupt files. Able to copy those same files using Vista on the same machine, or using Hardy on another machine. This problem may not be related to the above, but it seems plausible to me that this might be an interrupt issue.Yes, it might be unrelated. There are no kernel messages when it happens?
rubys@rubix4:~/tmp$ rsync /mnt/shared/windows7_7000.iso .
rubys@rubix4:~/tmp$ openssl md5 windows7_7000.iso
MD5(windows7_7000.iso)= 953b9ac92d58f5edef525004bcce048d
rubys@rubix4:~/tmp$ rsync /mnt/shared/windows7_7000.iso .
rubys@rubix4:~/tmp$ openssl md5 windows7_7000.iso
MD5(windows7_7000.iso)= 695328ef1280708eb73303656f6ef0b2
Once again, I'm talking about apic not acpi... does this advice still hold?memtest86+ runs clean.It'd be best to raise a report against ACPI?BIOS (I think) at
Quite willing to invest time in installing kernels or distributions on fresh hard drives, run tests, obtain debug information, and report back.
More background here: http://intertwingly.net/blog/2009/01/20/noAPIC
Not subscribed, but will actively monitor the web archives for this mailing list for the next several days.
bugzilla.kernel.org, please.
Not sure. Perhaps platform_i386/platform_x86_64 would be correct.
Can the x86 maintainers please advise?