never seen error (solved)

[Paolo]

I don't know if it's SV related, but it happens to me since I installed it, so, let's hope to sort it out.

It happens randomly, it seems, and it prints on the console (or the screen if the console isn't open)

"buf_alloc RX failed 1718"

I also discovered that while in Kronos (2.2) it always happens when testing VDI

Does anybody have a clue?
Is it SV-related? Or maybe it is something happening just by chance right now?

[shoggoth]

This error message is not generated by the SV drivers. You need to supply more info about your system. What's your CPU-speed? Are you using a CTCM? Operating system? Etc.

[shoggoth]

Hmm... Do you have a Svethlana? (I think we need a subforum for the Svethlana)

[Paolo]

Yes, I do have a SvethLana. May this error have something to do with it?

However, as soon as I am near my Falcn again, I'll collect the info you requested.

[shoggoth]

I want to know more info about your machine at this point. Basically I can't connect it to the SuperVidel nor the Svethlana, and I have to see some indication that it can be related to that, how it is reproduced etc.

[Paolo]

My CT60 is running @95MHz with a programmbale module directly provided bu Czuba.
It is a "soldered" CT60 installation with 128MB SDRAM and 14MB STRAM
I removed EtherNat (maybe I will install it again for USB purposes)
I don't remember the CT60 chipset version, since it was updatet directly by Czuba and it doesn't show at startup, but the config acc is 1.03c.

I will shortly arrange a clean startup to see what happens

[shoggoth]

Please see if lowing the CPU clock frequency helps (try the lowest possible freq first). The signal integrity from the CPU (i.e. the electronic on the CT6x) unfortunately isn't very good at higher frequencies; this isn't obvious without an expansion card, and can work with some expansion cards but not others. The SuperVidel tries to compensate for this as much as possible, but in the end there is no magic cure except trying a lower frequency.

It's unfortunate that you can't see the CT60 chipset version, because there have been bugs in it through the years. The SuperVidel basically *requires* the latest chipset revision, otherwise stable operation *cannot* be guaranteed. So if your setup works at a lower CPU frequency, it could work better at a higher frequency again if you update the CT60.

[Paolo]

I will try by lowering the clock. However, I remember I had huge problems time ago with low frequencies, like it was more unstable, can't remember...

In the meanwhile I set up a clean startup (as much clean as I could) and got the very same error:
when in kronos OR in zbench I start the VDI test, and it gets to the justified text thingie (you know, when it draws a text and dinamically justifies it), I get those errors (usually five-ten of them)

[shoggoth]

I will try by lowering the clock. However, I remember I had huge problems time ago with low frequencies, like it was more unstable, can't remember...

My machine isn't stable around 70-75MHz, but 66-70 and 75-90 is ok, for some reason. Just try going lower so that we can rule out this.

In the meanwhile I set up a clean startup (as much clean as I could) and got the very same error:
when in kronos OR in zbench I start the VDI test, and it gets to the justified text thingie (you know, when it draws a text and dinamically justifies it), I get those errors (usually five-ten of them)

Justified text isn't accellerated by the SuperVidel, it's pure CPU code and isn't even part of the SuperVidel drivers (it's done by generic NVDI code)...

I just ran Kronos on my machine to see if I could reproduce it. I couldn't. It works here.

What colour depth are you using (please try to supply as much information as you can)?

[Paolo]

maybe we are getting to it: going at 50 Hz steps up, I noticed that the number of errors went down, but the machine got more program crashes (as we already knew).
Then I started going down, and while the errors increased, all of a sudden the decreased at around 93MHz.
Right now, at around 92.200 MHz I don't get errors.

Now, let me add something that might be useful:
When testing the falcon with NemBench, it gives the same errors when doing the

Linear 32bit read (ST-Ram)
Linear 32bit write (ST-Ram)
Linear 32bit copy (ST-Ram)

Linear 32bit read (FastRAM)
Linear 32bit write (FastRAM)
Linear 32bit copy (FastRAM)

Linear burst copy (ST-Ram)
Linear burst copy (FastRAM)
Linear burst copy (ST->Fast)
Linear burst copy (Fast->ST)

And these errors went completely away at 92.000MHz.

Now I get one error every now and then while using netsurf.
maybe I might try and change the RAM stick...

[shoggoth]

For now, I treat this as if this issue was solved by lowering the CPU frequency; it doesn't seem to be a driver issue or anything like that.

I strongly recommend that you update the CT6x CPLDs to their latest firmware revision.

[instream]

AFAICR the error text is output by the Svethlana driver when MintNet can't allocate RAM for an incoming or outgoing packet. Don't rememer which right now and don't have access to the source code to check. I see it happen very rarely (Mint 1.17.0) on my system. And then I get only one such print.
I have no idea currently why Mintnet can't allocate 1718 bytes though. Maybe we should just remove the printf and just keep the incrementation of the network interface error counter? The only bad thing that can happen when you get this message is that an incoming/outgoing packet is discarded and a resend is done by Mintnet.

[Paolo]

I noticed that this is not a problem, since everything works; it's just an annoyance.
I must try disabling MiNTnet altogether.
I already wrote that in plain TOS this never happens.

Also, it's interesting how it changes when slowing down the clock.

Ah, by the way, I had to set my clock at 95MHz again, since everything was prone to crash (NetSurf, Papyrus, ...) except the testing programs, hehe.

[shoggoth]

If there's a correlation between this error and the clock frequency, I urge you to update the firmware of your CT60 CPLDs. If not, there is no way to ensure proper operation. I also suggest that you try 90MHz (or lower) and see if it's stable. Basically, the error message isn't a big deal, but there could be other side effects that are much more severe.

[Paolo]

I am trying to understand which version of the ABE&SDR are installed. I run back all my emails with R.Czuba, and I discovered that he updated my motherboard in mid-2005, so I assume I am with the V5x

WOW Tha't ooooold!

OK, off to search for a suitable JTAG on Ebay

[instream]

I am trying to understand which version of the ABE&SDR are installed. I run back all my emails with R.Czuba, and I discovered that he updated my motherboard in mid-2005, so I assume I am with the V5x

WOW Tha't ooooold!

OK, off to search for a suitable JTAG on Ebay

http://viewitem.eim.ebay.se/Xilinx-Plat ... 71548/item

I'm 90% sure that ggn and David Galvez bought this one and it worked at least for ggn. Don't know if David has used his.
I searched for "xilinx jtag usb" to find it.

[Galvez]

http://viewitem.eim.ebay.se/Xilinx-Plat ... 71548/item

I'm 90% sure that ggn and David Galvez bought this one and it worked at least for ggn. Don't know if David has used his.

I've used it for the Supervidel firmware and it worked right. I haven't tested it with the CT60 CPLDs though.