Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing
Adrian Ives wrote: I was 100% certain, but I went back and checked this and you're right - too much late night editing! So my psychic debugging abilities have once again not failed me ;) Well, it was sort of along shot but on the other hand also the only logical explanation as the things you wrote were simply impossible... anyway, glad another mystery got solved ;) Cheers, Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Help! Reasons for MT.FRJOB Failing
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? Many thanks Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
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
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
Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing
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
Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing
Adrian, 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! This reminds me of something I used to do many years ago, and the reason I did it was because i saw it done by someone better than me: kill_memoveq #mt.frjob,d0 moveq #me,d1 moveq #0,d3 trap #1 bra.s kill_me I can't remember if it was Andy Pennell or Adrian Dickens or Chas Dillon. Someone did it though. Cheers, Norman. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing
On 30 Jan 2011, at 16:33, Norman Dunbar wrote: 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! This reminds me of something I used to do many years ago, and the reason I did it was because i saw it done by someone better than me: kill_memoveq #mt.frjob,d0 moveq #me,d1 moveq #0,d3 trap #1 bra.s kill_me I can't remember if it was Andy Pennell or Adrian Dickens or Chas Dillon. Someone did it though. Interesting. I've never to my knowledge needed the final branch in any of my programs. With the branch in, the program is not going to do very much until it eventually decides to stop. Without that anything may presumably occur. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing
Hi George, Interesting. I've never to my knowledge needed the final branch in any of my programs. With the branch in, the program is not going to do very much until it eventually decides to stop. Without that anything may presumably occur. I have a funny feeling you called me to task many years ago in QL Toady when I wrote some code with it in! ;-) Cheers, Norman. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing
On 30 Jan 2011, at 16:47, Norman Dunbar wrote: Interesting. I've never to my knowledge needed the final branch in any of my programs. With the branch in, the program is not going to do very much until it eventually decides to stop. Without that anything may presumably occur. I have a funny feeling you called me to task many years ago in QL Toady when I wrote some code with it in! ;-) That is highly unlikely. In fact I often use for testing a small program which ends by running through to the suicide code. Each time I look at this I remind myself that nothing can happen after the Trap #1. But it appears it can! Both Pennel and Dickens say that the only error that can occur with mt.frjob is -2, invalid job. So not complete can't occur. H! George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing
It's worth bearing in mind that I'm developing under SMSQ/E on QPC2, which post-date Pennel and Dickens, either environment may have an effect. In any case, my job definitely continued to execute after the Trap #1 and even doing the kill_me looping branch didn't solve the problem - it just kept calling mt.frjob ad infinitum! I'll need to dig further into this because even though I now have a solution, I don't like not understanding why the behaviour is there in the first place. Or why, in the same job, calls to mt.susjb or mt.prior all return 0 in d0, apparently indicating success, but don't actually do anything! 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 17:07 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing On 30 Jan 2011, at 16:47, Norman Dunbar wrote: Interesting. I've never to my knowledge needed the final branch in any of my programs. With the branch in, the program is not going to do very much until it eventually decides to stop. Without that anything may presumably occur. I have a funny feeling you called me to task many years ago in QL Toady when I wrote some code with it in! ;-) That is highly unlikely. In fact I often use for testing a small program which ends by running through to the suicide code. Each time I look at this I remind myself that nothing can happen after the Trap #1. But it appears it can! Both Pennel and Dickens say that the only error that can occur with mt.frjob is -2, invalid job. So not complete can't occur. H! 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
Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing
Adrian Ives wrote: moveq #mt.frjob,d0 moveq #me,d1 moveq #0,d3 trap#1 Check the disassembly. I guess D1 is set to 0. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing
No, it isn't. me is defined as -1, for the current job. -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Marcel Kilgus Sent: 30 January 2011 21:20 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing Adrian Ives wrote: moveq #mt.frjob,d0 moveq #me,d1 moveq #0,d3 trap#1 Check the disassembly. I guess D1 is set to 0. Marcel ___ 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
Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing
Adrian Ives wrote: No, it isn't. me is defined as -1, for the current job. Have you checked that in an actual disassembly or in a debugger or just had a look at the source? Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing
I was 100% certain, but I went back and checked this and you're right - too much late night editing! This solves the mystery, because Job 0 cannot be removed. However, on the plus side, this problem actually allowed me to develop a tidier method of managing the spawned jobs. Many thanks for your insight! -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Marcel Kilgus Sent: 30 January 2011 21:33 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing Adrian Ives wrote: No, it isn't. me is defined as -1, for the current job. Have you checked that in an actual disassembly or in a debugger or just had a look at the source? Marcel ___ 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
