Well I've worked around the issue (for now). In the end I have had to add an extra step to my driver's 50HZ timer tick service that checks if the I/O job is still running (and is due for removal) and then issues an mt.frjob there. I still have no explanation as to why the job is seemingly unable to remove itself, or why other job control traps are behaving so strangely in the spawned jobs.
So ... development of the USBWiz driver project continues. The old version of the driver could mount and read/write a QDOS format SD card, but stalled when doing slaved writes or large reads. This new version uses a totally different architecture but that has introduced a whole new set of problems. I'm hopeful that they can be solved in time ... but then the question is whether anyone would want a USB device that is read/written at the maximum speed of the serial port! :( Adrian -----Original Message----- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Adrian Ives Sent: 30 January 2011 11:18 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing George, That had occurred to me as well, but this section of code is definitely executing in user mode. The job can be manually removed using an S*BASIC RJOB command or from the QPAC Jobs list. However, I'm sure the clue does lie in the fact that the trap is not guaranteed atomic. Adrian -----Original Message----- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of gdgqler Sent: 30 January 2011 10:37 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing On 30 Jan 2011, at 10:25, Adrian Ives wrote: > I am in the process of rewriting the USBWiz driver to get around the > problems with supervisor mode that I encountered last year. > > > > The new driver spawns independent jobs to handle reads and writes > asynchronously in the background (because it has to invoke serial IO). > I'm doing the work in QPC2 and I've encountered a problem with calls > to MT.FRJOB. > > > > This is the code that I'm using at the end of my USB_RD (and USB_WR) job: > > > > moveq #mt.frjob,d0 > > moveq #me,d1 > > moveq #0,d3 > > trap #1 ; > Remove ourselves! > > > > The only problem is that it doesn't work! It actually returns err.nc > (Not > Complete) and the job continues executing. Calls to mt.susjb and > mt.prior succeed (d0 is zero on return) but don't actually do what > they should. > > > > I'm beginning to think it's a QPC2 thing, but before I unpack the > Aurora QL from its hermetically sealed casket in the garden shed, can > anyone shed any light on the reasons why these traps should fail in > this way? > > mt.frjob may not work in supervisor mode. The manual (Dickens) says "this trap is not guaranteed atomic". Could this be the problem? George _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
