I have an adaptec 6805e RAID controller and I'm looking to compile the linux driver for ubuntu 20.04 (kernel=v5.4) but there have been a vast number of changes between kernel ~4x => 5x and I'm not a kernel developer.
OS:
Ubuntu LTS 20.04
Kernel:
v5.4
Adaptec 6805e:
https://storage.microsemi.com/en-us/support/raid/sas_raid/sas-6805e/
Any obvious major hurdles, or advice is appreciated, but right now the issue I'm having is trying to find a replacement for the 'pci_set_dma_max_seg_size' function. I have found the 'dma_set_max_seg_size' but that function accepts a generic device structure (struct device), whereas the adaptec code is using the (struct pci_dev) structure that seems to be specific for PCI devices.
aacraid-1.2.1-52011/linit.c:3992:10: error: implicit declaration of function ‘pci_set_dma_max_seg_size’; did you mean ‘dma_set_max_seg_size’? [-Werror=implicit-function-declaration]
3992 | error = pci_set_dma_max_seg_size(pdev,
Like I said any help is appreciated and if this seems like the wrong way to resolve this problem I'm open to ideas -- I'd like to be able to utilize the benefits of more recent linux developments with a slightly older adaptec chipset.
Thanks
Reference materials:
https://elixir.bootlin.com/linux/v5.4.128/source/include/linux
I believe since Linux v4.x you fell victim to (or benefitted from, depending on your perspective) an effort to overhaul the DMA unmapping support. That patchset, and particularly the specific patch linked to here, show what PCI driver maintainers who were obliged to accommodate this rework were expected to do:
[3/3] PCI: remove pci_set_dma_max_seg_size
Fortunately for you, they gave specific examples of how existing drivers got patched and it's not bad. It should be pretty straightforward for you to figure out at least roughly the Linux version this change corresponds to around the 2018-19 date of the patch's acceptance upstream, code a new stanza in the Adaptec driver source to update it accordingly (e.g.
#if ((LINUX_VERSION_CODE > KERNEL_VERSION(5,1,0))
<patch Adaptec's code to use dma_set_max_seg_size() here>
#else
compile the driver and be on your way. Note that the README does not explicitly mention support for the Adaptec 6805e RAID controller yet, so if you manage to make it work and post your patch you should at least add a comment to the effect that you believe this supports the controller now.
Related
Recently I upgraded up to Ubuntu 16.04.1 Xenial (from 14.04 Trusty) the build-host where I've compiled different linux kernels so far for my own project. Ubuntu 16.04.1 implies using a new updated environment for building binaries. These tools include a new gcc-5.4, libc6 (for userspace applications), etc. Also a new Ubuntu supplies (or suggests) a new kernel-package containing a new make-kpkg script and pulling different dependencies like build-essential, binutils, etc. with it
Ok, my task is to compile a linux kernel v3.10.12 (or v3.19) and run it within a VirtualBox machine (architecture x86_64, system Ubuntu 16.04.1). I used to be able to compile kernel-v3.10.12 and kernel-v3.19 in Ubuntu 14.04 Trusty deployed on the build server with the compiler gcc-4.8 and launch the kernels under the VirtualBox machine I mentioned above, but now something goes wrong while starting a kernel compiled
For example, let's consider v3.10.12 being compiled and run
For building the kernel I utilize 'make-kpkg' script provided by Ubuntu aptitude's package 'kernel-package'. I build the kernel for x86_64 using gcc-4.8 as I have always been doing
Once 'make-kpkg' has compiled the kernel and gathered linux-headers it starts packing them into deb-packages what makes me able to execute 'dpkg -i' on them in the system and install them in a 'debian' way
Okey, supposing I did it. Then I am going to reboot the system
When I choose my compiled kernel in the grub menu, it writes in the screen "Loading linux kernel... Loading initial ramdisk", then the inscription disappears, the screen goes black and I see only a cursor in the form of underscore "_" sign in the top-left side of the screen. That's all. Nothing is going to happen further. The booting process seems to have stuck
I tried swapping make-kpkg for an old one (from Trusty), swapping compiler gcc-4.8.5 for gcc-4.9, gcc-4.7, even gcc-5.2 having made a couple of supplementations inside the directory include/linux/ for the support of gcc-5.2, but nothing has come off, the result still persists being the same
I tried the same actions (on the same Ubuntu 16.04.1 and tool-chain) with new kernels 4. series* (for example, 4.6) meaning building the kernels, packing them into *.deb packages and installing into the VirtualBox machine and rebooting the system, and everything goes correctly, I see debug messages in the screen like I have always seen. I tried to use gcc-4.7, gcc-4.8, gcc-4.9, gcc-5.4 and everything works, I am able to load the linux-kernel-v4.6 appropriately and completely. But when I build 3.10.12 (or 3.19) kernels I cannot boot them properly and cannot have figured out why it has been happening
Actually, what I have found out is that the deal is in the kernel but not in initrd because I managed to substitute the 'broken' kernel by a working one having left 'initrd' built together with the 'broken' kernel and the debug logging started appearing and the kernel was loading until a rootfs came out to be mounted, at that moment the kernel didn't manage to load it and left in initramfs mode
Has someone faced the same issue I am observing? Actually I am almost exhausted having been struggling with this trouble for days
Maybe someone has any recipes or suggestion how to get rid of the problem?
I even put the 'panic' function code exactly in the first line of the function "asmlinkage void __init start_kernel(void)" but nothing happened, still the same black screen
Can the problem be related to a new glibc being used by gcc compiling my kernel? Personally, I am not prone to think so but in the world of linux everything can happen. On the other hand maybe toolchain (ld, as) somehow has affected? I am kindly asking to provide me a help.
I am nearly assured that someone before me has already encountered such an issue, I would have been searching for a topic alike but didn't find anything resembling
Thank you in advance
Short Answer
It's a glibc kernel version mismatch, if you need this you could create the glibc package such that it supports the kernel version that you need, by using the --enable-kernel flag at configuration time.
Long Answer
It's highly likely that your glibc was compiled in such a way that it only works down to a certain version of linux. This is done with the help of the --enable-kernel flag at the configuration stage. Any version older than the one specified in --enable-kernel will be rejected by glibc as a consequence no program will ever be loaded, like the init program presumably systemd's init.
This is from the configuration help of glibc
--enable-kernel=version
This option is currently only
useful on GNU/Linux systems. The version parameter should have the form X.Y.Z and describes the smallest version of the Linux kernel the generated library is expected to support. The higher the version number is, the less compatibility code is added, and the faster the code gets.
Finally I succeeded in this problem
Actually what I have done is to have compiled an old gcc-4.8.5 with an old glibc-2.19 on the host-system where I build the old-versioned kernels.
Glibc-2.19 was compiled with an option --enable-kernel=3.10.12 and with headers of an old-versioned linux-3.10.12. The compiler has turned out to be like a 'cross-compiler' with usage of glibc-2.19. So, I built an old kernel with the version 3.10.12 with this 'cross-compiler', which uses glibc-2.19, and everything has started working in a proper way
Thanks for the help and directing me to a right way to solve the problem, but I am obliged to notice that the deal was in host-system's glibc used but not in target-system glibc used as I had been assumedly said (but maybe I misunderstood #iharob)
I have the requirement of altering packets as a part of my University's research project and came across two libraries. which are libnetfilter_queue and libipq which is the deprecated version. libnetfilter_queue documentation is next to zero on packet alteration and the only good documentation I came across is done via libipq.
Thus, when I run my code I get the error passer: Unable to create netlink socket: Protocol not supported which I found out that is due to the fact that libipq is not supported in the new linux kernels.
My query is, is there a work around to make libipq work with Ubuntu 12.04 LTS or any reference to documentation or tutorials that would help implement packet alteration via libnetfilter_queue.
I was at this for some days and could not find solution. you help will be very much appreciated. :)
Thank you very much :)
P.S: the question is also posted over here ( https://askubuntu.com/questions/430234/libipq-not-supported-in-ubuntu-12-04-lts )
Once the ip_queue module is gone, then you can't use libipq, as it leverages that module directly; so no, there's no workaround unless you install an older kernel that still has the ip_queue module.
That said, you've mentioned absolutely nothing about what you've actually tried. If you start from a basic libnetfilter_queue example, when you're setting the verdict, you should be using nfq_set_verdict, passing in the data_len and buf parameters containing the swizzled packet data.
I have trouble finding Oracle Call Interface for FreeBSD. I maybe missing something simple but I searched net for several days and finally ended up here with question.
My task is fairly simple: write a program in posix C that connects to an Oracle database and works on a FreeBSD machine. In worst case scenario I will drop the POSIX and FreeBSD part and make it work on Linux but so far my goal is to do this on BSD. Here is what I found so far:
ftp://ftp.atnet.ru/pub/OS/FreeBSD/oracle/otl/otl.htm
A GNU library which I have not tested yet, if anybody knows anything about it please do tell so:
http://sourceforge.net/projects/orclib/files/OCILIB%20Sources/3.12.1/
If you have any kind of suggestion of how this could be done better please do tell. Or even better if you have experience in this situation.
Oracle themselves do not support FreeBSD. There are ports of their Linux client-libraries, however, that are made to work on the OS:
databases/oracle8-client
databases/oracle7-client
Unfortunately, the above two are currently only working on i386, but you may be able to use the same technique as the port's author to massage the x86_64 Linux binaries to work under FreeBSD/amd64.
And then there is a port of the open-source ODBC driver in:
databases/oracle_odbc_driver
This one requires oracle8-client and is thus also i386-only at this time.
There is oracle instance client for Mac OS X. AFAIK Mac OS somehow related to FreeBSD codebase. So, perhaps, adaptation of Mac OS client would be easier then Linux one. (I didn't try it however).
I'm into something about writing a "Mock GPU driver" for Linux based systems. What I mean is that, simply I want to write a driver (Behind X-server obviously) to answer X's API calls with some debugging messages.
In other words I want to fool Linux about having an actual GPU. So I can make a test-bed for GUI-accelerated packages in console based systems.
Right now, if I execute a GUI-accelerated package in Linux console based systems; it'll simply dies due to lack of a real GPU (or a GPU driver better I'd say).
So I want to know:
Is it even possible? (Writing a GPU driver to fool Linux about having an actual GPU)
What resources do you recommend before getting my hands dirty in code?
Is there any similar projects around the net?
PS: I'm an experienced ANSI-C programmer but I don't have any clue in real Kernel/Driver development under *nix (read some tutorials about USB driver development though), so any resources about these areas will be really appreciated as well. Thanks in advance.
What you are looking for is actually part of Xorg server suite, and it is called Xvfb (virtual framebuffer).
If you're not afraid of a bit complex bash, you can take a look at Gentoo's virtualx.eclass for an use example (we use it to run tests which require X11).
A good place to start is the Mesa project - it implements OpenGL in software. It has a way to trick the OS into thinking that it is the OpenGL driver.
Question:
How to (where to find additional information i.e., examples) programatically create a pseudo device-node under /dev from a kernel module?
From your question I'm guessing your talking about Linux (since you are talking about kernel modules). In that case I'd strongly recommend reading Linux Device Driver. I'd recommend looking at chapter 14 to understand better how device work.
It should also be noted that in most current desktop and server distribution of Linux, udev is responsible for creating entries in /dev. You can configure udev with rules that allow you to create your the device node with a specific name and location. In the embedded world it might be mdev with busybox that's responsible for populating /dev or even it could simply be the deprecated devfs.
Linux Device Driver is certainly a must read. However, I would start with chapter 3, since it is a step by step example on how to create a char device driver.
The kernel API is a moving target. More than often, you will discover that some example that used to compile against a previous version of the kernel generates a warning or an error with a newer version. In this situation, being able to browse through the sources without getting lost is very useful.