Message-id: <200901291034.27150.gene.heskett@gmail.com>
Date:	Thu, 29 Jan 2009 10:34:27 -0500
From:	Gene Heskett <gene.heskett@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.29-rc3

On Wednesday 28 January 2009, Linus Torvalds wrote:
>It's out there, and while it's a bit larger than I'd wish for, that size

Unforch, its not ready for prime time here.

1. In my buildit script, I copy the .config(s) from the defined $oldsrc tree 
to a safe place.  This includes the 'makeit' script.
2. I move the $src tree out of the way
3. Unpack new $src tree.
4. rename $src tree to $newversion, rename the $src.old back to $src
5. cd to $newversion
6. Copy all the .configs saved previously to this tree
7. apply the patch(plural if required)
8. make oldconfig
9. make xconfig (in case I want to change something)
exit

Then I cd to the new tree, and edit 'makeit' to fix its $VER, then
#> time ./makeit
which does everything but edit grub.conf for me.

It included all the reiserfs stuff I don't use, and pitched a fit over the 
includes
It skipped all the network hardware drivers so I had no network.

I redid the .config copying by hand, reran a make oldconfig by hand, and this 
time it worked although the make bzimage stage was still very noisy.  And I 
had a network when I rebooted to that version.

dmesg however was full of squawks (its attached) so I rebooted back to 
2.6.28.2.  Unforch the reboot killed the ethernet PHY's, so I had to crawl 
under the desk, pull the power and net cables, and go get a cuppa and check 
the weather (its snowing, yet, still, 3 days now about 40% of the time)
before coming back in and plugging everything in and tapping the power switch.

I'm getting smarter though, the next time I want to get out of a boot that 
isn't stable, I'll just tap the hardware reset, its a heck of a lot easier on 
hard drives.

The first squawk is caused apparently by my bios, that is in fact fixed if I 
update to the most recent, but that one cannot be used in the same machine as 
a stable kernel, its not in its vocabulary.  Support from ASUS is 
non-existent, I have sent several messages up the pipeline to them, with no 
response in over 60 days now.

Since apparently (see the dmesg) that first mtrr related bios wrinkle is fixed 
by the workaround, I see no valid reason to mark the system as 'Tainted' 
because of it, but it is.  What linux calls a Bios flub-up may be true, but 
once its 'fixed' with the older bios, the machine is rock solid.  The newer 
bios version doesn't need the fixup, and its uptimes range from 1 hour down 
to about the time x gets init'ed, sometimes even before, I have see it hang 
in the bootup, tap the hardware reset and it works ok for maybe an hour next 
time.

The next one (Oops/Bug) looks to be something in the cx88 code, which it seems 
has been changed since 2.6.28.

I also note that 2.6.28 doesn't have to do a workaround for reversed MAC's, 
also noted in this dmesg.

All in all, not ready for prime time use here, particularly when I want to 
reboot and have to use the hardware reset to do it if I don't want the MCP55 
ethernet ports turned off in a manner that requires this full powerdown reset 
stuff to recover.

That tends to take the fun out of playing the canary in the coal mine here.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
What does education often do?  It makes a straight cut ditch of a
free meandering brook.
		-- Henry David Thoreau

View attachment "dmesg-2.6.29-rc3" of type "text/plain" (56452 bytes)

Powered by blists - more mailing lists