Lost items from Port 2 (flash) in 49G+ (again)
John H Meyers
lost not only my most recent memory backup,
but also my "Nosy" library vanished as well from Port 2,
immediately after I did a RESTORE (I also got "Invalid
Card Data" again on every warmstart since that RESTORE;
doing PINIT cured the "Invalid Card Data"
at the expense of the instant disappearance
of my both last backup and my Nosy library.
All this happened with 210K free IRAM, 41K free ERAM,
and 368K free in flash; it also just occurred
with very fresh batteries installed,
although they became freshened only after
an earlier "low batt" warning.
So it's acting like a sieve which can't hold water.
Any thoughts on what's happening under my hood?
Some other little observations about which I'm curious:
The backup which I'm restoring to 49G+ was actually made
on my 49G emulator (to emulated ERAM and flash),
then recalled to emulator stack, "save object" to PC disk,
and finally transfer via Conn4x to 49G+
Naturally this produces a directory object (not a backup object)
in the 49G user area. After copying this directory
to both ERAM and flash on the 49G, I did an ordinary PGDIR
on the user variable, and I noticed that it took a very long
time to purge -- yes, I thought, that's because the RPL system
has to be very careful about any referenced items, and has to
recurse through the entire subdirectory structure to be sure
that it doesn't cause a TTRM by keeping a reference
to something which is about to be purged.
Then I copied that whole directory back into user memory,
and this time I asked the *Filer* to delete it for me,
rather than using PGDIR -- well, I think that the Filer
deleted that entire directory so fast that it was gone
even before I could release the PURGE menu key :)
How does the Filer manage to do that without worrying at all,
while PGDIR still plows through the slow but sure procedure
which we once thought to be necessary?
Getting back to my first issue,
based on my repetitive experiences with backups and libraries
vanishing from Port 2, I recommend using that SD card slot
all the time -- "don't leave HOME without it" :)
[r->] [OFF]
John H Meyers
(hey, where's Rodney Dangerfield when we need him? :)
After much investigation/experimentation,
I can now produce this bug 100% of the time
on my 49G+ [Version HP49-C, Revision #2.01,
self-test: version 04.01, build 0083],
on hardware of CN402 vintage:
o Archive to a RAM port, e.g. :1:XXXX ARCHIVE
(my typical size is 30K, in case that has any bearing)
o Perform ON+A+F -> NO (to clear the way for a RESTORE)
o Using the Filer, copy the backup back to the empty HOME
(this simulates having just received it from my PC,
as is usually the actual scenario).
o Using the Filer, copy the backup from HOME to port 2 (flash)
o Warmstart via ON+C
Results:
o Occasionally there is a "snowy screen" during copy to flash.
o "Warning: Invalid Card Data" [beep] during warmstart.
o After PINIT, the copied backup has always vanished from port 2.
o Other files (e.g. libraries and/or other previous backups)
may also have vanished from flash port 2.
This is about the only scenario which produces data corruption
(and loss); making innumerable archives directly to port 2 is okay,
as is copying any number of files directly from ports 1 or 3
to port 2, as is copying a native backup object rather than
the directory object remaining from archiving to ports 1 or 2.
Can you reproduce it?
(of course you should have complete SD backup before trying!)
Hope CB is enjoying the good life while at HP :)
[r->] [OFF]
timwe...@gmail.com
> (hey, where's Rodney Dangerfield when we need him? :)
Worms ain't givin him no respect, no respect at all. . . ;-)
I have had the same thing happen ocassionally. I have an install
routine to copy several (4) libraries, one of which is almost the size
of a whole bank. About 2% of the time it seems to hang, and the only
way to get out is popping the battery. In this instances, it seems to
loose some port2 content.
TW
Heiko Arnemann
> Well, it's done it again --
> lost not only my most recent memory backup,
> but also my "Nosy" library vanished as well from Port 2,
> immediately after I did a RESTORE (I also got "Invalid
> Card Data" again on every warmstart since that RESTORE;
> doing PINIT cured the "Invalid Card Data"
> at the expense of the instant disappearance
> of my both last backup and my Nosy library.
Hello John,
While updating to ROM 2.0, I lost at least Emacs and
ClckAdjst from PORT :2:. I remember having had trouble with
"Invalid Card Data" and have solved this with PINIT
deleting libs and by re-transfering the libs.
With ROM 2.0 I have lost a backup file from port :2:,
which could have hapened by debugging a programm
wich is containing ML.
With ROM 2.01-1, I have lost "only" ClckAdjst
from Port :2:.
I have not documented those issues :-(,
but I can confirm that port :2: was not save during
ROM-updates.
From readme_zip.rtf, delivered with ROM 2.01-1
"Note: Although the ROM update process should not erase any of the user
data stored in HOME, IRAM (PORT0), ERAM(PORT1) and SD(PORT3), this
upgrade may erase some of the data in FLASH(Port2) performing a backup
of your valuable data is therefore recommended."
Aha, "should not..." and "... may erase..."
My note:
This note is really not helpfull for a normal experienced user, because
it is
not that easy to make a "backup" from port2.
Conclusion:
So, it seems to become "normal", to loose data from port2 :-(
Best regards
Heiko
Scott Chapin
"Heiko Arnemann" <Heiko.A...@gmx.de> wrote in message
news:439c9717$0$31369$ba62...@news.skynet.be...
<SNIP>
>
> My note:
> This note is really not helpfull for a normal experienced user, because
> it is
> not that easy to make a "backup" from port2.
>
Doesn't the command, ->SD-> , in Filer6 back up Port2?
Scott Chapin
Jean-Yves Avenard
> While updating to ROM 2.0, I lost at least Emacs and
> ClckAdjst from PORT :2:. I remember having had trouble with
> "Invalid Card Data" and have solved this with PINIT
> deleting libs and by re-transfering the libs.
>
> With ROM 2.0 I have lost a backup file from port :2:,
> which could have hapened by debugging a programm
> wich is containing ML.
>
> With ROM 2.01-1, I have lost "only" ClckAdjst
> from Port :2:.
>
When you do a flash update with a new firmware, the bootloader will
erase the first 8 banks of the flash. With ROM > 2.0 user libraries were
also added. If you had user files in bank 8 you will loose them and they
will be replaced by the equation library.
Should you delete the equation library and start saving files in port 2,
it is likely than the next time you do a flash update you will loose
some contents of user flash.
HP does recommend to backup your files before upgrading.
JY
rsch...@comcast.net
Jean-Yves Avenard wrote:
<SNIP>
>
> When you do a flash update with a new firmware, the bootloader will
> erase the first 8 banks of the flash. With ROM > 2.0 user libraries were
> also added. If you had user files in bank 8 you will loose them and they
> will be replaced by the equation library.
>
> Should you delete the equation library and start saving files in port 2,
> it is likely than the next time you do a flash update you will loose
> some contents of user flash.
>
> HP does recommend to backup your files before upgrading.
>
When I flashed back to ROM 2.0 build 50 (on two different occassions),
it always obliterated Heiko's library, 1333, for ClkAdj. It was the
last library installed. Does that mean that the last library installed
uses part of the first 8 banks?
Perhaps it just doesn't like Heiko's library AND I got lucky with the
contents of the first 8 banks?
Warm Regards,
Scott Chapin
John H Meyers
> From readme_zip.rtf, delivered with ROM 2.01-1
> "Note: Although the ROM update process should not erase any of the user
> data stored in HOME, IRAM (PORT0), ERAM(PORT1) and SD(PORT3), this
> upgrade may erase some of the data in FLASH(Port2) performing a backup
> of your valuable data is therefore recommended."
Thanks for pointing this out; however,
I had no data at all in calc when doing last ROM update (to 83);
I started loading (libraries and backups) only *after* ROM update.
All my data loss has been since that time,
and can be re-triggered 100% of the time,
by following the few steps which I outlined earlier,
none of which should cause any data loss at all.
[r->] [OFF]
John H Meyers
Okay, I'll make it even easier to reproduce it;
just follow these steps:
o Perform ON+A+F then say NO
[now we have a totally "clean" default HOME directory]
o Go into the Filer, go into HOME.
o Copy the default CASDIR into port 2 (flash).
o Warmstart via ON+C
My result:
"Warning: Invalid Card Data" [beep]
If you go into Port 2 and delete the copy of CASDIR now,
then I believe the problem will be corrected,
that another warmstart will not find invalid data,
and that PINIT will not then wipe out any other objects.
Is anyone game enough to give it a try?
By the way, I removed my SD card and also
completely cleared ports 0 thru 2 and tried it again
(to eliminate all libraries and their configs,
just an absolutely empty calc to begin with);
still got this bug (with ROM v83 in CN402 calc).
The significance of this bug is that saved archives of HOME
can not be transferred via cable into HOME
(which is the only place they can be transferred to begin with)
and then copied into port 2 (which is where you need to put them
to be able to restore and also to preserve them in flash),
because each ARCHIVE (when originally created directly into a port
of another calculator, like into its own flash, for example)
is a directory, just like CASDIR.
[r->] [OFF]
John H Meyers
So here's another bug:
After ON+A+F (NO),
switch to RPN mode and store 5 into X
Now you can copy CASDIR from HOME to port 2
(and then warmstart) without a "Warning: Invalid Card Data"
However, look back into HOME;
the variable X is now gone!
(I rubbed my eyes the first time,
then repeated this very carefully,
but with the exact same result).
Maybe if mine is the only calc that does this,
it might be especially valuable, like those rare postage stamps
which get one of several colors printed upside down!
[r->] [OFF]
Steen Schmidt
> However, look back into HOME;
> the variable X is now gone!
I reported this bug a while ago. I'll see if I can find a reference...
Regards
Steen
Steen Schmidt
> I reported this bug a while ago. I'll see if I can find a reference...
I first reported this bug in February, can't supply a reference though.
Regards
Steen
John H Meyers
> I first reported this bug in February
Which bug -- the disappearance of a variable from HOME
after copying something else to port 2?
Or the corruption of flash every time copying
a directory from HOME to port 2?
(well, not every directory, every time,
but under certain conditions,
it will fail 100% of the time when repeated the same way).
I haven't looked to find Bugzilla yet;
if I find it I'll reference this thread --
no need to write everything over again :)
Thanks for posting;
it helps reassure me that my eyesight is okay :)
[r->] [OFF]
Steen Schmidt
> > I first reported this bug in February
>
> Which bug -- the disappearance of a variable from HOME
> after copying something else to port 2?
Yes, the disappearance of any variable named 'X' from HOME dir under
certain circumstances. A warmstart will purge 'X' from HOME too.
> I haven't looked to find Bugzilla yet;
> if I find it I'll reference this thread --
You won't find my bug report on bugzilla, but now would probably be a
good time to submit it there...
Regards
Steen
John H Meyers
and perhaps a bit of analysis.
I'm out of time for experimenting further today,
but what has happened thus far fits this pattern:
o Copying a directory which is the *first*object* in HOME
(or possibly the first object in any directory)
to flash port 2 is consistently resulting in
"Warning: Invalid Card Data" after next warmstart.
o If you don't purge the copy from flash before doing PINIT,
then the PINIT command seems certain not only to delete that copy,
but is likely to wipe out more objects along with it.
In any case, you can't really copy that directory to port 2 at all,
because in the end, it will have to be purged to fix corrupt data.
Although this is as observed on 49G+ [build 83],
I wonder what happens on 49G?
Should I go back and try the same there?
I wonder whether Alan Watts is behind all this;
after all, isn't there supposed to be a "Wisdom of Insecurity"
(or doesn't it apply to storing data?)
http://www.gurteen.com/gurteen/gurteen.nsf/id/X00014F6A
http://www.amazon.com/gp/product/0595290043
[r->] [OFF]
Joe Horn
Any time that the contents of the very first variable in the HOME
directory ( HOME VARS HEAD ) is stored into Port 2 without first
NEWOB'ing it, Port 2 acts as if it is corrupted, and the problem can be
completely fixed by deleting that variable from Port 2.
Example:
(1) Store any object > 2.5 bytes into any new name in the HOME
directory.
(2) Recall that object to the stack.
(3) Store that object (unmodified, unedited, un-NEWOB'ed) into Port 2.
(4) Warmstart (ON+C) --> Invalid Card Data
(5) Purge that object from Port 2.
(6) Warmstart --> no error.
(7) Recall the object to the stack again.
(8) Execute NEWOB on it.
(9) Store it as-is into Port 2.
(10) Warmstart --> no error.
The contents of the first variable in HOME seems to always end at
memory address #FFFF6. Storing THAT into Port 2 is what seems to cause
the trouble. I'm pretty sure that this covers the cases that John has
posted so far.
The name that's used doesn't seem to matter. << HOME VARS HEAD RCL
:2:AnyName STO >> always seems to screw up Port 2, no matter what is
used in place of AnyName. Thereafter, :2:AnyName PURGE always seems to
fix it. PINIT fixes it too, but it wipes out far more than necessary
and should be avoided.
-jkh-
rsch...@comcast.net
Joe Horn wrote:
> I think I've isolated the Port 2 Loss Bug!
>
> Any time that the contents of the very first variable in the HOME
> directory ( HOME VARS HEAD ) is stored into Port 2 without first
> NEWOB'ing it, Port 2 acts as if it is corrupted, and the problem can be
> completely fixed by deleting that variable from Port 2.
>
<SNIP>
That would be in keeping with the destruction of Heiko's library. It
has always been the last object stored in Port 2, and I believe it was
stored while it was the first object in the HOME directory.
Scott Chapin
Steen Schmidt
> o Copying a directory which is the *first*object* in HOME
> (or possibly the first object in any directory)
> to flash port 2 is consistently resulting in
> "Warning: Invalid Card Data" after next warmstart.
I can confirm this.
> o If you don't purge the copy from flash before doing PINIT,
> then the PINIT command seems certain not only to delete that copy,
> but is likely to wipe out more objects along with it.
And I can confirm this. 16 libraries were just purged from my port 2,
along with the directory I had copied there using the Filer. The first
time around I tried it, no libs were touched, but the second time I
wasn't so lucky. The 16 purged libs used around 113k of flash space in
total.
This is a serious bug.
> Although this is as observed on 49G+ [build 83],
> I wonder what happens on 49G?
I can't reproduce it on the 49G.
Regards
Steen
Raymond Del Tondo
thanks for the report.
Methinks it should not work different,
either with or without a prior TOTEMPOB.
In any case, you always have a pointer
to an object if 'recalled' to the stack,
and it must not make a difference if the pointer
points to TEMPOB or to USEROB.
I think there's problem with the copy routine,
maybe a wrong counter, an overlapping address,
or even an overflow.
The latter two options come in mind especially
if you take into consideration that the bug
only seems to happen with an object near the
memory boundary.
Regards
Raymond
"Joe Horn" <joe...@holyjoe.net> schrieb im Newsbeitrag
news:1134471998.2...@z14g2000cwz.googlegroups.com...
Brother-Peter
news:xn0eaxy9...@news.tele.dk...
> John H Meyers wrote:
>
>> o Copying a directory which is the *first*object* in HOME
>> (or possibly the first object in any directory)
>> to flash port 2 is consistently resulting in
>> "Warning: Invalid Card Data" after next warmstart.
>
> I can confirm this.
>
>> o If you don't purge the copy from flash before doing PINIT,
>> then the PINIT command seems certain not only to delete that copy,
>> but is likely to wipe out more objects along with it.
>
> And I can confirm this. 16 libraries were just purged from my port 2,
> along with the directory I had copied there using the Filer. The first
> time around I tried it, no libs were touched, but the second time I
> wasn't so lucky. The 16 purged libs used around 113k of flash space in
> total.
>
> This is a serious bug.
Waiting for Cyrille's announcement of ROM 2.02...
:-(
Jean-Yves Avenard
> Nobody trying to reproduce this bug?
>
> Okay, I'll make it even easier to reproduce it;
> just follow these steps:
>
> o Perform ON+A+F then say NO
> [now we have a totally "clean" default HOME directory]
> o Go into the Filer, go into HOME.
> o Copy the default CASDIR into port 2 (flash).
> o Warmstart via ON+C
>
> My result:
> "Warning: Invalid Card Data" [beep]
Sounds to me that somehow your flash got corrupted.
Please email me your email address, I will send you a file to completely
format your flash..
JY
Jean-Yves Avenard
> When I flashed back to ROM 2.0 build 50 (on two different occassions),
> it always obliterated Heiko's library, 1333, for ClkAdj. It was the
> last library installed. Does that mean that the last library installed
> uses part of the first 8 banks?
>
> Perhaps it just doesn't like Heiko's library AND I got lucky with the
> contents of the first 8 banks?
Where a file will be stored in a bank is entirely up to the system
depending on various criterias:
1-How full is the flash
2-Where is the next bank with enough space
etc...
It could very well be that Heiko's library where just small enough to
fit in the 8th bank in the same bank as the EQL.
JY
Jean-Yves Avenard
> Well then, it seems that *my* bug is awaiting some "seconding,"
> and perhaps a bit of analysis.
>
> I'm out of time for experimenting further today,
> but what has happened thus far fits this pattern:
Okay, I've been able to reproduce it ... and I know where it comes from...
Will tell the person responsible to reverse his fix...
JY
John H Meyers
reproduced it, reported it, analyzed it,
and of course who will fix it :)
[r->] [OFF]
Scott Chapin
"Jean-Yves Avenard" <m...@privacy.net> wrote in message
news:4086ppF...@individual.net...
> rsch...@comcast.net wrote:
<SNIP>
> It could very well be that Heiko's library where just small enough to
> fit in the 8th bank in the same bank as the EQL.
>
OK, that would make sense.
Thanks,
ScottChapin