Pi hangs at startup?

Because I had to sign the NDA for the full Ethernet specs, I’m not allowed to distribute the code without each line being approved by ROOL first, anyway.

And that’s just fiction.

Well I specifically asked Steve how the NDA affected distribution of software which used the NDA’d SWIs and was told I should send a copy to ROOL for clearance first.

That sounds more like a hand of generosity being extended to eyeball your code before you release it, to be sure the terms of the NDA haven’t been broken. There’s no specific term I can see (in my copy) that requires it, provided I don’t disclose information that’s not already in the public domain.

For example, if I look in the StrongHelp manual I can see there’s a DCI4 enumerate service call. If I look in the dcistructs.h header or showstat I can find out what all the fields are and write something to show the MAC address of all the NICs in my machine:

REM Find the NICs
DIMhwaddr% 6
SYS"OS_ServiceCall",0,&9B TOhead%
next%=head%
WHILEnext%<>0
  chain%=next%
  next%=chain%!0
  dib% =chain%!4
  SYS"XOS_GenerateError",dib%!4 TOname$
  FORi%=0TO5:hwaddr%?i%=?((dib%!12)+(5-i%)):NEXT:REM Endianness
  SYS"OS_ConvertVariform",hwaddr%,STRING$(32,CHR$13),32,6,11 TOeui48$
  PRINT"Dib &“;~chain%!4;” for “;name$;dib%!8;” is at “;eui48$
  REM Free the chain
  SYS”OS_Module",7,,chain%
ENDWHILE

safe in the knowledge I’ve not disclosed anything.

The total number of people who need the DCI4 spec is probably less than 10 in the whole world, and they can, by just going through the motions (ie. don’t waste ROOL’s time just requesting it because you’re nosey, they do enough dreary admin that nobody sees as it is!).

Hmm… I’ve been playing with this some more. The iPad stopclock times the delay of a full boot as taking 7.28 seconds. If I unplug EtherUSB, this drops to 4.93 seconds. I don’t use DHCP as explained above.
I notice that during the pause following the “mod init okay”, a lot of stuff is going on. Keyboard LEDs blink and so on. So I’m going to have to kick this over to Jeffrey to ask what are the potential side effects of having callbacks take place at this point – namely prior to various things being correctly set up. I notice that the bit of code immediately following sets the size of the RMA. How does this affect USB (etc) initialisation which might claim buffers in the RMA, for example? Could a callback occur on an FS before the FS has been set as the default? (perhaps this could explain the “sometimes can’t see the FileCore part” issue?).

Probably not helpful – but I gave up on DHCP and set the Pi to static IP. Thanks to random (and depressingly frequent) brownouts

I’ve now replaced my !Boot with the latest, moved SetUpNet from PreDesk to Tasks and added the following lines to !Boot.Choices.Internet.User to fix DHCP’s sporadic failures

If "<Inet$Resolvers>" = "" Then Set Inet$Resolvers 192.168.1.1
route add 0.0.0.0 -net 192.168.1.1 { > null: }

I’ll see if this improves the hangs I was seeing today.

EDIT: Boot time is 26 seconds

The various network driver sources along with the OS headers probably cover most of the DCI spec. I hope EtherUSB’s source is readable.

That sounds more like a hand of generosity being extended to eyeball your code before you release it, to be sure the terms of the NDA haven’t been broken. There’s no specific term I can see (in my copy) that requires it, provided I don’t disclose information that’s not already in the public domain.

I did specifically ask what the requirement was regarding NDA’d SWIs and was told I should submit it to ROOL for approval first, not that I could and they’d kindly look over my code.

Just to be clear, are you stating as official ROOL policy that I don’t need to submit any code that uses the NDA’d SWIs to ROOL for approval before I release it? Presumably I wouldn’t be allowed to comment the code in such a way that it effectively documents the SWIs I’m using?

The various network driver sources along with the OS headers probably cover most of the DCI spec. I hope EtherUSB’s source is readable.

Indeed, and I did look at the various sources available, along with C headers, in order to see what was going on, and did have 99% of my code written that way before I acquired the NDA’d DCI4 Spec document which then confirmed what I’d ‘reverse engineered’ beforehand.

I’ve now replaced my !Boot with the latest, moved SetUpNet from PreDesk to Tasks

This has simply moved the hang to the desktop, so either the DHCP Module is hanging or something it’s doing is causing USB to hang the machine.

You seem to be having a dreadful time with your pi. Did the USB audio rom make any difference – don’t really expect it to but there are some USB changes in it. Would you like to run USBDescriptors and post the results so that I can see the USB devices you are running.

When I first got my pi I vaguely remember DHCP being slow and if I remember correctly I think it was because the Gateway was set in configure clearing the field cured it.

You seem to be having a dreadful time with your pi

I expect my experience is no different to anyone else, the reason I appear to see more issues than most is because I reboot it around 100 times a day, whilst testing code changes.

I’ve not tested the USB audio ROM as I’m currently testing the bug fix Jeffrey applied a few days ago.

Configuration wise, my Pi is vanilla using the 13/10/10 ROM and matching !Boot. The only changes I’ve made are those mentioned above to test this issue, ticking DHCP in Networks and adding a 32mb RAM drive.

USB wise, I either have a KVM attached keyboard/mouse with power via an official Pi PSU or a powered hub with keyboard/mouse in, which backfeeds power to the Pi via the USB port.

I expect my experience is no different to anyone else,

[…]

I reboot it around 100 times a day,

Um.

:-)

I reset my pi often without problems but just to test I reset my pi 100 times in a row and still no problem. Is the hang frequent?

No, completely at random but more often after a power cycle. I don’t recall seeing many hangs via softboot. I suspect (but can’t prove) that USB might be the cause.

I reboot with the NIC attached, if that makes any difference. I’ve not tested without a NIC as I’m constantly copying updated code across.

I reset using the reset button. I have the keyboard and mouse plugged into my monitor and connected to the pi via a usb switch. I have the internet connected and use DHCP. I’m just using a bog standard !internet setup.

Reset button – luxury. I have to pull the power lead out!

OMG!

You need a reset button. Much friendlier to the hardware.

I’m not even sure if my dev Pi has the relevant header, it’s one of the original Pi B’s. I must have pulled the power lead tens of thousands of times by now!

You need a reset button. Much friendlier to the hardware.

Or at the least an on/off switch so you don’t have to keep pulling the plug!

I’m not even sure if my dev Pi has the relevant header, it’s one of the original Pi B’s.

The very first did not have a reset, but each subsequent Pi has one. On the Rev2, short the header P6 and on the + short RUN.

Perhaps it is time to update. You could get a B+, not B2, for only £15 a little while ago.

Off the back of this, I thought I’d get my Pi2 set up. Randomly, around the point at which the Pi usually hangs, the Pi2 was going to a blank screen and locking solid instead.

Initially, I thought it was down to incompatibility with the daily builds (as I was seeing RAM drive corruption¹), so went back a few weeks. After ten mins it again went to a blank screen and refused to work again. Assuming the ROM was now corrupt, I replaced it but again it refused to work again.

At this point I went back to RC14 trying both NOOBS and via the full disc image, same issue, but I did start to notice a pattern, in that it always started after I’d finished configuring the OS. On a hunch, I went to the latest 17-10-15 build, but this time unplugged the NIC. It worked every time. Plug the NIC in, blank screen, unplug the NIC, it works.

I don’t think the issue is down to the NIC, more likely USB, as to get a blank screen outside of MODE changes, something catastrophic has occurred. When I get this with ADFFS, it’s usually something writing past the GPU memory and hitting what I guess to be a key bit of IO memory space.

¹ The RAM drive was reporting a bad free space map, occurring at random when FTPc was midway through transferring a file to it.

I seem to have my fingerprints all over your problems. EtherUSB has changed since RC14 and it’s not that complicated it just passes ethernet packets to and from USB endpoints. The endpoints are just bulk endpoints – so well tested with usb file transfer. How FTPc causes a bad free space map is beyond me it just opens a file saves data and closes it so I can’t see how corrupting socket reads could cause a bad free space map. I suppose it may be related to Jeffrey’s changes to how RAMFS works.

It is good that you can repeat your problems on 2 PIs – at least you know it’s not the PIs. Could there be a problem with your router?

The only way I can see that you will get to the bottom of this is to compile the rom and find where it hangs yourself. If I could repeat it here I’d do it for you.

Do you have a riscos machine that you don’t have problems with?

I’ve updated my Pi usbaudio rom with a compilation from todays sources if you would like to see if it makes any difference – it would contain the changes you require for your own project. I could do a version without the zero page relocation if you think it would help.

The only other thing I can think of is have you tried not using the KVM

One could say that if a piece of external hardware causes a crash, something is wrong.

I wouldn’t disagree but as he can’t debug the rom himself it would narrow things down if we could locate a problem device.

Do you have a riscos machine that you don’t have problems with?

I believe the problem is Pi specific as I’ve never seen a hang on the Iyonix or RPC running RO5 – however, I don’t use them as much as the Pi so possibly not a good indicator.

I’ve updated my Pi usbaudio rom with a compilation from todays sources if you would like to see if it makes any difference – it would contain the changes you require for your own project. I could do a version without the zero page relocation if you think it would help.

Excellent, I’ll test it later when I’m back home. Ruling out Zero Page relocation is definitely something we need to do, if you wouldn’t mind doing me a build. That will help me out as well, as I need to rule out Zero Page relocation as the root cause of a load of other OS issues I’m seeing.

The only other thing I can think of is have you tried not using the KVM

I should have mentioned that all tests were done with Keyboard/Mouse connected via a powered USB hub, with the Pi also powered to rule out any power issues. I wasn’t seeing any power droop warnings – one handy feature they added to the Pi2 (pity they didn’t add a VRM circuit to resolve the underlying issue as well!)

EDIT: Typically I can’t get the damn thing to do it today!

EDIT2: The RAM drive issue seems to be a quirk of the DA changes in 5.23. The value of the RAM disc section in Configure\Discs wont accept changes and is stuck at 0.1mb. Quiting RAM and sliding the DA size up resolves this particular problem. I guess I need to replace !Configure with the latest from the daily HD image?

Ok PiUSBAudioROM_LPV is the same rom compiled with Low Processor Vectors.