The latest version of the -mjc branch has been released. It is
available at:
ftp://ftp.kernel.org/pub/linux/kernel/people/mjc/linux-2.4/patch-2.4.18-pre9-mjc2.bz2
--------------------------------------------------------------
[ A great deal of patches have been removed, in interest of keeping this
branch as close to the standard 2.4 series as possible.]
[ I am now using bitkeeper, and my bk tree is available at
bk://ohdarn.net/linux-mjc. it is cloned from linus's 2.4 tree so
please, please, please clone from him and pull from me. ]
2.4.18-pre9-ac3 (Alan Cox et al)
Reverse Mapping VM Patch #12e (Rik van Riel)
O(1) Scheduler K3 (Ingo Molnar)
IRQrate (IM)
Preemptible Kernel Patch (Robert M. Love)
Break Selected Locks (RML)
Netdev-Random (RML)
Fibonacci Hashing: (prime for 32-bit) (William Lee Irwin III)
-Inode hash (WLI)
-Page cache hash (WLI)
-UID hash (dynamic) (WLI)
-PID hash (dynamic) (WLI)
OOM trigger increase (WLI)
Change VM policy to overcommit (WLI)
Page aging adjustments (WLI)
Netfilter Header Order Fix (WLI)
proc_pid_statm() cleanup (WLI)
task_nice export (WLI)
Bootmem Rewrite (WLI)
Mountcache size reduction (WLI, Andi Kleen, Al Viro)
Slab search optimization (Momchil Velikov)
Radix tree page cache search (MV)
UserMode Linux (Jeff Dike)
Loop Mounting Deadlock Fix (Andrew Morton)
Read Latency Fix #2 (AKPM)
CDDA DMA fix (AKPM)
82Cxx devexit (AKPM)
make request (AKPM)
slab cache estimate optimization (Balbir Singh)
x86 Syscall stall fix (Alexander Khripin)
Bdflush parameters (Stephen van der Krantz)
AMD Elan Updates (Robert Schwiebel)
SiS5513 updates (20020128_1) (Daniel Bouton)
lm_sensors (lm_sensors team)
Verbose BUG() (Hugh Dickins)
Xconfig help fix (Olaf Diestche)
V4L2 (V4L2 Team)
SCSI CD Changer (?)
------
Michael J. Cohen
OhDarn.net
> Reverse Mapping VM Patch #12e (Rik van Riel)
Except that Documentation/vm/Changelog.rmap still reports...
rmap 12a:
- fix the compile warning in buffer.c (me)
- fix divide-by-zero on highmem initialisation DOH! (me)
- remove the pgd quicklist (suspicious ...) (DaveM, me)
This is confusing to people. is 12e applied??
--
Andrew Hatfield
SecureONE - http://www.secureone.com.au/
President - South East Brisbane Linux Users Group http://www.seblug.org/
Kernel work available at http://development.secureone.com.au/kernel/
> SiS5513 updates (20020128_1) (Daniel Bouton)
Erm, make that Lionel Bouton. My apologies. :)
-----
Michael Cohen
OhDarn.net
On Wed, Feb 13, 2002 at 11:58:28PM -0500, Michael Cohen wrote:
> [ I am now using bitkeeper, and my bk tree is available at
> bk://ohdarn.net/linux-mjc. it is cloned from linus's 2.4 tree so
> please, please, please clone from him and pull from me. ]
Just in case people need a reminder, you would do this:
bk clone bk://linux.bkbits.net/linux-2.4
cd linux-2.4
bk pull bk://ohdarn.net/linux-mjc
This means you use our bandwidth for the main clone and then only take
updates from Michael.
Michael, if you want to stash a mirror here, that's easy, take a look at
http://www.bitkeeper.com/Hosted.html
it should be pretty straight forward.
Cheers,
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
got this problem when applying 2.4.18-pre8-mjc to 2.4.18-pre8 to 2.4.17 as
well as newly released 2.4.18-pre8-mjc2
filemap.c: In function `__find_page_nolock':
filemap.c:404: structure has no member named `next_hash'
Not sure if this is related to Rik's rmap patch or Ingo's O(1) Scheduler
patch (or again, something else entirely)
your mjc2 patch contains....
patch-2.4.18-pre9-mjc2:- struct page *next_hash; /* Next page
sharing our hash bucket in
patch-2.4.18-pre9-mjc2:- struct page **pprev_hash; /*
Complement to *next_hash. */
which modifes linux/include/linux/mm.h
if i comment out the line in filemap.c it continues to compile... until
problems with ip.h (more to come)
--
Andrew Hatfield
SecureONE - http://www.secureone.com.au/
President - South East Brisbane Linux Users Group http://www.seblug.org/
Kernel work available at http://development.secureone.com.au/kernel/
Correct fix is to remove __find_page_nolock entirely.
On Thu, 2002-02-14 at 00:46, Andrew Hatfield wrote:
> got this problem when applying 2.4.18-pre8-mjc to 2.4.18-pre8 to 2.4.17 as
> well as newly released 2.4.18-pre8-mjc2
>
> filemap.c: In function `__find_page_nolock':
> filemap.c:404: structure has no member named `next_hash'
>
> Not sure if this is related to Rik's rmap patch or Ingo's O(1) Scheduler
> patch (or again, something else entirely)
>
> your mjc2 patch contains....
> patch-2.4.18-pre9-mjc2:- struct page *next_hash; /* Next page
> sharing our hash bucket in
> patch-2.4.18-pre9-mjc2:- struct page **pprev_hash; /*
> Complement to *next_hash. */
>
> which modifes linux/include/linux/mm.h
>
>
> if i comment out the line in filemap.c it continues to compile... until
> problems with ip.h (more to come)
>
> --
>
> Andrew Hatfield
> SecureONE - http://www.secureone.com.au/
> President - South East Brisbane Linux Users Group http://www.seblug.org/
>
> Kernel work available at http://development.secureone.com.au/kernel/
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Thu, Feb 14, 2002 at 03:46:53PM +1000, Andrew Hatfield wrote:
> got this problem when applying 2.4.18-pre8-mjc to 2.4.18-pre8 to 2.4.17 as
> well as newly released 2.4.18-pre8-mjc2
> filemap.c: In function `__find_page_nolock':
> filemap.c:404: structure has no member named `next_hash'
> Not sure if this is related to Rik's rmap patch or Ingo's O(1) Scheduler
> patch (or again, something else entirely)
> your mjc2 patch contains....
> patch-2.4.18-pre9-mjc2:- struct page *next_hash; /* Next page
> sharing our hash bucket in
> patch-2.4.18-pre9-mjc2:- struct page **pprev_hash; /*
> Complement to *next_hash. */
> which modifes linux/include/linux/mm.h
> if i comment out the line in filemap.c it continues to compile... until
> problems with ip.h (more to come)
It contains the ratcache by Momchil Velikov which eliminates the need for
those fields within struct page.
This is not the fix you're looking for...
Cheers,
Bill
On Thu, Feb 14, 2002 at 12:09:56AM -0500, Michael Cohen wrote:
> > SiS5513 updates (20020128_1) (Daniel Bouton)
> Erm, make that Lionel Bouton. My apologies. :)
>
No problem.
But 20020128_1 has buggy chip capability detection code for most chipsets.
20020214_1 solves this (mostly, it doesn't work yet for chip not in the in-driver
database).
LB.
On Wed, 13 Feb 2002, Michael Cohen wrote:
> 2.4.18-pre9-ac3 (Alan Cox et al)
...
> lm_sensors (lm_sensors team)
Hum, the last time I merged that stuff into my own kernel, the
patch-generator that they ship did not include all of the drivers I
needed. Also, I'm missing i2c from your patch list. Is that intentional
or is the i2c patch not needed? Which lm_sensors version did you merge?
--
Matthias Andree
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." Benjamin Franklin
> > lm_sensors (lm_sensors team)
>
> Hum, the last time I merged that stuff into my own kernel, the
> patch-generator that they ship did not include all of the drivers I
> needed. Also, I'm missing i2c from your patch list. Is that intentional
> or is the i2c patch not needed? Which lm_sensors version did you merge?
Be very careful merging lm_sensors. Incorrect use of it is a wonderful
way to do things like totally destroy (back to factory) an ibm thinkpad.
Thats why I've always stayed clear of it
Alan Cox wrote:
>>>lm_sensors (lm_sensors team)
>>>
>>Hum, the last time I merged that stuff into my own kernel, the
>>patch-generator that they ship did not include all of the drivers I
>>needed. Also, I'm missing i2c from your patch list. Is that intentional
>>or is the i2c patch not needed? Which lm_sensors version did you merge?
>>
>
>Be very careful merging lm_sensors. Incorrect use of it is a wonderful
>way to do things like totally destroy (back to factory) an ibm thinkpad.
>
Well that is only one single sensor driver... The rest work's rather nicely.
Larry McVoy wrote:
> On Wed, Feb 13, 2002 at 11:58:28PM -0500, Michael Cohen wrote:
>> [ I am now using bitkeeper, and my bk tree is available at
>> bk://ohdarn.net/linux-mjc. it is cloned from linus's 2.4 tree so
>> please, please, please clone from him and pull from me. ]
>
> Just in case people need a reminder, you would do this:
>
> bk clone bk://linux.bkbits.net/linux-2.4
> cd linux-2.4
> bk pull bk://ohdarn.net/linux-mjc
oscar% bk clone -q linux-2.4 linux-mjc-edt
oscar% cd linux-mjc-edt
oscar% bk pull bk://ohdarn.net/linux-mjc
Nothing to pull from bk://ohdarn.net/linux-mjc
oscar%
Where linux-2.4 is a local clone of linux-2.4. Why
does it find nothing to pull ?
TIA
Ed Tomlinson
On Wed, Feb 13, 2002 at 11:58:28PM -0500, Michael Cohen wrote:
> The latest version of the -mjc branch has been released. It is
> available at:
> ftp://ftp.kernel.org/pub/linux/kernel/people/mjc/linux-2.4/patch-2.4.18-pre9-mjc2.bz2
> --------------------------------------------------------------
> [ A great deal of patches have been removed, in interest of keeping this
> branch as close to the standard 2.4 series as possible.]
> [ I am now using bitkeeper, and my bk tree is available at
> bk://ohdarn.net/linux-mjc. it is cloned from linus's 2.4 tree so
> please, please, please clone from him and pull from me. ]
>
>
> 2.4.18-pre9-ac3 (Alan Cox et al)
> Reverse Mapping VM Patch #12e (Rik van Riel)
Here's rmap12f:
I'm not sure I murged mm/bootmem.c correctly, can someone take a look?
diff -ur 2.4.18-pre9-mjc2/Makefile 2.4.18-pre9-mjc2-rmap12f/Makefile
--- 2.4.18-pre9-mjc2/Makefile Thu Feb 14 19:09:54 2002
+++ 2.4.18-pre9-mjc2-rmap12f/Makefile Thu Feb 14 19:08:52 2002
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 4
SUBLEVEL = 18
-EXTRAVERSION = -pre9-mjc2
+EXTRAVERSION = -pre9-mjc2-rmap12f
KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
diff -ur 2.4.18-pre9-mjc2/fs/buffer.c 2.4.18-pre9-mjc2-rmap12f/fs/buffer.c
--- 2.4.18-pre9-mjc2/fs/buffer.c Thu Feb 14 19:09:58 2002
+++ 2.4.18-pre9-mjc2-rmap12f/fs/buffer.c Thu Feb 14 18:58:12 2002
@@ -2991,6 +2991,7 @@
spin_lock(&lru_list_lock);
if (!write_some_buffers(NODEV) || balance_dirty_state() < 0) {
+ run_task_queue(&tq_disk);
interruptible_sleep_on(&bdflush_wait);
}
}
diff -ur 2.4.18-pre9-mjc2/include/linux/mmzone.h 2.4.18-pre9-mjc2-rmap12f/include/linux/mmzone.h
--- 2.4.18-pre9-mjc2/include/linux/mmzone.h Thu Feb 14 19:10:01 2002
+++ 2.4.18-pre9-mjc2-rmap12f/include/linux/mmzone.h Thu Feb 14 18:58:12 2002
@@ -161,6 +161,21 @@
extern pg_data_t contig_page_data;
+/**
+ * for_each_pgdat - helper macro to iterate over all nodes
+ * @pgdat - pg_data_t * variable
+ *
+ * Meant to help with common loops of the form
+ * pgdat = pgdat_list;
+ * while(pgdat) {
+ * ...
+ * pgdat = pgdat->node_next;
+ * }
+ */
+#define for_each_pgdat(pgdat) \
+ for (pgdat = pgdat_list; pgdat; pgdat = pgdat->node_next)
+
+
/*
* next_zone - helper magic for for_each_zone()
* Thanks to William Lee Irwin III for this piece of ingenuity.
diff -ur 2.4.18-pre9-mjc2/kernel/ksyms.c 2.4.18-pre9-mjc2-rmap12f/kernel/ksyms.c
--- 2.4.18-pre9-mjc2/kernel/ksyms.c Thu Feb 14 19:10:02 2002
+++ 2.4.18-pre9-mjc2-rmap12f/kernel/ksyms.c Thu Feb 14 19:01:03 2002
@@ -251,6 +251,7 @@
EXPORT_SYMBOL(__pollwait);
EXPORT_SYMBOL(poll_freewait);
EXPORT_SYMBOL(ROOT_DEV);
+EXPORT_SYMBOL(__find_get_page);
EXPORT_SYMBOL(find_get_page);
EXPORT_SYMBOL(find_lock_page);
EXPORT_SYMBOL(grab_cache_page);
diff -ur 2.4.18-pre9-mjc2/mm/bootmem.c 2.4.18-pre9-mjc2-rmap12f/mm/bootmem.c
--- 2.4.18-pre9-mjc2/mm/bootmem.c Thu Feb 14 19:10:02 2002
+++ 2.4.18-pre9-mjc2-rmap12f/mm/bootmem.c Thu Feb 14 19:08:16 2002
@@ -897,13 +897,11 @@
pg_data_t *pgdat = pgdat_list;
void *ptr;
- while (pgdat) {
+ for_each_pgdat(pgdat) {
ptr = __alloc_bootmem_core(pgdat->bdata, size, align, goal);
if(ptr)
return ptr;
-
- pgdat = pgdat->node_next;
}
printk(KERN_ALERT "bootmem alloc of %lu bytes failed!\n", size);
diff -ur 2.4.18-pre9-mjc2/mm/page_alloc.c 2.4.18-pre9-mjc2-rmap12f/mm/page_alloc.c
--- 2.4.18-pre9-mjc2/mm/page_alloc.c Thu Feb 14 19:10:02 2002
+++ 2.4.18-pre9-mjc2-rmap12f/mm/page_alloc.c Thu Feb 14 18:58:12 2002
@@ -627,14 +627,11 @@
{
unsigned int sum;
zone_t *zone;
- pg_data_t *pgdat = pgdat_list;
sum = 0;
- while (pgdat) {
- for (zone = pgdat->node_zones; zone < pgdat->node_zones + MAX_NR_ZONES; zone++)
- sum += zone->free_pages;
- pgdat = pgdat->node_next;
- }
+ for_each_zone(zone)
+ sum += zone->free_pages;
+
return sum;
}
@@ -643,10 +640,10 @@
*/
unsigned int nr_free_buffer_pages (void)
{
- pg_data_t *pgdat = pgdat_list;
+ pg_data_t *pgdat;
unsigned int sum = 0;
- do {
+ for_each_pgdat(pgdat) {
zonelist_t *zonelist = pgdat->node_zonelists + (GFP_USER & GFP_ZONEMASK);
zone_t **zonep = zonelist->zones;
zone_t *zone;
@@ -657,8 +654,7 @@
sum += zone->inactive_dirty_pages;
}
- pgdat = pgdat->node_next;
- } while (pgdat);
+ }
return sum;
}
@@ -666,13 +662,12 @@
#if CONFIG_HIGHMEM
unsigned int nr_free_highpages (void)
{
- pg_data_t *pgdat = pgdat_list;
+ pg_data_t *pgdat;
unsigned int pages = 0;
- while (pgdat) {
+ for_each_pgdat(pgdat)
pages += pgdat->node_zones[ZONE_HIGHMEM].free_pages;
- pgdat = pgdat->node_next;
- }
+
return pages;
}
#endif
diff -ur 2.4.18-pre9-mjc2/mm/vmscan.c 2.4.18-pre9-mjc2-rmap12f/mm/vmscan.c
--- 2.4.18-pre9-mjc2/mm/vmscan.c Thu Feb 14 19:10:02 2002
+++ 2.4.18-pre9-mjc2-rmap12f/mm/vmscan.c Thu Feb 14 18:58:12 2002
@@ -652,6 +652,10 @@
refill_freelist();
+ /* Start IO when needed. */
+ if (free_plenty(ALL_ZONES) > 0 || free_low(ANY_ZONE) > 0)
+ run_task_queue(&tq_disk);
+
/*
* Hmm.. Cache shrink failed - time to kill something?
* Mhwahahhaha! This is the part I really like. Giggle.
> > Be very careful merging lm_sensors. Incorrect use of it is a wonderful
> > way to do things like totally destroy (back to factory) an ibm thinkpad.
> > Thats why I've always stayed clear of it
>
> They deserve it! Shipping hardware that commits suicide on i2c access is
> bad thing (tm).
IBM don't replace machines where you do that. So I suspect you'll have a few
users with very different views on the matter.
Hi!
> > Hum, the last time I merged that stuff into my own kernel, the
> > patch-generator that they ship did not include all of the drivers I
> > needed. Also, I'm missing i2c from your patch list. Is that intentional
> > or is the i2c patch not needed? Which lm_sensors version did you merge?
>
> Be very careful merging lm_sensors. Incorrect use of it is a wonderful
> way to do things like totally destroy (back to factory) an ibm thinkpad.
> Thats why I've always stayed clear of it
They deserve it! Shipping hardware that commits suicide on i2o access is
bad thing (tm).
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Hi!
> > > Be very careful merging lm_sensors. Incorrect use of it is a wonderful
> > > way to do things like totally destroy (back to factory) an ibm thinkpad.
> > > Thats why I've always stayed clear of it
> >
> > They deserve it! Shipping hardware that commits suicide on i2c access is
> > bad thing (tm).
>
> IBM don't replace machines where you do that. So I suspect you'll have a few
> users with very different views on the matter.
Someone should buy thinkpad, destroy it (preferably with CD labeled
Virus 98 or soemthing like that), return, destroy next, return,
destroy next, request money back.
Alternatively make a virus that destroys thinkpads -- should make them
some bad press, too.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
> Someone should buy thinkpad, destroy it (preferably with CD labeled
> Virus 98 or soemthing like that), return, destroy next, return,
> destroy next, request money back.
If you want to get arrested it sounds a great idea. Thats up to you
> Alternatively make a virus that destroys thinkpads -- should make them
> some bad press, too.
A virus to destroy any PC is trivial. Just be thankful nobody has crossed
the really infectious ones with stuff like chernobyl and disk firmware
erasers.
The PC simply is not a secure platform
Hi!
> > Someone should buy thinkpad, destroy it (preferably with CD labeled
> > Virus 98 or soemthing like that), return, destroy next, return,
> > destroy next, request money back.
>
> If you want to get arrested it sounds a great idea. Thats up to you
Huh? They are shipping faulty products. Unless their manual say "you
are only allowed to run windows 95 release 1, Word version 3.71 and
Outlook 17.32 and nothing else, you have handled your computer
properly and its *their* problem.
> > Alternatively make a virus that destroys thinkpads -- should make them
> > some bad press, too.
>
> A virus to destroy any PC is trivial. Just be thankful nobody has crossed
> the really infectious ones with stuff like chernobyl and disk firmware
> erasers.
What did chernobyl do? I've never seen PC damaged beyond
repair. Everyone with a clue has jumper on stuff like flashing, and I
can imagine that opening the case can void your warranty.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
> > If you want to get arrested it sounds a great idea. Thats up to you
>
> Huh? They are shipping faulty products. Unless their manual say "you
> are only allowed to run windows 95 release 1, Word version 3.71 and
> Outlook 17.32 and nothing else, you have handled your computer
> properly and its *their* problem.
You didnt handle it properly. You'll find the old "you cannot damage the
computer" messages vanished about the time of the IBM/AT. You instructed
it to erase critical internal data, so it did.
> What did chernobyl do? I've never seen PC damaged beyond
Erased the bios
> repair. Everyone with a clue has jumper on stuff like flashing, and I
> can imagine that opening the case can void your warranty.
You don't however have a jumper to protect your disk firmware do you...
man, 2002-02-18 kl. 22:39 skrev Alan Cox:
> > > If you want to get arrested it sounds a great idea. Thats up to you
> >
> > Huh? They are shipping faulty products. Unless their manual say "you
> > are only allowed to run windows 95 release 1, Word version 3.71 and
> > Outlook 17.32 and nothing else, you have handled your computer
> > properly and its *their* problem.
>
> You didnt handle it properly. You'll find the old "you cannot damage the
> computer" messages vanished about the time of the IBM/AT. You instructed
> it to erase critical internal data, so it did.
>
> > What did chernobyl do? I've never seen PC damaged beyond
>
> Erased the bios
>
> > repair. Everyone with a clue has jumper on stuff like flashing, and I
> > can imagine that opening the case can void your warranty.
>
> You don't however have a jumper to protect your disk firmware do you...
>
And you don't have a jumper on most laptops I've seen - neither do you
want to disassemble the laptop every time you decide to upgrade the BIOS
(at least I know I don't).
I've also seen lots of PCs that do exactly things like flashing the BIOS
during the first install cycle after you power up. I've even had to
return one because of user intervention (some guy flicked the power
during BIOS upgrade...)
Cheers
Kjartan
Hi!
> > > If you want to get arrested it sounds a great idea. Thats up to you
> >
> > Huh? They are shipping faulty products. Unless their manual say "you
> > are only allowed to run windows 95 release 1, Word version 3.71 and
> > Outlook 17.32 and nothing else, you have handled your computer
> > properly and its *their* problem.
>
> You didnt handle it properly. You'll find the old "you cannot damage the
> computer" messages vanished about the time of the IBM/AT. You instructed
> it to erase critical internal data, so it did.
I asked it to read temperature sensors *then* it commited suicide.
I believe consumer protection laws require manual to be shipped with a
product, and manual should state how you should handle your
computer. Unless they say "never run anything you downloaded", they
should return your machine.
> > repair. Everyone with a clue has jumper on stuff like flashing, and I
> > can imagine that opening the case can void your warranty.
>
> You don't however have a jumper to protect your disk firmware do
> you...
In such case disk should either:
*) have "firmware flasher" part unwritable,
or
*) check signature on whatever it is flashing in, and if it does not
match, refuse to flash it.
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
> > computer" messages vanished about the time of the IBM/AT. You instructed
> > it to erase critical internal data, so it did.
>
> I asked it to read temperature sensors *then* it commited suicide.
No. You load lm_sensors, it does a bus scan and that trashes your eeprom.
Its an lm_sensors problem (but rather hard to avoid when poking around
randomly inside a laptop without a clue what its doing)
> In such case disk should either:
> *) have "firmware flasher" part unwritable,
> or
> *) check signature on whatever it is flashing in, and if it does not
> match, refuse to flash it.
Well they don't.
Hi!
> > > computer" messages vanished about the time of the IBM/AT. You instructed
> > > it to erase critical internal data, so it did.
> >
> > I asked it to read temperature sensors *then* it commited suicide.
>
> No. You load lm_sensors, it does a bus scan and that trashes your eeprom.
> Its an lm_sensors problem (but rather hard to avoid when poking around
> randomly inside a laptop without a clue what its doing)
Okay, so what about adding dmi _white_list to lm_sensors? That should
address your concerns... [It would also be possible to autosetup
temperature offsets/divisors etc.]
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa