Re: Corruption in 2.1.106

J. Maynard Gelinas (maynard@jmg.com)
Fri, 19 Jun 1998 12:24:20 -0300


HW: Tyan 1662D + Dual PPRO, S3/968 video, NCR Symbios PCI SCSI (53C8xx),
Intel EtherExpress 16 ISA, Mad 16 sound ISA. SW: RH 5.1

[snip]

> fsck just checked to see if the file-system was dismouted properly.
> You need to (f)orce a file-system check.
>
> # fsck -f /dev/sda7

As embarrassing as it is to realize that I _should_ have double checked
something this silly before posting to linux-kernel, the fact is that I've made
an even worse mistake I want to clear up. For the last several days I've been
claiming 2.1.106 as 'the most stable 2.1 SMP kernel I've seen yet' without
double checking /proc/cpuinfo. D'OH!

I don't know if the ac2 patch modified the top level Makefile to comment
out SMP = 1, or if 2.1.106 shipped to compile uni by default.... (I seem to
remember previous 2.1 kernels shipping with SMP support in the Makefile). Oh
well! Fact is I compiled a uniprocessor 2.1.106+ac2 and then blindly
proclaimed it SMP safe. Jeesh, I feel stupid.

Last night I realized my mistake after running xosview and double checking
the Makefile, then immediately recompiled for SMP support. Well, the
networking problems I've been seeing since 2.1.89 came back in full force...
networking support drops out intermittently, requiring that I manually down and
up the interface to bring back networking. Don't know if other folks are
seeing this... it may be specific to the EtherExpress 16 driver.

I just wanted to clarify this because sending the list bad data on a
development kernel can have bad long term consequences for the linux community
as a whole. I apologize for any misunderstandings.

J. Maynard Gelinas

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu