Tungsten 22nd Oct Softload issues

Hi

I tried updating my Iyonix’s softload from the 21st Oct version to this mornings 22nd Oct version and the Iyonix fails to boot in to the desktop.

I rebooted the machine and answered “yes” at the softload prompt and the machine rebooted and went through the normal dhcp/pre desktop boot sequence.

At what should be the normal desktop start the hour glass became visible but the screen remained grey with no splash screen/Iyonix/Castle logo coming on.

I left the machine like this for over 5 minutes with no sign of the desktop.

I also tried a further reboot and also load in to 5.18 plus further installation of another clean download of the softload but with the same lack of booting in to the desktop.

I then reverted back to the 21st Oct softload and normal system booting was restored.

I notice that there have been Filecore and ADFS changes between the 21st and 22nd oct ROMs so are these the root cause or can I check something else.

My Iyonix has 2 ADFS harddiscs and 2 CDROM’s which I think are are all set up to cable select.

Doug

I installed the Oct 22 OMAP3 ROM on the ARMini this afternoon, and was soon plagued with random messages to ‘Please insert disc ARMini’ (the filecore formatted boot drive). All the USBSCSI drives seemed to go awol and a reset was needed to restore sanity. It also seemed unable to register insertion of filecore pen drives. Fat32Fs seemed ok. After a number of such events, needing reboots, I have reverted to the 11 Oct ROM and all has seemed OK since – using machine as normal.

If I get time later I will have another go with Oct 22 ROM.

I used the Oct 22 OMAP3 ROM on the Pandora with no Problems. I have seen any filcore-modules and SDFS module has actualy changed.

I notice that there have been Filecore and ADFS changes between the 21st and 22nd oct ROMs so are these the root cause or can I check something else.

The change to FileCore (should) only affect mounting old map floppy discs, and the change to the filer would require mouse interaction to even call the code, so I think it’s far more likely that ADFS is the one to watch.

Can you try loading an older version? Of course a little care is needed if booting from that drive too. For example, you might
*CONFIGURE NOBOOT
Reboot
*RUN !Boot
Accept ‘Y’ to start the softload from 22-Oct-2012
*MOUNT 4
*CHANGEDYNAMICAREA -ramfssize 1024k
*COPY whereever_you_saved_it RAM::0.$.ADFSTemp
*RAM
*RMLOAD ADFSTemp
*RUN !Boot

doubtless there are other ways, but you get the idea. That should help home in on any suspects. Cheers!

Ok after a few amendments to the above, i.e language was set to 11 so it booted to desktop , fixed by setting it to 10 and need to change back to ADFS before final !Boot, I think that ADFS 345 changes are to blame.

Using ADFS 344 I can !Boot in to a desktop though the screen/monitor settings were not picked up and had to be reset from Auto. Everything else seems the same.

With ADFS 345 it just stays on the splash screen with the Iyonix logo and default auto monitor/screen resolution settings by the look of it. Though this wasn’t the exact behaviour I saw with just a pure 22nd Rom it shows the same lockup and failure to enter the desktop issues.

Hope this helps.

Doug

Using ADFS 344 I can !Boot in to a desktop […] with ADFS 345 it just stays on the splash screen with the Iyonix logo.

Thanks for that, it sounds like a fat finger moment in ADFS somewhere (good job I made 3 check ins with 3 distinct sets of changes). I’ll take a look.

I’ve been mostly wearing out floppy discs: the gentle background tick of a disc bashing program running for it’s 3500th iteration 24 hours a day, though with IOMD it looks like some module somewhere is causing Filer_Action to hang so I’m doing everything single tasking at the moment.

The ARMini (with Oct 11 OMAP3 OS) ran all night and was in use normally this morning. I then changed to the Oct 22 build (which still seems to be the latest). Machine booted OK and I was doing some editing etc.

After 15-20 mins of use, while I was simply reading text on the screen, an error box appeared: Message from SCSI – “Please insert disc ‘ARMini’”. At the same time all drives disappeared from the iconbar and all filer windows, except the boot drive root dir (opened as ‘Boot:^’) closed. RAM and ShareFS icons were still visible.

Clicking on ‘OK’ just looped the error.

Clicking on ‘Cancel’ the ARMini drive came back on the iconbar and was accessible. The SSD Fat drive icon appeared, but showing as :4. Clicking on this remounted the drive and it is accessible again.

Machine seems to be usable as normal.

Inspecting the wimp syslog file shows after the insert disc error the following entry.

23 Oct 12:28:20 - 4881869 log lines missed while in IRQ mode

I am not sure whether this is related to the problem observed by Doug, is a different problem, or is specific to my machine. However, it looks as if something has changed between 11 and 22 Oct.

Inspecting the wimp syslog file shows after the insert disc error the following entry.
23 Oct 12:28:20 – 4881869 log lines missed while in IRQ mode

What if you go through the same sequence but with the Syslog temporarily setup to log to a RAMDISC (Memphis 3.03 or the plain vanilla version)?

The content of those log lines might be useful.

Using ADFS 344 I can !Boot in to a desktop […] with ADFS 345 it just stays on the splash screen with the Iyonix logo.

Found the mistake: I was clearing the “background transfer” bit when checking the DiscOp reason code. This was also the cause of Filer_Action hanging too, so two bugs with one instruction.

Fantastic and thanks for the quick response and fix.

I’ll try the updated softload ROM when I can as a little busy over the next couple of days.

Fantastic and thanks for the quick response and fix.

Not so much a ‘fix’ as an ‘un-blunder’. If you could retest that’d be great, and perhaps give floppies a spin too if your machine is fitted with one? Format/verify/copy a few files on/copy them back off again – that sort of thing.

Retested with 23rd ROM and HardDisc image and OK.

Formatted/Verified two floppies using ADFS 1600 F+ format and DOS 1440K OK. Copied files back and forwards 5 times each disc. Filled up F+ discs so only 70K free.

Tried accessing webpages using !Netsurf whilst doing one set of Formatting/Verifying/Copying as well with no issues.

So not an extensive test but at least shows it works.