Re: [APIC] Kernel panic, rsync corruption, intel q8200, 2.6.28-rc8

[Andrew Morton <akpm@linux-foundation.org>]

On Tue, 03 Feb 2009 12:58:36 -0500
Sam Ruby <rubys@intertwingly.net> wrote:

> Andrew Morton wrote:
> > On Thu, 22 Jan 2009 08:37:01 -0500 Sam Ruby <rubys@intertwingly.net> wrote:
> > 
> >> Hardware summary: http://tinyurl.com/ap79ra
> >> 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,
> > 
> > Join the ever-growing noapic club :(
> > 
> > I assume this is an ACPI problem.  Or at least, a BIOS problem which
> > ACPI can solve for us.
> 
> My understanding is that APCI and APIC are two different things.

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?

> >> 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?
> 
> 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:
> 
> 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
> 
> >> memtest86+ runs clean.
> >>
> >> 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.
> > 
> > It'd be best to raise a report against ACPI?BIOS (I think) at
> > bugzilla.kernel.org, please.
> 
> Once again, I'm talking about apic not acpi... does this advice still hold?

Not sure.  Perhaps platform_i386/platform_x86_64 would be correct.
Can the x86 maintainers please advise?