Kernel 2.6.30-rc6 (generic *.deb packaging) (Page 2 of 2)

Ah, the new b/g/n router/switch/ap works -
The old b router/switch/ap works -
The problems I at first blamed on the kernel are, instead, this Ubuntu "network-manager" thingy
that seems to insist on erasing my /etc/resolv.conf file.
Dummy utility - just because I turn off the Wifi does not mean the DNS server address needs to be erased!
After all - I still have the wired connection.
With both wired/wireless up - the Cloudbook has two addresses 192.168.0.48 and 192.168.1.101 (correct) -
and the routing table shows 192.168.0.4 as the gateway for either interface (correct) -
take down either link - ah, so - I guess the folks at Ubuntu didn't test that case. 

Looks like nobody on the LKML is willing to even touch that backtrace with a ten-foot pole..

Yea, hack out that code you got on stone tablets. Maybe that'll save us from our current digital ailment.

It's all good, Dijkstra's algorithm was written in 1959, and we use it for today's switch hardware! So, old code is new code.

Yea, network switch hardware. In forms of spanning tree protocols, you assign link costs in the network topology to force the router network to 'converge' to a specific set of paths that are preferred by the network administrator, which is usually the path with the least switch hops or overall lowest latency.

I'm pretty new school (I'm only 24). Hopefully this will give me a little more experience with kernel-level voodoo. I do mostly HPC and sysadmin stuff, so hardware driver issues are pretty foreign to me.

What a pain - Could not find any  '*_under_mask' primitives in the kernel.
Since I wanted to use atomic operations rather than locks. . .  I get to write my own.
- - - -
Which lead me to examining the existing atomic (asm) primitives - -
Whoot!  Whoot!
Stumbled on in the code: 32bit, x86, Uni-processor atomic operations are broken!!!
See: arch/x86/include/asm/alternative.h lines 1-39 (The only place LOCK_PREFIX is defined).

#else /* ! CONFIG_SMP */
#define LOCK_PREFIX ""
#endif

The 32-bit, x86 processor requires a single byte instruction prefix to make the
processor issue a back-to-back, read/write cycle.

I assume that I know nothing about the code - so I look everything up -
The plan was to make a modified version of the existing atomic ops (only under mask) -
Which led me to looking up "LOCK_PREFIX" the first time I saw it -
I *know* what it should be - but just in case the name was mis-leading. . .

diff --git a/arch/x86/include/asm/alternative.h b/arch/x86/include/asm/alternative.h
index f6aa18e..3c790ef 100644
--- a/arch/x86/include/asm/alternative.h
+++ b/arch/x86/include/asm/alternative.h
@@ -35,7 +35,7 @@
                "661:\n\tlock; "

 #else /* ! CONFIG_SMP */
-#define LOCK_PREFIX ""
+#define LOCK_PREFIX "\n\tlock; "
 #endif

 /* This must be included *after* the definition of LOCK_PREFIX */

Posted to the LKML bit-bucket - -
Now I can go back to re-inventing a ring-buffer. 

It has already been "shot down" by an "Intel Expert" -

I do not intend to do anything other than post a notice.
Dealing with LKML is too time invasive.

But I already built and tested the 09130 configuration with that patch -
Now we get a clean "stop" rather than strange error message loops.

I am tempted to respond with a link to the technical manual page -
specially since the "expert" is using an "intel.com" e-mail address. 

Thanks, but not a problem.  Alan Cox has not made a comment.
I recognize most of the names that have made a comment.
- - - -
Doing my best to not let this burn up working time, I gave them
the link to the technical reference, chapter and verse.  Now NMP.

Today's repository head is up at the usual place as:

linux-2.6.30-rc6-ce1200v-09143_2.6.30-rc6-ce1200v-09143-22_i386.deb

and friends.

This build has zip, zero, nada local patches.
Repository HEAD was at: commit 2528ed119b8f4fc553f9d1e65719ae183ffa97f4
when the build was made.

Configuration comments:
This is based on the -09130 build, with the known, significant options:
*) No cpufreq control - this is a fixed-speed (1/2 speed, 600Mhz) kernel.
*) No MSI support - known to provide better graphic/audio/network throughput with less cpu load.
*) Kernel message buffer at 2^15 - the 2^17 setting has been shown not suitable for my testing.
This is just a work-around until I complete a local version of kernel/printk.c suitable for load testing.
*) Padlock drivers are modules, you will have to load them - a testing convenience.
*) USB drivers are modules, to force the correct order by listing in /etc/initramfs-tools/modules.

This build has only been playing for 1/2 hour, but is looking good so far.
Soft Rock only today - don't want to shock it.

Edit:
That one only lasted 45 minutes.  Phooey.

Edit 2:
Also running this build on the HP-2133 (C7-M/CN896) just for laughs. . .
So far, only the expected problem with not having the Broadcom firmware loaded . . .
I killed off Network-Manger in user space so SSB would stop puking in the dmesg buffer.
** But I didn't build it for this machine, just F.L. it even boots! **

= = = =
Next - a 09143lk - with a local patch to over-ride the suppression of the lock prefix on atomic ops.

Edit 3:
The -09143lk (-09143 with atomic prefix set to "lock" instruction) -
Built and running on the Cloudbook - only been up about a 1/2 hour - will post RSN.

The -09143 still running on the HP-2133 - 2 1/2 hours - almost long enough to be a significant finding.

Edit 4:
The -09143lk files are posted.

HP-2133 (C7-M/CN896) - 09143 - No results - Still up - 3 1/2 hours.
Cloudbook (C7-M/CX700) - 09143 - 45 minutes.
Cloudbook (C7-M/CX700) - 09143lk - No results - Still up - 1 1/2 hours.

Edit 5:

HP-2133 (C7-M/CN896) - 09143 - No results - Still up - 6 hours.
A "personal best" for 2.6.30 on VIA hardware.

Cloudbook (C7-M/CX700) - 09143 - 45 minutes.
Cloudbook (C7-M/CX700) - 09143lk - Partial results - Still up - 4 hours.

Sometime recently, the echi (USB-2.0) driver went into its failure loop
but the kernel lived, and the music plays on (less the external mouse).
I think I will put it out of its misery now and take some time off myself.

Last edited by mikez (2009-05-23 2:45:52 pm)

Installed the 09143lk. It took two reboots to manage to download, install, generate the initrd, and edit the GRUB conf. Being that the laptop hasn't died yet in the process of writing this forum post, that's exceedingly good news. I'll tell you the runtime that I can get this thing to with normal usage. Perhaps additional information from another VIA chipset will convince the LKML to consider your local patch seriously.

It is clear that you probably lost the keyboard, and I assume the touchpad.
But was it locked?  Or did it just have a driver to the external devices fail?

Ways to tell - have something that updates on the screen - like an analog clock.
Have sound playing -
Have a remote session logged in -

In my last edit, I mentioned that on mine, the echi_hcd driver got into a loop,
flooding the message buffer - - - but with the -09143lk it just killed the driver;
not the machine.
I consider this as progress in the trouble shooting.
Not an answer yet, but progress.

I think the usb driver troubles are an error in its logic, haven't looked yet.

There are drivers for the VIA USB-2.0 controller in powerpc and (mips/arm?) -
So there does exist worked specific examples to compare with the generic driver.
Any "connect" or "disconnect" of a USB device will knock it out of its loop -
the driver will dump stack and exit, but the machine lives on.

But thanks for checking.

I keep two (more often three) manual grub stanzas in the config file - -
With at least one of them set to the "current best" - just for the purpose of servicing the machine.
Until yesterday, it has been the -09130 build, but now will keep the -09143lk as my "rescue" kernel.
- - - -
Linus has tagged an -rc7 now - I will check how much different it is than yesterday's build.
It may not be a significant difference.

Edit:
The -rc7 has had the pci code diddled - it *should* not effect us, unless using Samba or iSCSI - -
Just the same, will re-build yesterday's configurations as the first of the -rc7 series.
Will also start a new thread for -rc7 - - some people are watching by the rss feed.