another pci-e to parallel port issue with "make" command

computer: dell optiplex 7010 business desktop
"Dell Optiplex 7010 Business Desktop Computer (Intel Quad Core i5-3470 3.2GHz, 16GB RAM, 2TB HDD, USB 3.0, DVDRW,"

Now flashed with linuxcnc 2.7 which went well

I need a parallel port to use with my sherline lathe but am gettting worried now because every thread about this seems to have been a dead end - I am using the startech card "StarTech.com 1-Port Parallel PCIe Card - PCI Express DB25 LPT Printer Card"

I added all of the necessary files per the instructions and installed all of the packages which went well. However, when I navigate to the folder in the terminal and type in "make" I get the following error: Im sure other errors will arise...

/home/Desktop/ttt/ax99100_sp.c: In function ‘serial99100_request_port’:
/home/Desktop/ttt/ax99100_sp.c:2282:6: error: ‘mem_size’ undeclared (first use in this function)
/home/Desktop/ttt/ax99100_sp.c:2282:6: note: each undeclared identifier is reported only once for each function it appears in
/home/Desktop/ttt/ax99100_sp.c:2283:3: error: ‘ret’ undeclared (first use in this function)
/home/Desktop/ttt/ax99100_sp.c:2296:1: warning: control reaches end of non-void function [-Wreturn-type]
make[4]: *** [/home/Desktop/ttt/ax99100_sp.o] Error 1
make[3]: *** [_module_/home/Desktop/ttt] Error 2
make[2]: *** [sub-make] Error 2
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-3.4-9-rtai-686-pae'
make: *** [default] Error 2
XXXXX@mglinux:~/Desktop/ttt$


When I go to the associated file ax99100_sp.c and look into those variables, this is the section of the code: I am confused because it does seem like the variable is properly defined...any suggestions?

//Helper function to get the necessary kernel resources for the port
static int serial99100_request_port(struct uart_port *port)
{
struct uart_99100_port *up = &serial99100_ports[port->line];
#if defined(__x86_64__) || defined(__amd64__)
int ret = 0,size=8,mem_size=4096;
#endif
#if defined(__arm__) || defined(__aarch64__)
int ret = 0,mem_size=4096;
#endif
//todo:the mem_size and the mem2_size are not yet known properly
DEBUG("In %s

---

START\n",__FUNCTION__);
#if defined(__x86_64__) || defined(__amd64__)
if(!request_region(up->port.iobase, size, "AX99100"))
return -EBUSY;
#endif
if(!request_mem_region(up->port.mapbase, mem_size, "AX99100")){
ret = -EBUSY;
goto release;
}
DEBUG("In %s

---

END\n",__FUNCTION__);
return ret;

Ok, forget about the supplied drivers, they are a waste of time, and usually only specific to the "advanced features" of the serial side. I swear this is always comes up in one form or another, just recently for this same chipset.

I don't why you're using Wheezy, with those specs Bookworm and a RT_PREEMPT kernel will be fine. But none the less. My Leneovo M72e has the same specs and is fine with Bookworm, a SSD boot drive is a good idea. If latency is a issue isolcpus=2,3 helps.

Please supply the output of these 3 commands:

Sorry I realise now why you are using Wheezy, it's the Sherline thing.
My apologies.

The issue I can fathom, just out of interest, is that ret isn’t being defined for a 32 bit platform, it’s defined for x86_64, amd64 as well as 2 arm platforms.
Are you sure the driver supports a 32 bit platform ? Not that it’s going to be needed.
Wheezy is only 32 from memory.

What happens when you remove these lines in that file?
#if defined(__x86_64__) || defined(__amd64__)

And the "    #endif" after that

ret will only be defined for the arm platforms in the next stanza.
The thing is neither of the the #if statements are being acted on. There's no define for a 32 bit platform.

It might be my ignorance, doesn't this line define 'ret'?

#if defined(__x86_64__) || defined(__amd64__)
int ret = 0,size=8,mem_size=4096;

To me it looked like that when they added support for aarch64 they added the if x86_64. In this driver for example you don't see the if x86_86 before that line.
forum.ubuntu-fr.org/viewtopic.php?id=1993441

Otherwise wouldn't installing Debian Bookworm be an option with the rtai kernel, modules and headers from:
www.linuxcnc.org/dists/bookworm/base/binary-amd64/

Since there is no clause for x86 (whatever the 32 bit define is) so ret never gets defined in the scope of the function.

It's bit of a moot point really, since googling that card turns up with the serial port components unpopulated. Most of these chips can be configured via hardware (on board links) to operate as either serial or parallel ports. One of the AX chips also has an SPI interface that can be enabled. But a lot of this is dependant on the schematic & PCB being designed for such.

From the source I could find matching that card, it seems there is a patch for the kernels parport driver, but that only adds the PCI id to the kernel source. Those sources in the package were for 2.6 & 2.4 kernels. The OP may have a different archive, but I think even Wheezy was on a 3.x kernel.

The OP is using a sherline machine and the files sherline provides is for Lcnc 2.6, on another thread I did suggest Wheezy might be the go. I did suggest that Bookworm might be the better option, until I went and checked if it was the same user. In my second post I did apologise taht I didn't realise it was the same user with the sherline machine. It may have been easier if it was kept all in the one thread.
Since there has been no response it's difficult to take this thread further.
Even if the driver parport module was needed to loaded and a PCI id isn't matching for that device the kernel can be forced to load a driver via some udev magic.

There's some info here, just for interest:
unix.stackexchange.com/questions/67936/a...bedded/165845#165845

udev is pretty good, you can use it to mount USB drives by matching serial# or whatever automagically to a particular folder.

So when you remove the if... it always gets defined, or replace with:
#if defined(__x86_64__) || defined(__amd64__) || defined(__i686__)

When I replace these lines in ax99100_sp.c and parport_pc.c, I'm able to insert the module with "sudo insmod ax99100.ko"

drive.google.com/file/d/1bPI5vTtZvWeqOGH...HAT/view?usp=sharing
drive.google.com/file/d/15o3Yc9AOe5HOQ-a...A1Q/view?usp=sharing

So to install:
sudo cp parport_pc.ko /lib/modules/3.4-9-rtai-686-pae/kernel/drivers/parport/parport_pc.ko
sudo cp ax99100.ko /lib/modules/3.4-9-rtai-686-pae/
sudo depmod -a

Then take the first address of the parallel controller from the following command
lspci -v

For example: I/O port at d010

Then execute the following command with the correct address:
echo "options parport_pc io=0xd010" | sudo tee /etc/modprobe.d/parport_pc.conf

sudo reboot

 

To tell the truth you really don’t need the parport driver to be loaded.
Linuxcnc will load without it. Like I said it my Parallel Port Treatsie thread, the only call to the kernel module is to get exclusive use of the port. If the call fails and your Hal file has the correct address it will still run.
As for the serial port driver, what’s the point in building it if the card doesn’t have the components for the serial port populated ?
If the card has been manufactured without the serial port headers and driver chip there’s a better than ever chance that the chip has only been strapped for Parallel Port operation and if that’s the case the card will only report the PCI id for the Parallel card, the chip reports the id depending on how it’s config pins are strapped. So if the card doesn’t report to the PCI id that matches those defined in the serial port module, the kernel won’t load that module.
I’ve had a read of the data sheet for that family of chips and it’s quite interesting what can be done with it.
Just out of interest if you want to know what Vendor & Product ID a kernel module supports you can run modinfo with name of the driver.
The problem with users coming from windows to Linux when installing new hardware that comes with a “driver disc” is that they assume that they need to build and install the driver. It’s rare that needs to be the case.
You can even google the vendor and product id of a device and you’ll find pages that will let you know if & when a driver that matches was introduced into the kernel.
Ages ago I attempted to get a thread going with the IDs of Parallel Port cards that were known to work. But after some initial interest it went silent.
There’s also a parport_serial driver (the name I may have muddled up) in the kernel that supports a lot of these cards that have a chipset that can present as both a serial & Parallel Port.