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

That's all folks - a new record of 4 hours and 42 minutes.
- - - -
The difference - a 4C degree difference in ambient temperature.
- - - -
How?
For silicon devices, the mobility (at the molecular/ion level) doubles
for each 10C degree increase in temperature.
A 4C degree lower ambient temperature means *about* a 4C degree
decrease in chip temperature.
This is also the background to why a 10C degree increase in your silicon
device halves its life span. 
- - - -
Why?
The echi-hcd driver gets kicked into its re-try loop by a (false) over-current
detection in the integrated hub.
Without data on the chip set internals, I can only guess the over-current sensor
is sensitive to both temperature and current.
Since they normally are.   Also, they are normally thermal compensated to
eliminate the temperature effect.

Does this mean I am going over-temperature the CX700?
Or
The thermal compensation is not correct on the CX700?
Or
The USB driver is mis-detecting a normal (but extreme) reading?

Can't say - not until I get the SMBus driver working so we can read
the CX700 temperatures and voltage.

Meanwhile - I am intentionally *not fixing* the USB driver - I will need
it to test the new nprintk.c under failure conditions. 

Today's effort is posted at the usual place as:

2.6.30-rc7-ce1200v-09145-db.md5
2.6.30-rc7-ce1200v-09145lk-db.md5
config-2.6.30-rc7-ce1200v-09145-db
config-2.6.30-rc7-ce1200v-09145lk-db
linux-2.6.30-rc7-ce1200v-09145-db_2.6.30-rc7-ce1200v-09145-db-27_i386.deb
linux-2.6.30-rc7-ce1200v-09145lk-db_2.6.30-rc7-ce1200v-09145lk-db-28_i386.deb
linux-firmware-image_2.6.30-rc7-ce1200v-09145-db-27_all.deb
linux-firmware-image_2.6.30-rc7-ce1200v-09145lk-db-28_all.deb

This build is the same code base as yesterday's (-09144{,lk}) pair with the addition of
the kernel's lock dependency checking enabled.
Do not be alarmed at slow boot times - that is the lockdep code running self-tests.  Wait.
You can see the results of the testing in dmesg.

Also, keep in mind I am no longer building in the padlock drivers (via-rng is built-in).
You probably need to manual load them (depends on your distro auto-loading setup):

root@cb01:~# modprobe padlock-aes
root@cb01:~# modprobe padlock-sha
root@cb01:~# openssl engine
(padlock) VIA PadLock (no-RNG, ACE)
(dynamic) Dynamic engine loading support

= = = =

I have heard from the author of the SMBus driver - it **is expected to work on CX700**
Will have to give it another try RSN.

Not me!  I was sound asleep the entire time.
The last few builds where announced on LKML in answer to "not providing enough information".
It could be people wget'ting the whole directory, or it could be just a Dreamhost slowdown.
Will take a look at the logs later tonight.  Just glad that the problem fixed itself.
= = = =
There is a driver for the hardware watchdog, it is still "in the shop" at VIA.  Maybe soon.
Same with more technical manuals - they are still on the "release path" at VIA.

Rhetorical question:  How deep will this sh.. become?

Edit:
I should stop my complaining, the output of:
gcc -O2 -S -fomit-frame-pointer ...
Is hard to beat (if the compiler version gets it right, and so far, 4.1.2 does);
even by someone who has been hand coding Intel code since the I4004.
<< I had to brag, just to get myself out of yesterday's funk.>>

Of course, GCC only generates enough of the instruction set to translate source programs.
So hand coding is not completely out of style (although a dying art).

Last edited by mikez (2009-05-26 5:47:42 am)

Still here, still on the job.  Although my time is spent on the re-designed printk.c - -
The general problem has been stirring around in the back of my mind -
= = = =
There is not a lot of information to be gained from a glowing power-on light and a locked machine, but. . .
*) The difference between the up-time of a kernel using the 'lock' opcode in critical areas is about and
order of magnitude; _consistent_
*) Adding the lockdep reporting (and structure changes required) halves the up-time; _consistent_
*) The difference between the system chip sets CX700 and CN896 is significant (no failures on CN896).
= = = =
This sounds very much like a cache coherency or structure alignment on a cache line problem.
The cache is on the processor chip - same in both machines -
The devices that modify memory are on the system chip - different implementations (CX700/CN896) -
Also, half of what makes up the cache coherency controls is on the system chip (the *I/O* making
a change to a memory address has to "know" if the cache line and the memory line are consistent).
= = = =
The above line of thought does not rule out software errors, such as "out of bounds" write errors
(demonstrated by changing the ring-buffer size) or the human error of not using the correct instruction
sequence somewhere (demonstrated by globally changing the LOCK_PREFIX byte).
= = = =
I would be very surprised if the Linux kernel *was not* reporting the problem - - -
It is just a matter of making a bullet-proof message writer so we can read the notice. 

Unknown.
I hard coded the pci_cache_line_size to the processor's cache line size - -
Will see what difference that makes - -
Other than making the machine boot much faster and the music louder.
= = = =
It also looks like our "too slow" disk drive needs to be put on the exception
list for udma/66 so the driver will stop running it at udma/33. 

Question is still pending to VIA-CPU engineering. . .
Have heard back from VIA-CPU engineering on the LOCK_PREFIX usage, quote: "--- use it ---".
= = = =
They (VIA) reports doing some experiments with disabling 'lock' in the cpu - -
doing so breaks a popular, proprietary, operating system.
= = = =
Today's 09147lk-db has just passed its previous record of 2 hours (the -09145lk-db) - - -
Will see how this goes....
= = = =
Got this post typed without it dying, it usually dies when I brag on it.

Build with the 'lock' and the changed cache line size against today's repository head is looking good - -
This is a _variable speed_ kernel with e_powersaver - i2c-viapro also loads - not sure it is working.
= = = =
Will probably build a -09148lkcs tomorrow for posting.  Machine is still running, music playing.
= = = =

Historical note:
A number of years ago, in the HP, PARISC Linux port - - some experimental kernels where built
that forced the linker to place all of the *_lock_* thingies into their own, cache line aligned, section.
Where their access could not in-directly affect other cached data - -
I don't know if that ever made it into the x86 kernel (or even into the parisc kernel) - -
Will check on that for tomorrow's build.
- - - -
Besides, we might get VIA Tech's recommendation on this RSN.
- - - -
At my end of the spectrum (user) and the VIA Tech's engineering department are
of a like mind over the subject of using the 'lock' prefix - members of LKML have a
scattered collection of opinions.
As long as we get an order of magnitude improvement in up-time - - it stays in!

Great! You're making progress!

Try running this against the new kernel with the udma patch and the one without.. I'm curious about the difference:

hdparm -Tt /dev/sda

Last edited by aastaneh (2009-05-27 8:29:42 pm)

Sound (no pun intended - pulse audio uses this) familiar?
http://bugzilla.kernel.org/show_bug.cgi?id=13331
Read comment #5
= = = =
Will check if it is in today's code base, otherwise I will patch it in.

Edit:
Neither the original nor the changed lines of code in the bug
report are in 2.6.30 - - somebody "optimized it" - - I "Un-optimized" it.

Edit 2:
Found some more suspicious things in the cache set-up - -
One was a feature I could option out -
The other I sent a query to VIA Tech about.

If this build has a reasonable up-time, I will post it later today.

Edit 3:
I am going to use this on the HP-2133 (C7-M/CN896) and see if I broke that one. 
And...
The HP doesn't use the same NIC/driver - which may be the difference.

Edit 4:
Made it worse.  Phooey.  Well, at least I know what I will be doing this afternoon.

Edit 5:
The HP-2133 just past the 6 hour up-time mark. Works fine, if you don't need Wifi. 

Last edited by mikez (2009-05-28 1:01:12 pm)

The HP-2133 has been up nearly 12 hours now - no sign of problems.
The Cloudbook up-time is reaching a significant length now (for rc7-git3).
= = = =
This futex service the kernel provides user-space also has a potentially
endless loop (our endless loop?) that can hang if cache/memory/IO
coherency fails.
I plan to add an error exit to that routine tomorrow - we should have
another test build tomorrow. 
Note: I am not going to start at 2:30am tomorrow. 
= = = =
The project than maintains the USB drivers has a bunch of changes
ready, will check those while listen to music tomorrow - Cloudbook music.

Hmm....
The bad:  This thing still has an "up-time limiter" in it, somewhere - - -
The good: I can still test any sanity checker I come up with. 
The interesting: 93 *.deb downloads served in the past week, somebody is watching this. 

Last edited by mikez (2009-05-29 8:14:06 am)