CTPCI and USB card

Discuss CT60/CT63, CTPCI, SuperVidel and EtherNAT hardware here.

Moderators: Mug UK, moondog/.tSCc., [ProToS], lp, Moderator Team

mikro
Atari God
Atari God
Posts: 1288
Joined: Sat Sep 10, 2005 11:11 am
Location: Brisbane, Queensland, Australia
Contact:

Re: CTPCI and USB card

Postby mikro » Tue Oct 03, 2017 10:07 am

You are gonna love me for this. ;-) Last seven kernels to test. I have numbered them from 1 to 7 where 1 is the oldest and 7 newest.

From this set we need to find the bad guy. I recommend following procedure for testing:

1. (7)
2. If (7) works, that means c17 is the first bad guy. Just to be sure, verify also that (6) works.
3. Else (1)
4. If (1) doesn't work, that's good news -- we have found the bad guy. For sure test (2) to verify it's still bad.
5. Else continue in whatever direction: (2), (3), ... (6) or (6), (5), ... (2).

When you find the bad guy, always verify also the next in order is bad and make sure that the previous in order was good (or vice versa, depending on the ordering).
You do not have the required permissions to view the files attached to this post.

Kroll
Captain Atari
Captain Atari
Posts: 368
Joined: Fri Mar 09, 2012 10:07 am

Re: CTPCI and USB card

Postby Kroll » Tue Oct 03, 2017 11:28 am

I do not know if it's good or bad news. Unfortunately, none of the above works and is practically the same (see photo).
No activated additional partitions and drive q:/ is not visible

Photo-0073.jpg


To be sure that nothing else happened, I copied again the last usb_3f401cdb.zip and this one works

What do you think about ? Is it bad news ?
You do not have the required permissions to view the files attached to this post.

mikro
Atari God
Atari God
Posts: 1288
Joined: Sat Sep 10, 2005 11:11 am
Location: Brisbane, Queensland, Australia
Contact:

Re: CTPCI and USB card

Postby mikro » Tue Oct 03, 2017 12:06 pm

It's normal news. :) That means that 3f401cdb is the last working revision.

Interestingly, commit a7f4a4f0 is just a fix in code handling an error (!):

Code: Select all

long usb_new_device(struct usb_device *dev)
{
   DEBUG(("usb_new_device: "));
   long addr, err;
   long tmp;
   unsigned char tmpbuf[USB_BUFSIZ];
 
   /* We still haven't set the Address yet */
   addr = dev->devnum;
   dev->devnum = 0;
   
   [...]

   /* This is a Windows scheme of initialization sequence, with double
    * reset of the device (Linux uses the same sequence)
    * Some equipment is said to work only with such init sequence; this
    * patch is based on the work by Alan Stern:
    * http://sourceforge.net/mailarchive/forum.php?
    * thread_id=5729457&forum_id=5398
    */
   struct usb_device_descriptor *desc;
   long port = -1;
   struct usb_device *parent = dev->parent;
   unsigned short portstatus;

   /* send 64-byte GET-DEVICE-DESCRIPTOR request.  Since the descriptor is
    * only 18 bytes long, this will terminate with a short packet.  But if
    * the maxpacket size is 8 or 16 the device may be waiting to transmit
    * some more, or keeps on retransmitting the 8 byte header. */

   desc = (struct usb_device_descriptor *)tmpbuf;
   dev->descriptor.bMaxPacketSize0 = 64;       /* Start off at 64 bytes  */
   /* Default to 64 byte max packet size */
   dev->maxpacketsize = PACKET_SIZE_64;
   dev->epmaxpacketin[0] = 64;
   dev->epmaxpacketout[0] = 64;

   err = usb_get_descriptor(dev, USB_DT_DEVICE, 0, desc, 64);
   if (err < 0) {
      DEBUG(("usb_new_device: usb_get_descriptor() failed"));
      dev->devnum = addr; // <---------- this line has been added!
      return 1;
   }


I.e. it basically says that if getting the device descriptor failed, set some structure and return. So I'd assume previous versions shouldn't work and yet 3f401cdb does. Let's be totally paranoid and try the attached version, it's one revision less but with totally useless change (changing default CPU for storage.udd & netusbee.ucd from 060 to 000). If *that* doesn't work, that... that will be interesting. ;)
You do not have the required permissions to view the files attached to this post.

Kroll
Captain Atari
Captain Atari
Posts: 368
Joined: Fri Mar 09, 2012 10:07 am

Re: CTPCI and USB card

Postby Kroll » Tue Oct 03, 2017 12:31 pm

I have just tested, and not working, but after the run loader.prg on the screen there is aditional information
pid 5 (hubd): pipesize for pipe FFFFFF00 is zero
pid 5 (hubd): pipesize for pipe FFFFFF80 is zero

Similar information I had on the screen for the first compilation of the previous seven tested

mikro
Atari God
Atari God
Posts: 1288
Joined: Sat Sep 10, 2005 11:11 am
Location: Brisbane, Queensland, Australia
Contact:

Re: CTPCI and USB card

Postby mikro » Tue Oct 03, 2017 12:39 pm

Most intriguing. Maybe you have discovered quite interesting bug in the m68000 library. Let's see what happens with this one. This is literally the same as 3f401cdb.
You do not have the required permissions to view the files attached to this post.

Kroll
Captain Atari
Captain Atari
Posts: 368
Joined: Fri Mar 09, 2012 10:07 am

Re: CTPCI and USB card

Postby Kroll » Tue Oct 03, 2017 12:56 pm

mikro wrote:Most intriguing. Maybe you have discovered quite interesting bug in the m68000 library. Let's see what happens with this one. This is literally the same as 3f401cdb.


Wow, it is working (look at photo),
Photo-0075.jpg


Does that mean we are close to solving a problem with mass storage in Netusbee ? :D
You do not have the required permissions to view the files attached to this post.

mikro
Atari God
Atari God
Posts: 1288
Joined: Sat Sep 10, 2005 11:11 am
Location: Brisbane, Queensland, Australia
Contact:

Re: CTPCI and USB card

Postby mikro » Tue Oct 03, 2017 9:25 pm

No, that means we have a rather interesting problem to solve. ;-) (btw thanks for accepting the builds in such raw form, it saves me heaps of time)

I'm attaching two of our well known friends, usb-5f968c56 (working one) and usb-1adba0e0 (not working one). This is for a) verifying I didn't make a stupid typo or something similar yesterday b) get some debug outputs.

So, try to boot the kernel, press shift, set the debug level to "DEBUG", continue. Don't freak out with many debug messages. ;-) Then run the loader as:

./loader.prg > usb-XXXXXXXX.log (don't remember whether it's standard output or error, if you still see messages after this command, try ./loader 2> usb-XXXXXXXX.log)

Do for both, send me the logs. This should reveal the nature of this bug (whether 68000 code makes it slower = some timeout isn't met or it's something more serious).
You do not have the required permissions to view the files attached to this post.

Kroll
Captain Atari
Captain Atari
Posts: 368
Joined: Fri Mar 09, 2012 10:07 am

Re: CTPCI and USB card

Postby Kroll » Tue Oct 03, 2017 10:18 pm

mikro wrote:No, that means we have a rather interesting problem to solve. ;-) (btw thanks for accepting the builds in such raw form, it saves me heaps of time)

I'm attaching two of our well known friends, usb-5f968c56 (working one) and usb-1adba0e0 (not working one). This is for a) verifying I didn't make a stupid typo or something similar yesterday b) get some debug outputs.

So, try to boot the kernel, press shift, set the debug level to "DEBUG", continue. Don't freak out with many debug messages. ;-) Then run the loader as:


Sorry for being a trivial question, but after entering Freemint boot menu :, I have options
7 Debug / trace level, which should set:

0 - (none)
1 - ALERT
2 - ALERT, DEBUG
3 - ALERT, DEBUG, TRACE
4 - ALERT, DEBUG, TRACE, TRACELOW

8 - Debug output dev.

0- PRN: printer
1- Aux: modem
2 - CON: conole
3 - MID: midi
4 - KBD: keyboard
5 - RAW:: raw console

Memory Protection should be Yes ?

mikro
Atari God
Atari God
Posts: 1288
Joined: Sat Sep 10, 2005 11:11 am
Location: Brisbane, Queensland, Australia
Contact:

Re: CTPCI and USB card

Postby mikro » Tue Oct 03, 2017 10:35 pm

Set 2 - ALERT, DEBUG (trace is worth trying but perhaps you'll be flooded with too many useless messages; try 2 first)

Debug device - console (2 again).


Social Media

     

Return to “CT60 / CT63 Area”

Who is online

Users browsing this forum: No registered users and 4 guests