On Nov 29 14:48:47, Torsten Valentin wrote: > > So why don't you show us the dmesg > > of the most recent kernel that worked for you? > > Because I don't see what that has to do with the issue.
If the "issue" still is to get OpenBSD running on that hardware, then here is what it has to do with the issue: it might get you running OpenBSD on that hardware. > I'm not looking > for that one line that's missing in my current config files. I'm not > hoping for someone to tell me that I should include line #5 and then it > will work. > > Instead I was hoping to learn a way how to find out myself which lines > must be included (and which in my case don't need to). Ah, so it's adifferent "issue". Here is a way: include everuthing GENERIC includes (or better, include everything your last good running kernel included), and start stripping it line by line. Once you show us a dmesg of a kernel you run on that hardware (you say you do so since 3.8, right?), I might start believing you did that, and had reasons to do that. > Quite what Andres > Perera explained in his first reply. Just that Adres' explanation > obviously cannot be the complete answer or at least I didn't fully > understand it. > > To really get a minimal kernel, I'm going bottom up, not top down. I'm > not deleting lines from "GENERIC" but I'm copying lines from GENERIC to > an empty file. So there is no "go back one step to where it worked the > last time". The way you have been advised, you arrive at a minimal kernel from above. What problem do you have with that? > Though it might be a lot of work, there must be a solution to this issue. Yes; see above; then do it; yes, it is a lot of tedious work. > > "The npx driver is required for proper system functioning regardless > > of whether or not an NPX is present." > > > > so there's no 1:1 mapping between the devices you have and the ones > > you may need included in the kernel config. could potentially apply to > > other drivers, so why waste time figuring out which ones fall under > > this category and which ones don't? > > To me it seems like this is the real question that I'm facing: To which > drivers does this apply? Answering this question requires an intimate knowledge of the kernel's internals, which you don't have (I don't either). > Also please understand that it will not help if I explained why there is > no way to use GENERIC and why the hardware cannot be changed. If you showed us your previous dmesg, we wouldn't have to ask you what the hardware is. > be a long story which in the end would lead to nothing... except wasting > time. ... and showing those you ask for help what that exotic hardware of yours actually is. Right?
