"Task not known"

I am using my own port of DeskLib to 32 bit code; however it and the application I’m using were compiled with an older (Castle era) compiler; so running the software on ARMv7 without disabling alignment aborts will report “Task not known”. If I switch the alignment thingy off, the software works as expected.

As far as I am aware, the code (mostly a bunch of veneers to SWIs, actually) is not faulty.

Furthermore, I am aware the compiler is capable of outputting ‘good’ code because I was aware of this problem when I began coding MoreKeys so in order to work around it, I rewrote all of the Wimp library code, myself, mostly in assembler [MoreKeys itself is, therefore, utterly self-contained and needs nothing more than CLib stubs] and it works fine.

I know it isn’t only my hack to DeskLib as the fault happens with !PDF, !WinEd, and a quick Google suggests it is more common than that.

So my question is – is the Wimp guru reading? Under what conditions would starting a task fail with the strange error of “Task not known”?

the fault happens with !PDF, !WinEd

Not sure what your problem is (you are on a BB, aren’t you?). Both the above work fine with AEs on, on my ARMini. I don’t think I have seen the ‘Task not known’ error for a long time.

I did run into this error a day or two ago, when I updated to a new ROM but hadn’t fixed VIDCBandwidthLimit in my !Boot. Trying to launch the screen setup plugin resulted in the error.

Since that above scenario is easy to reproduce, when I get some spare time I might have a look into what’s causing it. Just don’t hold your breath while waiting for a response!

The “Task not known” message was being caused by the C library not making a copy of the error block when it tries to report an error via Wimp_ReportError. This was resulting in the block being overwritten if (a) it’s the shared error block returned by _kernel_last_oserror, and (b) the TaskManager_TaskNameFromHandle call the C lib makes to work out the task name (for the error title) fails. This has now been fixed, so if you try running your apps again (once the ROMs have been rebuilt!) you should get a more useful error message this time.

I’ve also fixed the bug that was causing the error to appear for me when running the screen setup plugin (simple null pointer dereference)

I’ve also fixed the bug that was causing the error to appear for me when running the screen setup plugin (simple null pointer dereference)

I have only recently been checking through the configure functions and discovered that selecting the screen configure plugin gave an hourglass and a nicely locked up machine.
Mouse movement still worked but nothing else.
Is this connected?

As ever, testing on a Beagle-xm with the SD card and boot memory stick both as <2GB FAT32 partitions. (As an aside certain files in the boot have non-FAT32 compliant names – they contain [] and MS systems can’t delete or rename them. Fine on Linux)

This has now been fixed, […snip…] you should get a more useful error message this time.

Yay! (^_^)

they contain [] and MS systems can’t delete or rename them

Huh? Square brackets?

This is pretty common with certain types of downloads (Hyôka!) where you get stuff like “[480p]” and MD5s in square brackets; plus some servers that offer them as stuff like “%5D” and thus need to be renamed… XP with FAT32 SD, no problems…

I have only recently been checking through the configure functions and discovered that selecting the screen configure plugin gave an hourglass and a nicely locked up machine.
Mouse movement still worked but nothing else.
Is this connected?

Quite possibly. I did fix up a couple of other bits in the screen setup plugin, so it’s probably worth updating to the latest version and seeing if that works for you. I’ll also try and remember to give the new version a go on my BB tonight.

Huh? Square brackets?

This is pretty common with certain types of downloads (Hyôka!) where you get stuff like “[480p]” and MD5s in square brackets; plus some servers that offer them as stuff like “%5D” and thus need to be renamed… XP with FAT32 SD, no problems…

The items seem to have regional id reference (Japanese etc) I will recheck when I get home – the other post was over breakfast and sadly I had to turn up here sometime to be able to collect the money they pay as my retainer (the remuneration isn’t really pay, just an inducement to turn up and then I work for fun which explains the low level of money)

Hey Steve! This isn’t really a place for fixing Windows (^_^) but if you find a file Windows doesn’t want to deal with, close Explorer and drop to the DOS-like command line. Issue “DIR /X” and you should see a listing of filenames in OLDNAM~1.MEH format, as shown:

2012/08/21 00:23 133,328,897 NANIWA~3.MKV Naniwa Shounen Tanteidan EP04.mkv
2012/08/25 21:45 153,532,588 _HORRI~2.MKV [HorribleSubs] Kokoro Connect – 08 [48
2012/08/25 22:17 206,032,896 _5BPOM~1.AVI _5BPomf_5D Koi to Senkyo to Chocolate
2012/08/26 20:10 154,269,855 _HORRI~3.MKV [HorribleSubs] Jinrui wa Suitai Shimas
2012/08/27 21:42 219,541,986 _5BMAZ~1.AVI _5BMazui_5D Hyouka - 19 _5BXviD AnimeS 2012/08/27 23:01 203,589,632 _CR__R~1.AVI [CR]_Rinne_no_Lagrange_S2_-_20_(XviD_A

Once you know the 8.3 name, use that to delete/rename the file. You can rename an 8.3 to long, just give the 8.3 name then stick the new (long) name in quotes.

I’ll also try and remember to give the new version a go on my BB tonight.

I’ve now tried it (the latest screen setup plugin), and it seems fine for me. However I was using a completely fresh disc image, so if you tried merging the new version with your existing image then it’s possible something has gone wrong there and is causing the issue (assuming it still happens!)

Hey Steve! This isn’t really a place for fixing Windows (^_^)

That would be the day job, when the desktop guys can’t figure out what is broken and blame the network for things like a browser speed problem that only affects specific users on specific machines but works fine for a.n.other low permissions user. :-)

The experimental install currently fails in the boot somewhere and I have 640×480 and first click on the boot drive opens the first level of $.!Boot instead of $
Build is a blank fat32 with the content of HD4.util extracted to RAM and then copied into the fat32. I think I will wipe and work with the weekends latest offering.

The experimental install currently fails in the boot somewhere and I have 640×480 and first click on the boot drive opens the first level of $.!Boot instead of $

OK, I’ll give things another go, this time using the same setup you have (blank fat32 stick, HD4.util, etc.)

Have you always used a fat32 stick for your boot device? I know Ben Avison ran into some issues with getting !Boot working properly on FAT drives, so you might want to try again with a filecore formatted stick. If you don’t have a working machine handy with which to reformat the stick, you should be able to use the ‘InstallHD4’ script from the OMAP3 ROM .zip to set everything up for you (preferably the latest version, since a couple of fixes were checked in yesterday to get it working with the bigger disc image we now have).

I used the filecore version on the first build many months ago I did one on fat32 and all since then have been fat32 – deliberately so that I would find any faults that occur on what I judge is likely to be the new RO users first route in to the setup simply because they can add and remove files using a PeeCee.

I’ve had the opening the wrong directory on first click error before and I think it’s related to errors in the boot which leave the path in a strange state. I was meaning to try and step through things all week but life got in the way (busy assisting the close down of my social club clubhouse, hence a house full of paper records needing sorting for retention or disposal)
Boot sequence errors seem common for people at present and it’s tempting to suggest that there should be a Reporter install in there (but then that was what I managed to break one install with…)

Question: Is the update for the installHD4 script in the latest download?

Yes, the new script should be in the latest download.

OK.
Beagleboard image Sept 01 version, HardDisc4 self-extractor.
Boot on Sept 01 image, (hit escape and type desktop to get working desktop) manually setup RAM disc, copy HD4 util file to RAM disc to decompress and then Shift-Drag ALL files to Fat32 partition on memory stick.
Reboot.
First click on pretty icon for memory stick opens S.!boot. Close this and second click on memory stick icon opens $.
Click of Display Configure plugin generates an hourglass which if you leave it long enough for an episode of Dr. Who, times out and fails out the filer – closing the configure windows.

NB. I have had a working setup on fat32 (with the exception of the display configure.)

Now need to do the same with the installHD4 script, which should create a filecore version of boot on the stick.

Yes, the display setup window in !Configure was one of the things I found wouldn’t work if the boot drive was FAT formatted. I never got to the bottom of why, sorry…

Yes, the display setup window in !Configure was one of the things I found wouldn’t work if the boot drive was FAT formatted. I never got to the bottom of why, sorry…

I have now taken the board through the install of a filecore boot drive with the first test results:

1. Unbroken install and clean boot (after manually running the formatter and copying a boot sequence into the filecore partition as the installer failed at “line 70”)

2. Attempts to select the display configure plugin have the hourglass on screen for an awfully long time. I guessed this was it reading large numbers of definitions and moved all bar the Acorn display definitions out as a test – virtually instant display, so the plugin is taking a long time to generate the table of monitor options. Perhaps the file read is reading more than it needs to at that point.

Ben – I think the display configure plugin is falling victim to some quirk of the read/write in the fat32 handling.
Looking at a fat32 memory stick, with a default HD4 install, on a PeeCee running XP showed the first entry as !Boot_~1
Given that !Boot is less than the shortname limit it shouldn’t have those additional elements intended for the long filename kludge in windows, various other files suffer a similar fate and of course the display plugin uses lots of long (for DOS) filenames.

I will run with two alternate memory sticks, filecore and fat32 for future testing.
I need to buy some more small memory sticks to handle the variants

a PeeCee running XP showed the first entry as !Boot_~1

I don’t know whether the mixed case is a consequence of reading on a PC; if not, remember that 8.3 is upper case only, and any attempt to mix case will result in a “long filename kludge”.

Yes, the display setup window in !Configure was one of the things I found wouldn’t work if the boot drive was FAT formatted. I never got to the bottom of why, sorry…

It’s because it’s doing the old “when I enumerate the directory, the restart value goes up monotonically” fail.
I’ve opened a bug

I don’t know whether the mixed case is a consequence of reading on a PC; if not, remember that 8.3 is upper case only, and any attempt to mix case will result in a “long filename kludge”.

The read was a windows pc, I will check on a linux pc for comparison.
The intriguing part is that the case is mixed but the name format is 8.3 style. A tweak for XP etc allegedly stops the filing system storing 8.3 names – I wonder what effect that has on cross OS read write.