.xinitrc commands don't last

Hello,
I'm seeing a strange behaviour on my 12.2-RELEASE-p1 (last updated today).
I'm using .xinitrc with startx to start my X session. It includes several xset commands, among them this one:
Code:
setxkbmap -layout 'us,fr(oss),ru' -variant -option \
grp:alt_shift_toggle,terminate:ctrl_alt_bksp,compose:ralt,lv3:menu_switch keypad:pointerkeys &
This adds a good layout switch method to my FVWM session, which lasts session long. I mean, normally, in all my installations (I have several). But in this particular installation it only lasts some short time! In some 20 minutes I can't switch keyboard layout anymore, neither can I end session with Ctrl+Alt+Backspace (terminate:ctrl_alt_bksp setting from the setxkbmap command).

Any idea what could be the cause of it?
 
There is something as a time out. I have stumbled over that some weeks ago. Otherwise I would not have been aware about that strange thing. Please see below what I have in my .xinitrc for the setting of the mouse keys not to expire.
Code:
xkbset m
xkbset exp '='m
This is not in xkbset(1) but in the help output you get by xkbset h.
 
Thank you! I'll try this.
But my main question here is not only how to prevent it, but also WHY this is happening in one installation, but not in any other :).
One difference of this installation against my other ones is that it uses precompiled packages from site. Normally I build my own ones with Synth. I'll give it a try.
 
But my main question here is not only how to prevent it, but also WHY this is happening in one installation, but not in any other :).
I have no idea. Initially I did not have that entry. There must have been a change somewhere last year. BTW: I am using packages running the RELEASE version of FreeBSD, currently FreeBSD-12.2 RELEASE. May be there are configurations or dependencies in the involved ports which trigger or disable the time out.
 
Is this a USB or Bluetooth keyboard? Maybe, for some reason, the connection is interrupted for a very short time (short enough that you don’t notice), causing the device driver to detach and attach it again, causing it to lose its settings. This should be logged in /var/log/messages, so you might want to check that.
 
Is this a USB or Bluetooth keyboard? Maybe, for some reason, the connection is interrupted for a very short time (short enough that you don’t notice), causing the device driver to detach and attach it again, causing it to lose its settings. This should be logged in /var/log/messages, so you might want to check that.
A USB keyboard. I'll check the log, thank you, good idea. For comparison, I have another 12.2 installation on the same machine, the only difference is that one was continually upgraded (freebsd-update) from 12.1, I think. So I'll see if this is happening there.
 
Well, it seems related to the new keyboard, after all. Who would think? Because I upgraded now to 13.0-alpha3, but the thing doesn't go away.
 
And? Did detach?
Yes, kind of. You see the message in dmesg output (I don't monitor it specifically on my desktop) like USB keyboard detached / attached etc. What surprises me is I have seen such messages before. But it never caused the problem described in this discussion.

I upgraded that installation to 13-alpha3 and still have that same thing. But I can swear to it, I NEVER had it on my other 12* installation on the same machine but which was incrementally updated by freebsd-update. Though I can't duplicate this on my main workstation because it uses PS2 type keyboard.
 
FreeBSD is getting non-deterministic. That begins with the installation, before running the kernel, with the boot loader.
Well there must be a cause of it anyway. I suspect a particular USB keyboard model (bought recently, here's the point).
 
FreeBSD is getting non-deterministic. That begins with the installation, before running the kernel, with the boot loader.
Actually I believe this trend isn't that new.

I realized that, to be able to use FreeBSD in office, I will have to maintain a custom kernel with some locked modules for my personal use, as it seems that an old bug in the suspend/resume routines (usage of uninitialized data structures) I reported more than three years ago including fix, apparently still has not been corrected.
Everybody knows that using uninitialized data structures with random content usually does not result in reliably deterministic behaviours.

As this bug is an annoying, but trivial-to-fix showstopper preventing reliable wake-up after sleep on computers with Nvidia cards, I just do not understand that there seems so little interest in fixing it.
Even if FreeBSD focus is on servers, I honestly think that the suspend/resume stuff might deserve a bit more attention, so people do not get an impression of total neglect.

Considering that the implementation of a suspend/resume framework has been paid by a sponsors' generous financial donation, I honestly do not know what I should think about the continuous inaction regarding fixing a showstopper bug affecting Nvidia users. Usage of uninitialized data structures in a kernel module seems no longer to be an issue requiring action.

(This is not intended as criticism! It is just saying what I do not understand.)
 
I realized that, to be able to use FreeBSD in office, I will have to maintain a custom kernel with some locked modules for my personal use, as it seems that an old bug in the suspend/resume routines (usage of uninitialized data structures) I reported more than three years ago including fix, apparently still has not been corrected.
Everybody knows that using uninitialized data structures with random content usually does not result in reliably deterministic behaviours.

As this bug is an annoying, but trivial-to-fix showstopper preventing reliable wake-up after sleep on computers with Nvidia cards, I just do not understand that there seems so little interest in fixing it.
Even if FreeBSD focus is on servers, I honestly think that the suspend/resume stuff might deserve a bit more attention, so people do not get an impression of total neglect.

Considering that the implementation of a suspend/resume framework has been paid by a sponsors' generous financial donation, I honestly do not know what I should think about the continuous inaction regarding fixing a showstopper bug affecting Nvidia users. Usage of uninitialized data structures in a kernel module seems no longer to be an issue requiring action.
This whole thread reads as a series of mutual misunderstandings, especially on your part.
 
This whole thread reads as a series of mutual misunderstandings, especially on your part.
Thank you for the information.
Your information would be more helpful/constructive if you could assist me regarding the question important to me "how can I get suspend/resume work with the standard kernel, without either removing or fixing vesa.ko?".

What do you think I misunderstand, what do I need to do to so that this issue gets solved in the standard kernel, so I no longer need to build a custom kernel, just to make things work as intended? I would thoroughly appreciate any hints.
 
The PR you linked to is very interesting, it reveals yet another issue of vt :)
You need to know, I have tried vt a few years ago for a short time, and went back to sc a few days later due to vt's bugs and its lack of functionality (history buffer size is very small, hard coded, thus not configurable without editing sources). So I am not a vt user.

However I think it is a different issue, as the issue I reported is not in vt, but in vesa.ko (which vt depends on).
On resuming there is a call into VGA BIOS that should not be done on Nvidia cards, because using a non-implemented BIOS function can yield unpredictable results that may depend on things like random memory or register contents, which result in a failed resume process.

A simple check (is nvidia? then skip that unsupported BIOS call) would be sufficient to fix the issue.

My (hopefully temporary) solution is to build kernel without vesa and vt, which I also add to the kernel module blacklist.
 
The PR you linked to is very interesting, it reveals yet another issue of vt :)
You need to know, I have tried vt a few years ago for a short time, and went back to sc a few days later due to vt's bugs and its lack of functionality (history buffer size is very small, hard coded, thus not configurable without editing sources). So I am not a vt user.
You state in the bug entry "Switching between X and text console fails, screen is garbled or no video at all", which is a well known vt issue. The sleep mode problem might not be, but that's not clear from your description.

However I think it is a different issue, as the issue I reported is not in vt, but in vesa.ko (which vt depends on).
On resuming there is a call into VGA BIOS that should not be done on Nvidia cards, because using a non-implemented BIOS function can yield unpredictable results that may depend on things like random memory or register contents, which result in a failed resume process.
It should be obvious I don't think there is anything wrong with Nvidia's BIOS or vesa.ko for that matter.

A simple check (is nvidia? then skip that unsupported BIOS call) would be sufficient to fix the issue.
If it were that simple, you probably would have a patch already. Do you?

My (hopefully temporary) solution is to build kernel without vesa and vt, which I also add to the kernel module blacklist.
…apparently not.
 
You state in the bug entry "Switching between X and text console fails, screen is garbled or no video at all", which is a well known vt issue. The sleep mode problem might not be, but that's not clear from your description.


It should be obvious I don't think there is anything wrong with Nvidia's BIOS or vesa.ko for that matter.


If it were that simple, you probably would have a patch already. Do you?


…apparently not.
If one uses sc instead of vt, then it just hangs in the text mode instead of switching to graphics mode, if, and only if vesa.ko with the bugged BIOS call is loaded.
This is clear proof that this particular issue roots in vesa.ko and not in vt.

The easiest temporary fix is, as I said, removing the vesa module. Easy if you do not care for vt anyway.

As I am not interested in vt as long as I am easily able to source mobos without UEFI or with non-UEFI option I have no incentive to use vt or vesa, both of which I do not see a need for.
I verified that this BIOS call is the problem by commenting it out.

For this reason I only have provided the fix - check the card type variable for "nvidia", and only call that BIOS function if it is not "nvidia".
Honestly, I do not see the necessity to submit a patch for such an extremely simple change.
So I just switched to using Linux for desktop things for three years until I got finally fed up from systemd and went back to FreeBSD.

The annoying thing when one is forced to use a custom kernel due to a bug not getting fixed for years is just that one has to rebuild and reinstall kernel every time one does freebsd-update.
So I maybe will provide a patch file when I am in the mood to work on some pending PRs, as Nvidia's great drivers shouldn't be impeded by a stupid kernel bug.

Anyway, there are always two sides of the medal :)
So this issue leads to a web based custom kernel configurator in my postinstaller, and this is a good thing :)
 
...
Honestly, I do not see the necessity to submit a patch for such an extremely simple change.
...
But why WON'T you submit a patch, then? You have already invested your time & energies into submitting a PR and finding a way out, why not make it public? That would be a logical conclusion and the responsibility henceforth with be laid on other shoulders...

Human factor interferes at times. So is it not possible, for that matter, that by not submitting your patch you only follow the trend?

I mean, some isolated incidents don't mean FreeBSD team is just THAT BAD... I remember, some 8 years ago (well, as far back as they don't keep the messages on the forum) I DID have a very unpleasant problem with the (re) driver: NIC would appear to be working while actually not usable. And that was a Realtek chip widely used in m/b's at that time.
And I had a rather unfortunate experience trying to report that bug, which ended up in nobody paying any more attention to it after my report. I was lucky enough to google-find some rather old proprietary Realtek driver for FreeBSD (version 4.8 or something). I"m not a programmer, but the code looked similar to (re), so I made up a dirty hybrid of that one and (re), and it built and worked... I still have that motherboard, but (re) was fixed a while ago.
 
I want to apologize in case people get the impression I consider the FreeBSD team bad.
No, not at all. It is just a matter of resources and priorities.

The issue is a bit more complicated from the normal users' (i.e. non-kernel-programmers') viewpoint.
Modifying the /usr/src/sys/dev/fb/vesa.c alone and then build/install the kernel is easy.
This was the way I found out that disabling/commenting out the BIOS call in line 520 fixes the hang issue on nvidia cards and produces reliable resume after suspend.

So, as said, the (pseudocode) fix is:
Code:
(+)if (! nvidia_card_is_installed) {
    x86bios_intr(&regs, 0x10);
(+)}
In the module and some other related modules there are video-related information similar those from pciconf in complex data structures.
It would take me hours, maybe days of looking through countless source files to find out how to write the expression (nvidia_card_is_installed) in real code.
After mastering this challenge, I still would need to learn how to make proper patchfiles for FreeBSD.

So I would have to spend days to provide a patchfile that does just what I described in the pseudocode above.
For people familiar with kernel programming all this would only take minutes.


So I beg for understanding that in this situation, as a normal dumb user and no kernel guru, I feel unable to comply by providing a patch file.
This is a challenge too big for my motivation, as the easy way to have suspend/resume work is building a custom kernel without vesa.ko.

P.S.: The Realtek drivers are another story... they have drivers on their site, and in my experience sometimes the one in FreeBSD, and sometimes a driver from the Realtek site works (or not). I soon preferred to generally use Intel PCI network cards instead of the poor-performance Realtek chips.
 
The fact remains you aren't using the patch you are advertising. How do you expect to convince anyone that it is working is beyond me.

As I am not interested in vt as long as I am easily able to source mobos without UEFI or with non-UEFI option I have no incentive to use vt or vesa, both of which I do not see a need for.
I verified that this BIOS call is the problem by commenting it out.
You did? This is the first time in years you are actually claiming that.

This was the way I found out that disabling/commenting out the BIOS call in line 520 fixes the hang issue on nvidia cards and produces reliable resume after suspend.

So, as said, the (pseudocode) fix is:
Code:
(+)if (! nvidia_card_is_installed) {
    x86bios_intr(&regs, 0x10);
(+)}
In the module and some other related modules there are video-related information similar those from pciconf in complex data structures.
This isn't mentioned in PR 224069 at all (it's "uncomment /* regs.R_DL = STATE_SIZE; */" instead), no wonder everyone there is completely confused what do you want them to fix.
 
shkhln Later in the PR talk with jkim, the supposed author of vesa.ko, it seems to me that it is obvious that the mentioned BIOS call does no good, and that it needs to be skipped if nvidia card is found installed.

You seem to be correct stating that I failed to make that clear.
I will possibly try another attempt updating the PR in the next autumn, if nobody with better communications skills jumps in before and finds the right wording that causes the addition of such an if check around /usr/src/sys/dev/fb/vesa.c line 520.
 
Back
Top