applet mcelog? [was: Re: patch: unzip succeeds with CRC errors]

[Bernhard Fischer]

On Wed, Mar 29, 2006 at 10:33:26AM -0500, Rob Landley wrote:
>On Wednesday 29 March 2006 2:57 am, Bernhard Fischer wrote:
>> On Tue, Mar 28, 2006 at 04:56:04PM -0500, Rob Landley wrote:
>> >On Tuesday 28 March 2006 11:28 am, Bernhard Fischer wrote:
>> >> On Tue, Mar 28, 2006 at 10:24:39AM -0500, Rob Landley wrote:
>> >> >On Monday 27 March 2006 1:58 pm, Paul Fox wrote:
>> >> >
>> >> >the user.  If that happens now, you have bad memory without ECC or the
>> >> >ability to catch a machine check exception.  Has anybody actually
>> >> > _seen_ this
>> >>
>> >> apropos... Do we want to have an mcelog applet in busybox?
>> >
>> >How big is it and how hardware-specific is it?
>>
>> The full binary (e.g. on SuSE) is:
>> # size $(which mcelog)
>>   text    data     bss     dec     hex filename
>>   12126    1896     264   14286    37ce /usr/sbin/mcelog
>>
>> Which also includes dmidecode, i think.
>
>So 14k.  On the chunky side, but not egregious.

Yes. That'd be the non-busybpx'ified version.
>
>> wrt hardware-specifics of mcelog:
>> It (optionally?) uses DMI to find out stuff about the hardware (this can
>> be a separate applet, dmidecode, which is handy, too).
>> mcelog looks quite hardware-specific ATM, i.e. it currently supports
>> p4 and k8 compatible machines.
>
>So not relevant to ppc, mips, arm, sparc, or even most of the actual x86 chips 
>used in the embedded world (via samuel and such)?

Doesn't look like for ppc et al, not sure about the x86 compatible
chips.

Since linux-2.6 doesn't decode MCEs for us anymore, a userspace applet
is currently the only way to decode the kernel's buffer where it put's
the recorded Machine Check Exceptions.
>
>> The dmidecode applet is potentially useful on anything that has a DMI
>> block, so may be useful on a wider variety of machines. I'm not sure
>> which integrators/vendors on non-x86 compatible arches do support DMI
>> currently. A quick grep turns up mips, ppc, didn't look closely, though.
>
>Still, that's a plus.
>
>Yeah, I suppose I can see it, if we can get both applets for that 14k.  Could 
>I see the patch before it goes in, though?

Sure. Haven't even started, though, so no timeframe for this.
>
>We might want to add a hardware menu.
>
>> >I'm a little uncomfortable with the "linux32 and linux64" applets just
>> > because they're so hardware-specific, although I do see the need for
>> > them.  (Speaking
>>
>> I don't see anything hardware-specific in linux32 and linux64.
>> It just sets the personality (AFAICS exec_domain.c::__set_personality()).
>>
>> >of which, are those _just_ x86_64, or are they also PPC32/64 perhaps?)
>>
>> There is PER_LINUX and PER_LINUX32. Again, i don't see anything which is
>> particularily hardware-dependant there, it's a syscall. YMMV.
>>
>> So, what is it that makes you uncomfortable with setarch?
>
>I'm not uncomfortable enough to suggest it be removed or anything.  It's fine.  
>There's just something unresolved about it.
>
>Partly it's "64 bit busybox.  Is that our _job_?"  I'm still a bit surprised 
>that the answer is "yes". :)

Remember that we're used in initramfs and initrd on 64bit boxes and also
as rescue swiss army knife on 64bit boxes.