Re: [gentoo-user] LXDE startup error
Peter Humphrey wrote: On Friday 17 Mar 2017 09:49:14 Mick wrote: I don't have a fix for you, but from the errors it seems pam is not happy. Display Managers and various services install pam modules in /etc/pam.d/ to manage user authentication. It seems something is amiss there, or some kind of conflict between gnome-keyring and LXDE. Yes, I see that. I also see a lot of stuff that may be causing it. I deleted .cache/lxsessions/LXDE/run.log, ran startx and immediately logged out, and this is what I found (sorry, it's 110 lines): $ cat run.log So it looks as though something hasn't been installed right. I'm running an emerge -e world at the moment to see if I can pick something up from it. I don't see anything strange in your log; LXDE should start even without notification-deamon installed. Is there anything strange in /var/log/X.org.0.log? "ran startx and immediately logged out": do you use a login manager? raffaele
Re: [gentoo-user] Slightly OT - My new SSD.
> That, indeed, seems to to be the case. When I do cat /proc/interrupts | > egrep '(CPU/nvm)', I get just the header line with one data line: > >CPU0 CPU1 CPU2 CPU3 > 17: 0 0 15 14605 IO-APIC 17-fasteoi > ehci_hcd:usb1, nvme0q0, nvme0q1 > > I'm kind of feeling a bit out of my depth here. What are the nvme0q0, > etc.? "Queues" of some kind? You appear to have nine of these things, > I've just got two. I'm sure there's a fine manual I ought to be > reading. Do you know where I might find this manual? > Can't remember where i read up on this. Might have been troubleshooting poor small packet performance on a firewall (some network drivers can have multiqueue too). Maybe start with this; https://www.thomas-krenn.com/en/wiki/Linux_Multi-Queue_Block_IO_Queueing_Mechanism_(blk-mq) It looks like the nvme driver was made "mutliqueue" in kernel 3.19. FWIW my system is 8 core (AMD 8350). Its odd having two queues on the same interrupt, but I have the same for q0 and q1, but on your system i'd say there should be some queues on other interrupts to they can be serviced by other cores, so that doesnt look right. Do you have MSI enabled? Bus options -> PCI Support -> Message Signaled Interrupts (MSI and MSI-X) If your system is not too old you may get more interrupts or a better spread with that enabled. When I look at the entire /proc/interrupts, there are just 30 lines > listed, and I suspect there are no more than 32 interrupt numbers > available. Is there any way I can configure Linux to give my SSD more > than one interrupt line to work with? > > > FWIW > > # hdparm -tT /dev/nvme0n1 > > > /dev/nvme0n1: > > Timing cached reads: 9884 MB in 2.00 seconds = 4945.35 MB/sec > > Timing buffered disk reads: 4506 MB in 3.00 seconds = 1501.84 MB/sec > > I get: > > /dev/nvme0n1: > Timing cached reads: 4248 MB in 2.00 seconds = 2124.01 MB/sec > Timing buffered disk reads: 1214 MB in 3.00 seconds = 404.51 MB/sec > > So my "cached reads" speed is (a little under) half of yours. This is > to be expected, since my PCIe lanes are only version 2 (and yours are > probably version 3). FWIW the motherboard manual says it has PCIe 2.0 x16 slots. Agree that cache speed is likely a hardware issue. > But the "buffered disk read" are much slower. Is > this just the age of my PC, or might I have something suboptimally > configured? > You look like you're getting SATA speeds, but since you have the nvme device, i guess that implies you havent fallen back to SATA. Could well be older hardware or less PCIe slots/lanes.
Re: [gentoo-user] Re: Steam downloading extremely
Hi Kai, Oops, fixed? I just updated my system and tried to randomly download another game and it looks fine... Weird. Anyway, thanks for you guys. May the good code be with you. Danny On 2017-03-19 19:11, Kai Krakow wrote: > Am Thu, 16 Mar 2017 14:04:14 +0800 > schrieb Danny YUE : > >> Hi Kai, >> >> Thanks for your help :-) >> >> Code here: >> /usr/share/info $ cat /proc/sys/net/ipv4/tcp_fastopen >> 1 >> /usr/share/info $ cat /proc/sys/net/core/default_qdisc >> pfifo_fast >> /usr/share/info $ cat /proc/sys/net/ipv4/tcp_congestion_control >> cubic >> >> dnsmasq may help because...if my understanding is correct, Steam Linux >> client has a bug that it tries to query the DNS too often during >> downloading, then its request got throttled. Please see >> https://wiki.gentoo.org/wiki/Steam/Client_troubleshooting >> Section "Slow download speeds". > > This has been fixed with the March 9th 2017 Update. It's in the current > stable client. > >> For disk, I don't think it fits my case because for a downloading >> speed of 100KB/s, disk write should not be a bottleneck. > > Well, it still can be if there's a lot of data backlogged and the > writeback cache of the kernel is saturated. > >> I suspect it is related to Linux client because Steam Windows client >> on my machine downloads at the normal speed... > > This makes sense... However, here the linux client is downloading at 48 > mbytes/s which is pretty much the maximum of my 400 mbit link. > > So, if it is still slow for you, there seem to be other issues. > >> Well, I am not that familiar with network tuning things...so I will >> definitely check the methods you mentioned. > > Feel free to ask. > >> On 2017-03-15 21:07, Kai Krakow wrote: >> > Am Wed, 15 Mar 2017 21:53:44 +0100 >> > schrieb Kai Krakow : >> > >> >> Am Wed, 15 Mar 2017 21:24:10 +0800 >> >> schrieb Danny YUE : >> >> >> [...] >> >> >> >> Here, it's downloading with peak bandwidths of 48 mbytes/s but >> >> usually it's around 38 mbytes/s. However, I sometimes see >> >> slowdowns, too. I guess that games are downloaded file by file, >> >> and when a lot of small files are left in the queue, it just >> >> cannot get good bandwidth. >> >> >> >> But I only see such slowdowns mostly short before the last few >> >> megabytes of a game. >> >> >> >> Could you check if your downloaded games consist of many smallish >> >> files? Then that could be the explanation. >> >> >> >> You could try activating fq_codel and tcp fastopen: >> >> >> >> In /proc/sys/net/ipv4/tcp_fastopen it should say 1. >> >> In /proc/sys/net/core/default_qdisc it should say fq_codel. >> >> >> >> Also, you may want to try out bbr congestion control: >> >> >> >> In /proc/sys/net/ipv4/tcp_congestion_control it should say bbr. >> >> >> >> By recompiling the kernel, you can reconfigure the defaults for >> >> this (and enable support). Some of these need modern kernels. >> >> >> >> Additionally, many small tcp request need a good portion of your >> >> upload bandwidth and are very dependent on good round trip times. >> >> Traditional DSL lines with ping times of 50-60ms can really slow >> >> down requests of small files a lot due to three-way tcp >> >> handshaking, that is, you could request only one smallish file per >> >> 100-120ms. This can totally destroy the usable bandwidth. Maybe >> >> watch a running ping while the downloads are running. If the ping >> >> times increase while the download slows down, your bottleneck is >> >> the upload. >> >> >> >> But also keep in mind that traditional spinning disks may not keep >> >> up with the bandwidth if confronted with many small files. If >> >> you're using SSD all should be fine. I'm running on bcache with >> >> writeback caching which gives a really good performance boost by >> >> adding a small SSD to one or more big HDDs. >> > >> > BTW: I don't see how dnsmasq could help you here... It can do >> > nothing about bandwidth. It only acts as a DNS cache which helps >> > keeping latency of the DNS resolver down. But this doesn't matter >> > here because during download, steam won't do many DNS requests. >> > >> > As already stated, part of the problem may be the upload, and/or bad >> > queue handling within your broadband router. You can work around it >> > with a traffic shaper and throttling upload below what's physically >> > possible with your internet line, thus keeping the queue in front >> > of the broadband router. That way, a traffic shaper could handle it >> > and work around bad queue handling. >> > >> > To resolve the issue it is important to sophistically test the >> > suggestions one step at a time, starting with the easy ones, and do >> > your measurements. >> >>
Re: [gentoo-user] Shell echo missing after ctrl+c
Walter Dnes wrote: > On Sun, Mar 19, 2017 at 09:49:50AM +0100, Kai Krakow wrote >> Hello! >> >> More and more of my Gentoo systems are exhibiting the following >> strange and unexpected behavior: >> >> After ctrl+c'ing out of programs like tailf, SSH password prompts, in >> the middle of a shell scripts, the shell echo is not restored - that >> is: If I type characters I no longer see the characters (but they are >> received and can be executed by "enter"). If experiencing this, I have >> to ctrl+c again to discard what I was typing, the blindly type "reset" >> to reset the terminal, then echo is enabled again. > "It's not a bug; it's a feature". It's caused by some programs. See > http://askubuntu.com/questions/171449/shell-does-not-show-typed-in-commands-reset-works-but-what-happened > for a detailed explanation. Executive summary... some programs, e.g. > vim, can be run from the command line, and they accept certain control > characters (CTRL-V, CTRL-I, etc) as valid input. These characters would > normally be echo'd back to the user's terminal by the kernel's tty > subsystem. This would foul up the application's screen display. To > avoid that, the application turns off echoing to the tty when it starts > up. It also restores echoing ***IF IT EXITS PROPERLY***. This also > applies to when a program issues a password prompt, where you obviously > want echoing turned off. If killed with CTRL-C or "kill -9" or "kill > -15", it doesn't have a chance to restore echoing, and you get the > situation you described. > So, it was intentional. Why am I not surprised. It's still annoying. I can see why they did it based on your post but it's still annoying. Dale :-) :-)
Re: [gentoo-user] Shell echo missing after ctrl+c
On Sun, Mar 19, 2017 at 09:49:50AM +0100, Kai Krakow wrote > Hello! > > More and more of my Gentoo systems are exhibiting the following > strange and unexpected behavior: > > After ctrl+c'ing out of programs like tailf, SSH password prompts, in > the middle of a shell scripts, the shell echo is not restored - that > is: If I type characters I no longer see the characters (but they are > received and can be executed by "enter"). If experiencing this, I have > to ctrl+c again to discard what I was typing, the blindly type "reset" > to reset the terminal, then echo is enabled again. "It's not a bug; it's a feature". It's caused by some programs. See http://askubuntu.com/questions/171449/shell-does-not-show-typed-in-commands-reset-works-but-what-happened for a detailed explanation. Executive summary... some programs, e.g. vim, can be run from the command line, and they accept certain control characters (CTRL-V, CTRL-I, etc) as valid input. These characters would normally be echo'd back to the user's terminal by the kernel's tty subsystem. This would foul up the application's screen display. To avoid that, the application turns off echoing to the tty when it starts up. It also restores echoing ***IF IT EXITS PROPERLY***. This also applies to when a program issues a password prompt, where you obviously want echoing turned off. If killed with CTRL-C or "kill -9" or "kill -15", it doesn't have a chance to restore echoing, and you get the situation you described. -- Walter Dnes I don't run "desktop environments"; I run useful applications
[gentoo-user] Re: Re: Flashing hardware via WINE ?
tu...@posteo.de wrote: [snip] > Hi Kai (that's a rhyme! :) > > I have installed Virtualbox already and use the Linux Image I > installed there for banking purposes only. Feels more secure. > > I would prefer the WIndows-in-a-(virtual)box-solution) as you > do -- if I would own a Windows installation disc. But do not. You might give ReactOS a try: https://www.reactos.org/ Works for me in a VBox, but I have no idea if serial ports are supported. [snip] Cheers, Jörg
Re: [gentoo-user] mpv startup times...is this guy waiting for soemthing ?
> On 18 Mar 2017, at 18:44, tu...@posteo.de wrote: > > Starting mpv as root "fixes" the problem...so it is > a permission problem (see my second mail). Can't find your second mail, but a different user has a different _environment_, as well as different permissions. Stroller.
[gentoo-user] Re: Steam downloading extremely
Am Thu, 16 Mar 2017 14:04:14 +0800 schrieb Danny YUE : > Hi Kai, > > Thanks for your help :-) > > Code here: > /usr/share/info $ cat /proc/sys/net/ipv4/tcp_fastopen > 1 > /usr/share/info $ cat /proc/sys/net/core/default_qdisc > pfifo_fast > /usr/share/info $ cat /proc/sys/net/ipv4/tcp_congestion_control > cubic > > dnsmasq may help because...if my understanding is correct, Steam Linux > client has a bug that it tries to query the DNS too often during > downloading, then its request got throttled. Please see > https://wiki.gentoo.org/wiki/Steam/Client_troubleshooting > Section "Slow download speeds". This has been fixed with the March 9th 2017 Update. It's in the current stable client. > For disk, I don't think it fits my case because for a downloading > speed of 100KB/s, disk write should not be a bottleneck. Well, it still can be if there's a lot of data backlogged and the writeback cache of the kernel is saturated. > I suspect it is related to Linux client because Steam Windows client > on my machine downloads at the normal speed... This makes sense... However, here the linux client is downloading at 48 mbytes/s which is pretty much the maximum of my 400 mbit link. So, if it is still slow for you, there seem to be other issues. > Well, I am not that familiar with network tuning things...so I will > definitely check the methods you mentioned. Feel free to ask. > On 2017-03-15 21:07, Kai Krakow wrote: > > Am Wed, 15 Mar 2017 21:53:44 +0100 > > schrieb Kai Krakow : > > > >> Am Wed, 15 Mar 2017 21:24:10 +0800 > >> schrieb Danny YUE : > >> > [...] > >> > >> Here, it's downloading with peak bandwidths of 48 mbytes/s but > >> usually it's around 38 mbytes/s. However, I sometimes see > >> slowdowns, too. I guess that games are downloaded file by file, > >> and when a lot of small files are left in the queue, it just > >> cannot get good bandwidth. > >> > >> But I only see such slowdowns mostly short before the last few > >> megabytes of a game. > >> > >> Could you check if your downloaded games consist of many smallish > >> files? Then that could be the explanation. > >> > >> You could try activating fq_codel and tcp fastopen: > >> > >> In /proc/sys/net/ipv4/tcp_fastopen it should say 1. > >> In /proc/sys/net/core/default_qdisc it should say fq_codel. > >> > >> Also, you may want to try out bbr congestion control: > >> > >> In /proc/sys/net/ipv4/tcp_congestion_control it should say bbr. > >> > >> By recompiling the kernel, you can reconfigure the defaults for > >> this (and enable support). Some of these need modern kernels. > >> > >> Additionally, many small tcp request need a good portion of your > >> upload bandwidth and are very dependent on good round trip times. > >> Traditional DSL lines with ping times of 50-60ms can really slow > >> down requests of small files a lot due to three-way tcp > >> handshaking, that is, you could request only one smallish file per > >> 100-120ms. This can totally destroy the usable bandwidth. Maybe > >> watch a running ping while the downloads are running. If the ping > >> times increase while the download slows down, your bottleneck is > >> the upload. > >> > >> But also keep in mind that traditional spinning disks may not keep > >> up with the bandwidth if confronted with many small files. If > >> you're using SSD all should be fine. I'm running on bcache with > >> writeback caching which gives a really good performance boost by > >> adding a small SSD to one or more big HDDs. > > > > BTW: I don't see how dnsmasq could help you here... It can do > > nothing about bandwidth. It only acts as a DNS cache which helps > > keeping latency of the DNS resolver down. But this doesn't matter > > here because during download, steam won't do many DNS requests. > > > > As already stated, part of the problem may be the upload, and/or bad > > queue handling within your broadband router. You can work around it > > with a traffic shaper and throttling upload below what's physically > > possible with your internet line, thus keeping the queue in front > > of the broadband router. That way, a traffic shaper could handle it > > and work around bad queue handling. > > > > To resolve the issue it is important to sophistically test the > > suggestions one step at a time, starting with the easy ones, and do > > your measurements. > > -- Regards, Kai Replies to list-only preferred.
[gentoo-user] Re: Shell echo missing after ctrl+c
Am Sun, 19 Mar 2017 14:50:14 + schrieb Peter Humphrey : > On Sunday 19 Mar 2017 10:59:45 Mick wrote: > > > Not sure this will help, but none of my systems have this problem. > > urxvt, xterm, konsole, terminology, all display anything I enter in > > the keyboard after I have pressed Ctrl+c. I run enlightenment, or > > fluxbox, I have not tried with the plasma DE yet. > > I'm using plasma and I don't have any problem with CTRL-C. Well, > unless I'm interrupting something so deeply nested in the call stack > that there's no way back out all the way to the command line, as > happens sometimes when emerging -j . Then I have to kill > Konsole and start it again. I thought this was fixed by emerge using cgroups? -- Regards, Kai Replies to list-only preferred.
Re: [gentoo-user] Re: Shell echo missing after ctrl+c
On Sun, 19 Mar 2017 16:37:50 +, Peter Humphrey wrote: > > > I'm using plasma and I don't have any problem with CTRL-C. Well, > > > unless I'm interrupting something so deeply nested in the call > > > stack that there's no way back out all the way to the command line, > > > as happens sometimes when emerging -j . Then I have to kill > > > Konsole and start it again. > > > > kill -9 works for me in that situation. > > Yes, that's what I meant. Sometimes I can pick out the process holding > things up, other times I can't reliably and kill the konsole containing > it, preferring not to resort to guesswork with such a sharp knife. :8 pgrep --full --list-full emerge works for emerge processes. So far, I haven't killed the wrong process... so far. -- Neil Bothwick Theory is when you know everything, but nothing works. Reality is when everything works, but you don't know why. However, usually theory and reality are mixed together : Nothing works, and nobody knows why not. pgpDde5octlvk.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: Shell echo missing after ctrl+c
On Sunday 19 Mar 2017 16:23:34 Neil Bothwick wrote: > On Sun, 19 Mar 2017 14:50:14 +, Peter Humphrey wrote: > > I'm using plasma and I don't have any problem with CTRL-C. Well, unless > > I'm interrupting something so deeply nested in the call stack that > > there's no way back out all the way to the command line, as happens > > sometimes when emerging -j . Then I have to kill Konsole and > > start it again. > > kill -9 works for me in that situation. Yes, that's what I meant. Sometimes I can pick out the process holding things up, other times I can't reliably and kill the konsole containing it, preferring not to resort to guesswork with such a sharp knife. :8 > I also don't see the behaviour described by the others. -- Regards Peter
Re: [gentoo-user] Re: Shell echo missing after ctrl+c
On Sun, 19 Mar 2017 14:50:14 +, Peter Humphrey wrote: > I'm using plasma and I don't have any problem with CTRL-C. Well, unless > I'm interrupting something so deeply nested in the call stack that > there's no way back out all the way to the command line, as happens > sometimes when emerging -j . Then I have to kill Konsole and > start it again. kill -9 works for me in that situation. I also don't see the behaviour described by the others. -- Neil Bothwick Get your grubby hands off my tagline! I stole it first! pgp14D_Y_Uug_.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Shell echo missing after ctrl+c
On 03/19/2017 04:37 AM, Alan Mackenzie wrote: > Hello, Kai. > > On Sun, Mar 19, 2017 at 09:49:50 +0100, Kai Krakow wrote: >> Hello! > >> More and more of my Gentoo systems are exhibiting the following >> strange and unexpected behavior: > >> After ctrl+c'ing out of programs like tailf, SSH password prompts, in >> the middle of a shell scripts, the shell echo is not restored - that >> is: If I type characters I no longer see the characters (but they are >> received and can be executed by "enter"). If experiencing this, I have >> to ctrl+c again to discard what I was typing, the blindly type "reset" >> to reset the terminal, then echo is enabled again. > >> I'm not sure which update or configuration is causing this. It started >> out on our Gentoo servers some years ago (which I'm only SSH'ed into, >> no physical access), now since a few weeks, also my desktop machines are >> affected. I have no explanation for this. > >> But maybe anyone? > >> BTW: I know from the old times (some 15-20 years ago) that ctrl+c out >> of a program (i.e. rsync) that starts a subshell (i.e. ssh) that in >> turn shows a password prompt, will leave you with an echoless shell. >> But it shows up on almost any occasion now. > > It's been happening to me increasingly often in the last few > months/years. I don't like it. > > Here is a recipe for reproducing the phenomenon. A typical way of > invoking patch is by supplying the patch file to standard input: > > $ patch --dry-run < some-patch-file.diff > > . However if you accidentally omit the "<", like this: > > $ patch --dry-run some-patch-file.diff > > , the terminal will await you typing in the patch file. Instead, do a > ctrl-c. This leaves the terminal not echoing keystrokes. > > By the way, thanks for educating me about the existence of the command > `reset'. :-) > `stty echo` will probably fix it as well. I haven't seen this problem but I can reproduce it. It seems to rely on programs/scripts interrupting break and setting the terminal settings back the way they were. If a program/script does not do this properly, and it changes the tty echo state, it leaves echo off as well. When it happens, if you run `stty -a` do you see "-echo" in the results? If you do, whatever you ran turned echo off and didn't restore it on abort. If you want you can turn it off yourself using `stty -echo` for testing. The question is, is this the responsibility of bash itself after a script terminates? Dan
Re: [gentoo-user] Re: Shell echo missing after ctrl+c
On Sunday 19 Mar 2017 10:59:45 Mick wrote: > Not sure this will help, but none of my systems have this problem. urxvt, > xterm, konsole, terminology, all display anything I enter in the keyboard > after I have pressed Ctrl+c. I run enlightenment, or fluxbox, I have not > tried with the plasma DE yet. I'm using plasma and I don't have any problem with CTRL-C. Well, unless I'm interrupting something so deeply nested in the call stack that there's no way back out all the way to the command line, as happens sometimes when emerging -j . Then I have to kill Konsole and start it again. -- Regards Peter
[gentoo-user] Re: Flashing hardware via WINE ?
On 2017-03-19, tu...@posteo.de wrote: > yes...no chance. > Linux is insecure...you know. > It makes it possible to spy the firmware and decrypt it on > the way to the charger. > > Windows is much more secure. Wow. It's actually much easier to grab serial data on Windows (using sysinternals 'portmon') than it is on Linux (you can do it with strace, but it's not easy). > Earth is flat and there was no landing on the moon. > > I believe in Santa Claus. -- Grant
[gentoo-user] Re: Shell echo missing after ctrl+c
Am Sun, 19 Mar 2017 10:17:02 +0100 schrieb Matthias Hanft : > Kai Krakow wrote: > > > > After ctrl+c'ing out of programs like tailf, SSH password prompts, > > in the middle of a shell scripts, the shell echo is not restored > > Not here, but something similar: Immediately after ctrl+c'ing, no > shell prompt is displayed (in fact, *nothing* is displayed) - but > it's just the display; I can enter a shell command (with echo, too) > which will be executed properly. Or just press the RETURN key on the > empty line to get the shell prompt again. > > This happens just on a single of my Gentoo systems (and not always, > but very often). > > Any idea? Yes, this can sneak upon you if you ctrl+c a program with child processes, and part of the teardown is that a child displays a line after control has already been returned to the shell. What happens now is: Your shell displays the prompt, the child process echos a carriage return and echos text, overwriting your prompt, and putting a newline, child now also exits. If your prompt was long enough, you may still see the rest of it. You end up with a sole blinking cursor on an empty line. Hitting enter produces a new shell prompt. There's no way to work around it except by maybe putting a sleep inside the PS1 variable. But I'm sure you don't want that. ;-) Tho, thinking about this, your case may have the same underlying bug in common: delayed termination of child processes. -- Regards, Kai Replies to list-only preferred.
Re: [gentoo-user] Re: Shell echo missing after ctrl+c
Kai Krakow wrote: > Am Sun, 19 Mar 2017 06:27:15 -0500 > schrieb Dale : > > > > Here is mine: > > root@fireball / # uname -r > 4.5.2-gentoo > root@fireball / # > > As far as I know, I use bash. If you are talking about what I think > you are talking about. > Yes, that's what I was talking about. > > Run ps, it should tell you the processes running in your current shell, > including the shell itself: > > # ps > PID TTY TIME CMD > 1256 pts/200:00:00 ps > 32059 pts/200:00:00 bash > > And you can see your default shell this way: > > # realpath /bin/sh > /bin/dash > > Yes, dash for me, because it spawns much faster than bash, at least > when running scripts. This can make a big difference with openrc. > Meanwhile, I'm using systemd. root@fireball / # ps | grep bash 8515 pts/000:00:00 bash root@fireball / # realpath /bin/sh /bin/bash root@fireball / # Looks like bash for me. >> [IP-] [ ] app-shells/bash-4.3_p48-r1:0 > Here, too: > > # equery list bash > [IP-] [ ] app-shells/bash-4.3_p48-r1:0 > >> Given the age of your kernel, maybe it is above that level anyway. I >> don't update my kernel often either. >> >> I'm going to be watching this thread tho. If I can share info which >> may help narrow things down, I'll do that for sure. > The problem is that this bug is totally non-deterministic... It fails > once, next try it works as it should. > > If you can work out a way to reliably reproduce this bug, let me know. > Then I'll try to work out what the problem is. > I think our other Alan posted a way to reproduce it. I see you replied so maybe his post will help and I'll read your reply next. Maybe if we share enough between several of us, we can at least rule out some stuff and narrow it down a bit. Dale :-) :-)
[gentoo-user] Re: modules-load restart
Am Thu, 16 Mar 2017 18:11:33 -0600 schrieb the...@sys-concept.com: > On 03/16/2017 12:51 PM, Alan McKinnon wrote: > > On 16/03/2017 20:04, the...@sys-concept.com wrote: > >> I compiled as module: it87 > >> run: > >> make > >> make modules_prepare > >> make modules_install > >> ... > >> INSTALL drivers/hwmon/it87.ko > >> > >> add "it87" to modules.conf > >> > >> but running: /etc/init.d/modules-load restart > >> does not restart the module. > >> > >> Do I need to restart the box, this procedure work on a different > >> box without restart. > >> > > > > > > What is the correct module name? It does not have to match the file > > name. > > I compile this as module: > > CONFIG_SENSORS_IT87=m > > I did the same on my other computer, add to: /etc/conf.d/modules > it87 > > and modules-load restart worked. You need to fix two things on the affected system: First, changes to /etc/conf.d/modules affect /etc/init.d/modules but not /etc/init.d/modules-load. Then, fix your syntax: You're overwriting the modules= assignment with each line. Your changes have no effect because you are confusing yourself (and even others here): 1. There a module autoloader and depmod, modules may be autoloaded 2. There's modules-load and modules 3. Each have their own config file and init script 4. Use the correct pair of config/init script when doing changes -- Regards, Kai Replies to list-only preferred.
[gentoo-user] Re: modules-load restart
Am Sat, 18 Mar 2017 22:31:44 + schrieb Neil Bothwick : > On Fri, 17 Mar 2017 17:28:27 +, David W Noon wrote: > > > > cat /etc/conf.d/modules > > > modules="vboxdrv vboxnetflt vboxnetadp vboxpci" > > > modules="it87" > > > > The above syntax is incorrect. > > > > To use multiple lines, you need to re-interpolate the modules > > variable, thus: > > > > modules="vboxdrv vboxnetflt vboxnetadp vboxpci" > > modules="${modules} it87" > > > > Otherwise the second assignment deletes the module list from the > > first assignment. > > If that were true, it87 would be the only module loaded, not the only > module not loaded. This is only a wrong assumption... His reload command is using a different configuration file. > The comments in the file show multiple module definitions without > explicitly adding the previous values. -- Regards, Kai Replies to list-only preferred. pgpMRwVfTNz9h.pgp Description: Digitale Signatur von OpenPGP
[gentoo-user] Re: Shell echo missing after ctrl+c
Am Sun, 19 Mar 2017 11:37:56 + schrieb Alan Mackenzie : > Hello, Kai. > > On Sun, Mar 19, 2017 at 09:49:50 +0100, Kai Krakow wrote: > > Hello! > > > More and more of my Gentoo systems are exhibiting the following > > strange and unexpected behavior: > > > After ctrl+c'ing out of programs like tailf, SSH password prompts, > > in the middle of a shell scripts, the shell echo is not restored - > > that is: If I type characters I no longer see the characters (but > > they are received and can be executed by "enter"). If experiencing > > this, I have to ctrl+c again to discard what I was typing, the > > blindly type "reset" to reset the terminal, then echo is enabled > > again. > > > I'm not sure which update or configuration is causing this. It > > started out on our Gentoo servers some years ago (which I'm only > > SSH'ed into, no physical access), now since a few weeks, also my > > desktop machines are affected. I have no explanation for this. > > > But maybe anyone? > > > BTW: I know from the old times (some 15-20 years ago) that ctrl+c > > out of a program (i.e. rsync) that starts a subshell (i.e. ssh) > > that in turn shows a password prompt, will leave you with an > > echoless shell. But it shows up on almost any occasion now. > > It's been happening to me increasingly often in the last few > months/years. I don't like it. Me neither, getting on my nerves. > Here is a recipe for reproducing the phenomenon. A typical way of > invoking patch is by supplying the patch file to standard input: > > $ patch --dry-run < some-patch-file.diff > > . However if you accidentally omit the "<", like this: > > $ patch --dry-run some-patch-file.diff > > , the terminal will await you typing in the patch file. Instead, do a > ctrl-c. This leaves the terminal not echoing keystrokes. The "funny" nature of this bug is its "reproducibility": On my system, your test doesn't work for me: I currently always get echo back. Tho, next reboot that may have changed. > By the way, thanks for educating me about the existence of the command > `reset'. :-) Enjoy. :-) There's a maybe related problem: On some system I see that tailf doesn't detect new file data - sometimes never, sometimes it stop after a while, and I checked: The file wasn't rotated or truncated. That also affects apachetop which reliably never works on this system. Fun fact: Only one user was affected by this, now also my own user is affected. -- Regards, Kai Replies to list-only preferred.
[gentoo-user] Re: Shell echo missing after ctrl+c
Am Sun, 19 Mar 2017 06:27:15 -0500 schrieb Dale : > Kai Krakow wrote: > > Am Sun, 19 Mar 2017 05:40:09 -0500 > > schrieb Dale : > > > >> Kai Krakow wrote: > [...] > [...] > >> [...] > [...] > [...] > >> I've likely had it happen on a regular console too. I have just > >> got so used to it, I don't pay it any attention. I suspect this > >> is a deep issue somewhere. Maybe even as low level as the kernel > >> somehow or close to it. > >> > >> It will be interesting to see what it is tho. Given how long it > >> has been doing it here at least, it's going to be a old > >> commit/change which may be difficult to track back. > > Well, I shouldn't say that probably, but some affected servers are > > still running on 3.0 or 3.2 kernels. Only the rest of the system was > > upgraded (mostly "glsa-check -f affected" only). So, I suspected an > > issue because of old kernel but new user space tools. > > > > But since some time ago my desktop machines are also affected (and > > those are almost bleeding edge, with ~amd64 gentoo-sources). > > > > So, more likely it's something in bash... Which is what I use. Which > > shell do you use? I could try using zsh tho I absolutely hate how it > > tries to be smarter about tab-completion and always steals trailing > > "/" away - which especially with rsync and mv can do some serious > > damage or at least unexpected results. > > > > > Here is mine: > > root@fireball / # uname -r > 4.5.2-gentoo > root@fireball / # > > As far as I know, I use bash. If you are talking about what I think > you are talking about. Yes, that's what I was talking about. Run ps, it should tell you the processes running in your current shell, including the shell itself: # ps PID TTY TIME CMD 1256 pts/200:00:00 ps 32059 pts/200:00:00 bash And you can see your default shell this way: # realpath /bin/sh /bin/dash Yes, dash for me, because it spawns much faster than bash, at least when running scripts. This can make a big difference with openrc. Meanwhile, I'm using systemd. > [IP-] [ ] app-shells/bash-4.3_p48-r1:0 Here, too: # equery list bash [IP-] [ ] app-shells/bash-4.3_p48-r1:0 > Given the age of your kernel, maybe it is above that level anyway. I > don't update my kernel often either. > > I'm going to be watching this thread tho. If I can share info which > may help narrow things down, I'll do that for sure. The problem is that this bug is totally non-deterministic... It fails once, next try it works as it should. If you can work out a way to reliably reproduce this bug, let me know. Then I'll try to work out what the problem is. -- Regards, Kai Replies to list-only preferred.
Re: [gentoo-user] Shell echo missing after ctrl+c
Hello, Kai. On Sun, Mar 19, 2017 at 09:49:50 +0100, Kai Krakow wrote: > Hello! > More and more of my Gentoo systems are exhibiting the following > strange and unexpected behavior: > After ctrl+c'ing out of programs like tailf, SSH password prompts, in > the middle of a shell scripts, the shell echo is not restored - that > is: If I type characters I no longer see the characters (but they are > received and can be executed by "enter"). If experiencing this, I have > to ctrl+c again to discard what I was typing, the blindly type "reset" > to reset the terminal, then echo is enabled again. > I'm not sure which update or configuration is causing this. It started > out on our Gentoo servers some years ago (which I'm only SSH'ed into, > no physical access), now since a few weeks, also my desktop machines are > affected. I have no explanation for this. > But maybe anyone? > BTW: I know from the old times (some 15-20 years ago) that ctrl+c out > of a program (i.e. rsync) that starts a subshell (i.e. ssh) that in > turn shows a password prompt, will leave you with an echoless shell. > But it shows up on almost any occasion now. It's been happening to me increasingly often in the last few months/years. I don't like it. Here is a recipe for reproducing the phenomenon. A typical way of invoking patch is by supplying the patch file to standard input: $ patch --dry-run < some-patch-file.diff . However if you accidentally omit the "<", like this: $ patch --dry-run some-patch-file.diff , the terminal will await you typing in the patch file. Instead, do a ctrl-c. This leaves the terminal not echoing keystrokes. By the way, thanks for educating me about the existence of the command `reset'. :-) > -- > Regards, > Kai > Replies to list-only preferred. -- Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] Re: Flashing hardware via WINE ?
Am Sun, 19 Mar 2017 11:38:56 +0100 schrieb tu...@posteo.de: > On 03/19 10:27, Neil Bothwick wrote: > > On Sun, 19 Mar 2017 09:09:51 +0100, tu...@posteo.de wrote: > > > > > I have a smart NiMH-charger with serial port (normally used to > > > dump chargeing curves to the PC). > > > The chargers firmware can bei flashed with a flashtool provided > > > by the vendor. The communication is via serial port. I have > > > a PCI=>serial.ports-card installed in my PC. > > > > > > The command > > > > > > file > > > > > > results in this information > > > > > > PE32 executable (GUI) Intel 80386, for MS Windows > > > > > > . As Linux user by heart I have no Windows. > > > > Have you tried contacting the manufacturer to see if flashing from > > Linux is possible? > > > > > > -- > > Neil Bothwick > > > > I am MODERATOR of BORG. Follow the rules or be assimilated. > > Hi Neil, > > yes...no chance. > Linux is insecure...you know. > It makes it possible to spy the firmware and decrypt it on > the way to the charger. > > Windows is much more secyre. > > Earth is flat and there was no landing on the moon. > > I believe in Santa Claus. And then there is Wireshark in Windows, with libpcap for USB... It can easily decode and record all USB frames. I successfully used it some time ago to debug a custom made USB board and found bugs in the firmware, which I had access to that way. In the end, there was a bug in the interrupt handler: a race condition overwriting the USB communication buffer too early and thus sending back wrong data in the USB HID frames back to the PC (part old data, part new data). The bug was uncovered by our implementation using a highly optimized threaded implementation to use the maximum bandwidth the device could provide. It wasn't possible to convince the firmware programmer about the bug (which was really expensive for our customer) and the project was eventually stopped. Strangely, they later provided a firmware without this failing behavior, much later. Project still paused. But the preliminary implementation now runs and show very high time resolution of measurement data (it's an electrochemical spectrometer, just if you're curious). Just that in Linux tools are available more easily doesn't mean that Windows is more "secure". ;-) Choose your partners wisely. -- Regards, Kai Replies to list-only preferred.
Re: [gentoo-user] Re: Shell echo missing after ctrl+c
Mick wrote: > On Sunday 19 Mar 2017 05:40:09 Dale wrote: >> >> I've likely had it happen on a regular console too. I have just got so >> used to it, I don't pay it any attention. I suspect this is a deep >> issue somewhere. Maybe even as low level as the kernel somehow or close >> to it. >> >> It will be interesting to see what it is tho. Given how long it has >> been doing it here at least, it's going to be a old commit/change which >> may be difficult to track back. >> >> Dale >> >> :-) :-) > Not sure this will help, but none of my systems have this problem. urxvt, > xterm, konsole, terminology, all display anything I enter in the keyboard > after I have pressed Ctrl+c. I run enlightenment, or fluxbox, I have not > tried with the plasma DE yet. Be interesting to see what happens when you try that. I have KDE for my main desktop. I do have others, Fluxbox etc, for backup usage tho. If we keep posting what we use and what is affected, or not, maybe we can find something common that points to the problem. Maybe. Dale :-) :-)
Re: [gentoo-user] Re: Shell echo missing after ctrl+c
Kai Krakow wrote: > Am Sun, 19 Mar 2017 05:40:09 -0500 > schrieb Dale : > >> Kai Krakow wrote: >>> Am Sun, 19 Mar 2017 04:12:38 -0500 >>> schrieb Dale : >>> Kai Krakow wrote: >> [...] I don't have a solution but wanted to reply to say that this happens to me too. I have a regular desktop running KDE. I use Konsole for most of my command line activity. I've noticed that this happens with a lot of programs. It has been happening so long, I thought maybe it was the new way things are done. It is aggravating and confusing at times. You are not alone on this. I'm hoping someone will post a fix. >>> KDE with konsole here, too... But I don't think that's the common >>> denominator. It's also happening from PuTTY in Windows. >>> >> I've likely had it happen on a regular console too. I have just got >> so used to it, I don't pay it any attention. I suspect this is a deep >> issue somewhere. Maybe even as low level as the kernel somehow or >> close to it. >> >> It will be interesting to see what it is tho. Given how long it has >> been doing it here at least, it's going to be a old commit/change >> which may be difficult to track back. > Well, I shouldn't say that probably, but some affected servers are > still running on 3.0 or 3.2 kernels. Only the rest of the system was > upgraded (mostly "glsa-check -f affected" only). So, I suspected an > issue because of old kernel but new user space tools. > > But since some time ago my desktop machines are also affected (and those > are almost bleeding edge, with ~amd64 gentoo-sources). > > So, more likely it's something in bash... Which is what I use. Which > shell do you use? I could try using zsh tho I absolutely hate how it > tries to be smarter about tab-completion and always steals trailing "/" > away - which especially with rsync and mv can do some serious damage or > at least unexpected results. > Here is mine: root@fireball / # uname -r 4.5.2-gentoo root@fireball / # As far as I know, I use bash. If you are talking about what I think you are talking about. [IP-] [ ] app-shells/bash-4.3_p48-r1:0 Given the age of your kernel, maybe it is above that level anyway. I don't update my kernel often either. I'm going to be watching this thread tho. If I can share info which may help narrow things down, I'll do that for sure. Dale :-) :-)
[gentoo-user] Re: Shell echo missing after ctrl+c
Am Sun, 19 Mar 2017 05:40:09 -0500 schrieb Dale : > Kai Krakow wrote: > > Am Sun, 19 Mar 2017 04:12:38 -0500 > > schrieb Dale : > > > >> Kai Krakow wrote: > [...] > >> I don't have a solution but wanted to reply to say that this > >> happens to me too. I have a regular desktop running KDE. I use > >> Konsole for most of my command line activity. I've noticed that > >> this happens with a lot of programs. It has been happening so > >> long, I thought maybe it was the new way things are done. It is > >> aggravating and confusing at times. > >> > >> You are not alone on this. I'm hoping someone will post a fix. > > KDE with konsole here, too... But I don't think that's the common > > denominator. It's also happening from PuTTY in Windows. > > > > I've likely had it happen on a regular console too. I have just got > so used to it, I don't pay it any attention. I suspect this is a deep > issue somewhere. Maybe even as low level as the kernel somehow or > close to it. > > It will be interesting to see what it is tho. Given how long it has > been doing it here at least, it's going to be a old commit/change > which may be difficult to track back. Well, I shouldn't say that probably, but some affected servers are still running on 3.0 or 3.2 kernels. Only the rest of the system was upgraded (mostly "glsa-check -f affected" only). So, I suspected an issue because of old kernel but new user space tools. But since some time ago my desktop machines are also affected (and those are almost bleeding edge, with ~amd64 gentoo-sources). So, more likely it's something in bash... Which is what I use. Which shell do you use? I could try using zsh tho I absolutely hate how it tries to be smarter about tab-completion and always steals trailing "/" away - which especially with rsync and mv can do some serious damage or at least unexpected results. -- Regards, Kai Replies to list-only preferred.
Re: [gentoo-user] Re: Shell echo missing after ctrl+c
On Sunday 19 Mar 2017 05:40:09 Dale wrote: > Kai Krakow wrote: > > Am Sun, 19 Mar 2017 04:12:38 -0500 > > > > schrieb Dale : > >> Kai Krakow wrote: > >>> Hello! > >>> > >>> More and more of my Gentoo systems are exhibiting the following > >>> strange and unexpected behavior: > >>> > >>> After ctrl+c'ing out of programs like tailf, SSH password prompts, > >>> in the middle of a shell scripts, the shell echo is not restored - > >>> that is: If I type characters I no longer see the characters (but > >>> they are received and can be executed by "enter"). If experiencing > >>> this, I have to ctrl+c again to discard what I was typing, the > >>> blindly type "reset" to reset the terminal, then echo is enabled > >>> again. > >>> > >>> I'm not sure which update or configuration is causing this. It > >>> started out on our Gentoo servers some years ago (which I'm only > >>> SSH'ed into, no physical access), now since a few weeks, also my > >>> desktop machines are affected. I have no explanation for this. > >>> > >>> But maybe anyone? > >>> > >>> BTW: I know from the old times (some 15-20 years ago) that ctrl+c > >>> out of a program (i.e. rsync) that starts a subshell (i.e. ssh) > >>> that in turn shows a password prompt, will leave you with an > >>> echoless shell. But it shows up on almost any occasion now. > >> > >> I don't have a solution but wanted to reply to say that this happens > >> to me too. I have a regular desktop running KDE. I use Konsole for > >> most of my command line activity. I've noticed that this happens > >> with a lot of programs. It has been happening so long, I thought > >> maybe it was the new way things are done. It is aggravating and > >> confusing at times. > >> > >> You are not alone on this. I'm hoping someone will post a fix. > > > > KDE with konsole here, too... But I don't think that's the common > > denominator. It's also happening from PuTTY in Windows. > > I've likely had it happen on a regular console too. I have just got so > used to it, I don't pay it any attention. I suspect this is a deep > issue somewhere. Maybe even as low level as the kernel somehow or close > to it. > > It will be interesting to see what it is tho. Given how long it has > been doing it here at least, it's going to be a old commit/change which > may be difficult to track back. > > Dale > > :-) :-) Not sure this will help, but none of my systems have this problem. urxvt, xterm, konsole, terminology, all display anything I enter in the keyboard after I have pressed Ctrl+c. I run enlightenment, or fluxbox, I have not tried with the plasma DE yet. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Slightly OT - My new SSD.
Hello, Adam. Thanks for the reply. On Sun, Mar 19, 2017 at 11:45:34 +1100, Adam Carter wrote: > On Sun, Mar 19, 2017 at 3:36 AM, Alan Mackenzie wrote: > > I've just bought myself a Samsung NVMe 960 EVO M.2 SSD. > > > > Some timings: > > > > An emerge -puND @world (when there's nothing to merge) took 38.5s. With > > my mirrored HDDs, this took 45.6s. (Though usually it takes nearer a > > minute.) > > > > An emerge of Firefox took 34m23s, compared with 37m34s with the HDDs. > > The lack of the sound of the HDD heads moving was either disconcerting > > or a bit of a relief, I'm not sure which. > > > > Copying my email spool file (~110,000 entries, ~1.4 GB) from SSD -> SSD > > took 6.1s. From HDD RAID -> HDD RAID it took 30.0s. > > > > > > > I was also hoping for more speed up when i got mine, but of course it only > helps with the system is IO bound. Its great for loading VMs. > It may be mandatory with NVM, but you can check multiqueue is setup/working > with; > # cat /proc/interrupts | egrep '(CPU|nvm)' > CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 > CPU6 CPU7 > 30: 21596 0 0 0 0 0 >0 0 PCI-MSI 1572864-edge nvme0q0, nvme0q1 > 40: 0 12195 0 0 0 0 >0 0 PCI-MSI 1572865-edge nvme0q2 > 41: 0 0 12188 0 0 0 >0 0 PCI-MSI 1572866-edge nvme0q3 > 42: 0 0 0 13696 0 0 >0 0 PCI-MSI 1572867-edge nvme0q4 > 43: 0 0 0 0 11698 0 >0 0 PCI-MSI 1572868-edge nvme0q5 > 44: 0 0 0 0 0 45820 >0 0 PCI-MSI 1572869-edge nvme0q6 > 45: 0 0 0 0 0 0 > 10917 0 PCI-MSI 1572870-edge nvme0q7 > 46: 0 0 0 0 0 0 >0 12865 PCI-MSI 1572871-edge nvme0q8 > If its not setup there'll be just a single IRQ/core handling all the IO. That, indeed, seems to to be the case. When I do cat /proc/interrupts | egrep '(CPU/nvm)', I get just the header line with one data line: CPU0 CPU1 CPU2 CPU3 17: 0 0 15 14605 IO-APIC 17-fasteoi ehci_hcd:usb1, nvme0q0, nvme0q1 I'm kind of feeling a bit out of my depth here. What are the nvme0q0, etc.? "Queues" of some kind? You appear to have nine of these things, I've just got two. I'm sure there's a fine manual I ought to be reading. Do you know where I might find this manual? When I look at the entire /proc/interrupts, there are just 30 lines listed, and I suspect there are no more than 32 interrupt numbers available. Is there any way I can configure Linux to give my SSD more than one interrupt line to work with? > FWIW > # hdparm -tT /dev/nvme0n1 > /dev/nvme0n1: > Timing cached reads: 9884 MB in 2.00 seconds = 4945.35 MB/sec > Timing buffered disk reads: 4506 MB in 3.00 seconds = 1501.84 MB/sec I get: /dev/nvme0n1: Timing cached reads: 4248 MB in 2.00 seconds = 2124.01 MB/sec Timing buffered disk reads: 1214 MB in 3.00 seconds = 404.51 MB/sec So my "cached reads" speed is (a little under) half of yours. This is to be expected, since my PCIe lanes are only version 2 (and yours are probably version 3). But the "buffered disk read" are much slower. Is this just the age of my PC, or might I have something suboptimally configured? -- Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] Re: Flashing hardware via WINE ?
Am Sun, 19 Mar 2017 11:35:44 +0100 schrieb tu...@posteo.de: > On 03/19 11:20, Kai Krakow wrote: > > Am Sun, 19 Mar 2017 09:57:22 +0100 > > schrieb tu...@posteo.de: > > > > > On 03/19 09:37, Kai Krakow wrote: > [...] > [...] > [...] > [...] > [...] > > > > > > Hi Kai (that's a rhyme! :) > > > > Yeah, I know that one... If you are from Germany, you'll also get > > why my former nick (some years ago) was "Shark" :-) > > > > > I have installed Virtualbox already and use the Linux Image I > > > installed there for banking purposes only. Feels more secure. > > > > So something like application virtualization... You could maybe run > > in an isolated container, only exposing the xserver or run inside a > > nested xserver. It would probably greatly reduce startup times and > > not waste a complete image. > > > > > I would prefer the WIndows-in-a-(virtual)box-solution) as you > > > do -- if I would own a Windows installation disc. But do not. > > > > Well, you can easily get an image from MS using a Linux browser. > > Just go to the Windows 10 download page. It will show a selection > > form to choose the ISO instead of the nasty downloader they present > > to Windows browsers. Then install this inside the VM. Even if not > > activated, it runs for 1-2 hours before shutting down which should > > be enough for most purposes you'll need it for. > > > > If you already activated a Windows installation with your MS > > account, with some luck your Win10 VM may even become digitally > > activated (this happened to me). No cracks involved. Should be > > legal enough. ;-) > > > But it is good to know, that the wine-workaround would either > > > work or fail too early to damage anything. > > > > I tried some, and all failed because they didn't even find the > > device. The ones that worked where either network based (flashing > > via IP protocol) or using other simple interfaces (COM or LPT). > > > > > Is there anything important to know before doing an emerge > > > of wine (need I more than app-emulation/wine?) -- I have > > > literally no experience with this emulator - the flashing > > > tool is a 32bit gui application...) ??? > > > > Wine = wine is no emulater ;-) > > > > Actually, it's the Windows API implemented as .so files plus an EXE > > loader to enable the kernel to run PE binaries (instead of ELF). So > > nothing is emulated, it's running native. There's also a thin layer > > of drivers implemented to transform API calls to native kernel > > interfaces, like HID (for input devices). So everything connecting > > to simple HID-USB should also work (some custom USB hardware just > > implement a HID interface, it's simple and cheap). > > > > If your applications work depends on if the required parts of the > > API had been implemented (including the bugs that exists between > > different versions of Windows). > > > > So, with this knowledge, you simply emerge wine with the useflags > > that look useful to you. If you don't need graphics (DirectX) or > > don't want to apply your linux GUI theme to Windows apps, you can > > ignore the staging useflag. Wine can be compiled with both 64bit > > and 32bit support. > > > > After installation, get familiar with the winecfg utility. It allows > > mapping unix path to Windows drive letters. And it allows to set > > Windows version per EXE you run (to expose different API bugs and > > behavior to your application). Also, you can set DDL overrides > > (which is what Windows itself uses when you run applications in > > compatibility mode, or when you put DLL overrides manually in the > > registry). Tho, here you can decide between native (native DLL on > > filesystem) or builtin (*.dll.so file from Wine), and the order in > > which they are tried. > > > > You may also run with different WINEDEBUG settings if you want to > > work out problems. There are fixme lines which usually show stub > > implementations of API calls (functions that do nothing, and are > > there just to return success or fail). You can use it like this: > > > > # WINEDEBUG=-all wine your-exe-file.exe > > > > If you'd like to easily manage different Wine prefixes, I'd > > recommend using PlayOnLinux - it's not only useful to games. It > > also has a long list of scripted installers for installing popular > > Windows extensions that you may need (fonts, VB runtimes, C > > runtimes) in different versions. > > > > And then, maybe you want to use winetricks, tho it may be a bit > > tricky to run this with PlayOnLinux because it will default to the > > non-PlayOnLinux wine prefix. Easy work-around: Launch a commandline > > shell from within PlayOnLinux and run winetricks there. > > > > With PlayOnLinux you can easily reset or discard wine prefixes if > > you messed up. Also, you can see each prefix as some sort of > > compatibility profile you individually crafted per Windows > > application you are running. > > > > -- > > Regards, > > Kai > > > > Replies
Re: [gentoo-user] Re: Shell echo missing after ctrl+c
Kai Krakow wrote: > Am Sun, 19 Mar 2017 04:12:38 -0500 > schrieb Dale : > >> Kai Krakow wrote: >>> Hello! >>> >>> More and more of my Gentoo systems are exhibiting the following >>> strange and unexpected behavior: >>> >>> After ctrl+c'ing out of programs like tailf, SSH password prompts, >>> in the middle of a shell scripts, the shell echo is not restored - >>> that is: If I type characters I no longer see the characters (but >>> they are received and can be executed by "enter"). If experiencing >>> this, I have to ctrl+c again to discard what I was typing, the >>> blindly type "reset" to reset the terminal, then echo is enabled >>> again. >>> >>> I'm not sure which update or configuration is causing this. It >>> started out on our Gentoo servers some years ago (which I'm only >>> SSH'ed into, no physical access), now since a few weeks, also my >>> desktop machines are affected. I have no explanation for this. >>> >>> But maybe anyone? >>> >>> BTW: I know from the old times (some 15-20 years ago) that ctrl+c >>> out of a program (i.e. rsync) that starts a subshell (i.e. ssh) >>> that in turn shows a password prompt, will leave you with an >>> echoless shell. But it shows up on almost any occasion now. >>> >> I don't have a solution but wanted to reply to say that this happens >> to me too. I have a regular desktop running KDE. I use Konsole for >> most of my command line activity. I've noticed that this happens >> with a lot of programs. It has been happening so long, I thought >> maybe it was the new way things are done. It is aggravating and >> confusing at times. >> >> You are not alone on this. I'm hoping someone will post a fix. > KDE with konsole here, too... But I don't think that's the common > denominator. It's also happening from PuTTY in Windows. > I've likely had it happen on a regular console too. I have just got so used to it, I don't pay it any attention. I suspect this is a deep issue somewhere. Maybe even as low level as the kernel somehow or close to it. It will be interesting to see what it is tho. Given how long it has been doing it here at least, it's going to be a old commit/change which may be difficult to track back. Dale :-) :-)
Re: [gentoo-user] Flashing hardware via WINE ?
On 03/19 10:27, Neil Bothwick wrote: > On Sun, 19 Mar 2017 09:09:51 +0100, tu...@posteo.de wrote: > > > I have a smart NiMH-charger with serial port (normally used to > > dump chargeing curves to the PC). > > The chargers firmware can bei flashed with a flashtool provided > > by the vendor. The communication is via serial port. I have > > a PCI=>serial.ports-card installed in my PC. > > > > The command > > > > file > > > > results in this information > > > > PE32 executable (GUI) Intel 80386, for MS Windows > > > > . As Linux user by heart I have no Windows. > > Have you tried contacting the manufacturer to see if flashing from Linux > is possible? > > > -- > Neil Bothwick > > I am MODERATOR of BORG. Follow the rules or be assimilated. Hi Neil, yes...no chance. Linux is insecure...you know. It makes it possible to spy the firmware and decrypt it on the way to the charger. Windows is much more secyre. Earth is flat and there was no landing on the moon. I believe in Santa Claus. Cheers Meino
Re: [gentoo-user] Re: Flashing hardware via WINE ?
On 03/19 11:20, Kai Krakow wrote: > Am Sun, 19 Mar 2017 09:57:22 +0100 > schrieb tu...@posteo.de: > > > On 03/19 09:37, Kai Krakow wrote: > > > Am Sun, 19 Mar 2017 09:09:51 +0100 > > > schrieb tu...@posteo.de: > > > > > > > Hi, > > > > > > > > I have a smart NiMH-charger with serial port (normally used to > > > > dump chargeing curves to the PC). > > > > The chargers firmware can bei flashed with a flashtool provided > > > > by the vendor. The communication is via serial port. I have > > > > a PCI=>serial.ports-card installed in my PC. > > > > > > > > The command > > > > > > > > file > > > > > > > > results in this information > > > > > > > > PE32 executable (GUI) Intel 80386, for MS Windows > > > > > > > > . As Linux user by heart I have no Windows. > > > > > > > > May the attempt to install wine and use it for this purpose > > > > a thinkable way or are the precoditions that way, that it > > > > is due to those a NO-NO...? > > > > > > Flashing via serial port should be no problem from within Wine. It > > > requires no special driver implementation. > > > > > > However, if the hardware implements its own driver behind the serial > > > port, it won't work anyways because on the Wine side there will be > > > no such driver. > > > > > > So I think, it should either work or fail early without doing > > > damage. > > > > > > > > > > Does anyone have experience with such an attempt? > > > > > > I'm usually doing such things from VirtualBox by passing through the > > > hardware (usually USB, that's easily done from within the GUI). > > > > > > VirtualBox can also pass COM ports to the VM. You may want to try > > > that as a second chance. > > > > > > > > > -- > > > Regards, > > > Kai > > > > > > Replies to list-only preferred. > > > > Hi Kai (that's a rhyme! :) > > Yeah, I know that one... If you are from Germany, you'll also get why > my former nick (some years ago) was "Shark" :-) > > > I have installed Virtualbox already and use the Linux Image I > > installed there for banking purposes only. Feels more secure. > > So something like application virtualization... You could maybe run in > an isolated container, only exposing the xserver or run inside a nested > xserver. It would probably greatly reduce startup times and not waste a > complete image. > > > I would prefer the WIndows-in-a-(virtual)box-solution) as you > > do -- if I would own a Windows installation disc. But do not. > > Well, you can easily get an image from MS using a Linux browser. Just > go to the Windows 10 download page. It will show a selection form to > choose the ISO instead of the nasty downloader they present to Windows > browsers. Then install this inside the VM. Even if not activated, it > runs for 1-2 hours before shutting down which should be enough for most > purposes you'll need it for. > > If you already activated a Windows installation with your MS account, > with some luck your Win10 VM may even become digitally activated (this > happened to me). No cracks involved. Should be legal enough. ;-) > > > But it is good to know, that the wine-workaround would either > > work or fail too early to damage anything. > > I tried some, and all failed because they didn't even find the device. > The ones that worked where either network based (flashing via IP > protocol) or using other simple interfaces (COM or LPT). > > > Is there anything important to know before doing an emerge > > of wine (need I more than app-emulation/wine?) -- I have > > literally no experience with this emulator - the flashing > > tool is a 32bit gui application...) ??? > > Wine = wine is no emulater ;-) > > Actually, it's the Windows API implemented as .so files plus an EXE > loader to enable the kernel to run PE binaries (instead of ELF). So > nothing is emulated, it's running native. There's also a thin layer of > drivers implemented to transform API calls to native kernel interfaces, > like HID (for input devices). So everything connecting to simple > HID-USB should also work (some custom USB hardware just implement a HID > interface, it's simple and cheap). > > If your applications work depends on if the required parts of the API > had been implemented (including the bugs that exists between different > versions of Windows). > > So, with this knowledge, you simply emerge wine with the useflags that > look useful to you. If you don't need graphics (DirectX) or don't want > to apply your linux GUI theme to Windows apps, you can ignore the > staging useflag. Wine can be compiled with both 64bit and 32bit support. > > After installation, get familiar with the winecfg utility. It allows > mapping unix path to Windows drive letters. And it allows to set > Windows version per EXE you run (to expose different API bugs and > behavior to your application). Also, you can set DDL overrides (which > is what Windows itself uses when you run applications in compatibility > mode, or when you put DLL overrides manually i
Re: [gentoo-user] Flashing hardware via WINE ?
On Sun, 19 Mar 2017 09:09:51 +0100, tu...@posteo.de wrote: > I have a smart NiMH-charger with serial port (normally used to > dump chargeing curves to the PC). > The chargers firmware can bei flashed with a flashtool provided > by the vendor. The communication is via serial port. I have > a PCI=>serial.ports-card installed in my PC. > > The command > > file > > results in this information > > PE32 executable (GUI) Intel 80386, for MS Windows > > . As Linux user by heart I have no Windows. Have you tried contacting the manufacturer to see if flashing from Linux is possible? -- Neil Bothwick I am MODERATOR of BORG. Follow the rules or be assimilated. pgpfRJtZtP5Ut.pgp Description: OpenPGP digital signature
[gentoo-user] Re: Shell echo missing after ctrl+c
Am Sun, 19 Mar 2017 04:12:38 -0500 schrieb Dale : > Kai Krakow wrote: > > Hello! > > > > More and more of my Gentoo systems are exhibiting the following > > strange and unexpected behavior: > > > > After ctrl+c'ing out of programs like tailf, SSH password prompts, > > in the middle of a shell scripts, the shell echo is not restored - > > that is: If I type characters I no longer see the characters (but > > they are received and can be executed by "enter"). If experiencing > > this, I have to ctrl+c again to discard what I was typing, the > > blindly type "reset" to reset the terminal, then echo is enabled > > again. > > > > I'm not sure which update or configuration is causing this. It > > started out on our Gentoo servers some years ago (which I'm only > > SSH'ed into, no physical access), now since a few weeks, also my > > desktop machines are affected. I have no explanation for this. > > > > But maybe anyone? > > > > BTW: I know from the old times (some 15-20 years ago) that ctrl+c > > out of a program (i.e. rsync) that starts a subshell (i.e. ssh) > > that in turn shows a password prompt, will leave you with an > > echoless shell. But it shows up on almost any occasion now. > > > > I don't have a solution but wanted to reply to say that this happens > to me too. I have a regular desktop running KDE. I use Konsole for > most of my command line activity. I've noticed that this happens > with a lot of programs. It has been happening so long, I thought > maybe it was the new way things are done. It is aggravating and > confusing at times. > > You are not alone on this. I'm hoping someone will post a fix. KDE with konsole here, too... But I don't think that's the common denominator. It's also happening from PuTTY in Windows. -- Regards, Kai Replies to list-only preferred.
[gentoo-user] Re: Flashing hardware via WINE ?
Am Sun, 19 Mar 2017 09:57:22 +0100 schrieb tu...@posteo.de: > On 03/19 09:37, Kai Krakow wrote: > > Am Sun, 19 Mar 2017 09:09:51 +0100 > > schrieb tu...@posteo.de: > > > > > Hi, > > > > > > I have a smart NiMH-charger with serial port (normally used to > > > dump chargeing curves to the PC). > > > The chargers firmware can bei flashed with a flashtool provided > > > by the vendor. The communication is via serial port. I have > > > a PCI=>serial.ports-card installed in my PC. > > > > > > The command > > > > > > file > > > > > > results in this information > > > > > > PE32 executable (GUI) Intel 80386, for MS Windows > > > > > > . As Linux user by heart I have no Windows. > > > > > > May the attempt to install wine and use it for this purpose > > > a thinkable way or are the precoditions that way, that it > > > is due to those a NO-NO...? > > > > Flashing via serial port should be no problem from within Wine. It > > requires no special driver implementation. > > > > However, if the hardware implements its own driver behind the serial > > port, it won't work anyways because on the Wine side there will be > > no such driver. > > > > So I think, it should either work or fail early without doing > > damage. > > > > > > > Does anyone have experience with such an attempt? > > > > I'm usually doing such things from VirtualBox by passing through the > > hardware (usually USB, that's easily done from within the GUI). > > > > VirtualBox can also pass COM ports to the VM. You may want to try > > that as a second chance. > > > > > > -- > > Regards, > > Kai > > > > Replies to list-only preferred. > > Hi Kai (that's a rhyme! :) Yeah, I know that one... If you are from Germany, you'll also get why my former nick (some years ago) was "Shark" :-) > I have installed Virtualbox already and use the Linux Image I > installed there for banking purposes only. Feels more secure. So something like application virtualization... You could maybe run in an isolated container, only exposing the xserver or run inside a nested xserver. It would probably greatly reduce startup times and not waste a complete image. > I would prefer the WIndows-in-a-(virtual)box-solution) as you > do -- if I would own a Windows installation disc. But do not. Well, you can easily get an image from MS using a Linux browser. Just go to the Windows 10 download page. It will show a selection form to choose the ISO instead of the nasty downloader they present to Windows browsers. Then install this inside the VM. Even if not activated, it runs for 1-2 hours before shutting down which should be enough for most purposes you'll need it for. If you already activated a Windows installation with your MS account, with some luck your Win10 VM may even become digitally activated (this happened to me). No cracks involved. Should be legal enough. ;-) > But it is good to know, that the wine-workaround would either > work or fail too early to damage anything. I tried some, and all failed because they didn't even find the device. The ones that worked where either network based (flashing via IP protocol) or using other simple interfaces (COM or LPT). > Is there anything important to know before doing an emerge > of wine (need I more than app-emulation/wine?) -- I have > literally no experience with this emulator - the flashing > tool is a 32bit gui application...) ??? Wine = wine is no emulater ;-) Actually, it's the Windows API implemented as .so files plus an EXE loader to enable the kernel to run PE binaries (instead of ELF). So nothing is emulated, it's running native. There's also a thin layer of drivers implemented to transform API calls to native kernel interfaces, like HID (for input devices). So everything connecting to simple HID-USB should also work (some custom USB hardware just implement a HID interface, it's simple and cheap). If your applications work depends on if the required parts of the API had been implemented (including the bugs that exists between different versions of Windows). So, with this knowledge, you simply emerge wine with the useflags that look useful to you. If you don't need graphics (DirectX) or don't want to apply your linux GUI theme to Windows apps, you can ignore the staging useflag. Wine can be compiled with both 64bit and 32bit support. After installation, get familiar with the winecfg utility. It allows mapping unix path to Windows drive letters. And it allows to set Windows version per EXE you run (to expose different API bugs and behavior to your application). Also, you can set DDL overrides (which is what Windows itself uses when you run applications in compatibility mode, or when you put DLL overrides manually in the registry). Tho, here you can decide between native (native DLL on filesystem) or builtin (*.dll.so file from Wine), and the order in which they are tried. You may also run with different WINEDEBUG settings if you want to work out problems. There are fixme lines whi
Re: [gentoo-user] Shell echo missing after ctrl+c
On 03/19 10:17, Matthias Hanft wrote: > Kai Krakow wrote: > > > > After ctrl+c'ing out of programs like tailf, SSH password prompts, in > > the middle of a shell scripts, the shell echo is not restored > > Not here, but something similar: Immediately after ctrl+c'ing, no shell > prompt is displayed (in fact, *nothing* is displayed) - but it's just > the display; I can enter a shell command (with echo, too) which will > be executed properly. Or just press the RETURN key on the empty line > to get the shell prompt again. > > This happens just on a single of my Gentoo systems (and not always, > but very often). > > Any idea? > > -Matt > > Hi, I haven't experienced this yet...but the command 'reset' will reset (hence the name... ;) the terminal to normal. This also helps, if the terminal got confused after accidentally cat'ing a binary... Cheers Meino
Re: [gentoo-user] Shell echo missing after ctrl+c
Kai Krakow wrote: > > After ctrl+c'ing out of programs like tailf, SSH password prompts, in > the middle of a shell scripts, the shell echo is not restored Not here, but something similar: Immediately after ctrl+c'ing, no shell prompt is displayed (in fact, *nothing* is displayed) - but it's just the display; I can enter a shell command (with echo, too) which will be executed properly. Or just press the RETURN key on the empty line to get the shell prompt again. This happens just on a single of my Gentoo systems (and not always, but very often). Any idea? -Matt
Re: [gentoo-user] Shell echo missing after ctrl+c
Kai Krakow wrote: > Hello! > > More and more of my Gentoo systems are exhibiting the following > strange and unexpected behavior: > > After ctrl+c'ing out of programs like tailf, SSH password prompts, in > the middle of a shell scripts, the shell echo is not restored - that > is: If I type characters I no longer see the characters (but they are > received and can be executed by "enter"). If experiencing this, I have > to ctrl+c again to discard what I was typing, the blindly type "reset" > to reset the terminal, then echo is enabled again. > > I'm not sure which update or configuration is causing this. It started > out on our Gentoo servers some years ago (which I'm only SSH'ed into, > no physical access), now since a few weeks, also my desktop machines are > affected. I have no explanation for this. > > But maybe anyone? > > BTW: I know from the old times (some 15-20 years ago) that ctrl+c out > of a program (i.e. rsync) that starts a subshell (i.e. ssh) that in > turn shows a password prompt, will leave you with an echoless shell. > But it shows up on almost any occasion now. > I don't have a solution but wanted to reply to say that this happens to me too. I have a regular desktop running KDE. I use Konsole for most of my command line activity. I've noticed that this happens with a lot of programs. It has been happening so long, I thought maybe it was the new way things are done. It is aggravating and confusing at times. You are not alone on this. I'm hoping someone will post a fix. Dale :-) :-)
Re: [gentoo-user] Re: Flashing hardware via WINE ?
On 03/19 09:37, Kai Krakow wrote: > Am Sun, 19 Mar 2017 09:09:51 +0100 > schrieb tu...@posteo.de: > > > Hi, > > > > I have a smart NiMH-charger with serial port (normally used to > > dump chargeing curves to the PC). > > The chargers firmware can bei flashed with a flashtool provided > > by the vendor. The communication is via serial port. I have > > a PCI=>serial.ports-card installed in my PC. > > > > The command > > > > file > > > > results in this information > > > > PE32 executable (GUI) Intel 80386, for MS Windows > > > > . As Linux user by heart I have no Windows. > > > > May the attempt to install wine and use it for this purpose > > a thinkable way or are the precoditions that way, that it > > is due to those a NO-NO...? > > Flashing via serial port should be no problem from within Wine. It > requires no special driver implementation. > > However, if the hardware implements its own driver behind the serial > port, it won't work anyways because on the Wine side there will be no > such driver. > > So I think, it should either work or fail early without doing damage. > > > > Does anyone have experience with such an attempt? > > I'm usually doing such things from VirtualBox by passing through the > hardware (usually USB, that's easily done from within the GUI). > > VirtualBox can also pass COM ports to the VM. You may want to try that > as a second chance. > > > -- > Regards, > Kai > > Replies to list-only preferred. Hi Kai (that's a rhyme! :) I have installed Virtualbox already and use the Linux Image I installed there for banking purposes only. Feels more secure. I would prefer the WIndows-in-a-(virtual)box-solution) as you do -- if I would own a Windows installation disc. But do not. But it is good to know, that the wine-workaround would either work or fail too early to damage anything. Is there anything important to know before doing an emerge of wine (need I more than app-emulation/wine?) -- I have literally no experience with this emulator - the flashing tool is a 32bit gui application...) ??? Cheers Meino
[gentoo-user] Shell echo missing after ctrl+c
Hello! More and more of my Gentoo systems are exhibiting the following strange and unexpected behavior: After ctrl+c'ing out of programs like tailf, SSH password prompts, in the middle of a shell scripts, the shell echo is not restored - that is: If I type characters I no longer see the characters (but they are received and can be executed by "enter"). If experiencing this, I have to ctrl+c again to discard what I was typing, the blindly type "reset" to reset the terminal, then echo is enabled again. I'm not sure which update or configuration is causing this. It started out on our Gentoo servers some years ago (which I'm only SSH'ed into, no physical access), now since a few weeks, also my desktop machines are affected. I have no explanation for this. But maybe anyone? BTW: I know from the old times (some 15-20 years ago) that ctrl+c out of a program (i.e. rsync) that starts a subshell (i.e. ssh) that in turn shows a password prompt, will leave you with an echoless shell. But it shows up on almost any occasion now. -- Regards, Kai Replies to list-only preferred.
[gentoo-user] Re: Flashing hardware via WINE ?
Am Sun, 19 Mar 2017 09:09:51 +0100 schrieb tu...@posteo.de: > Hi, > > I have a smart NiMH-charger with serial port (normally used to > dump chargeing curves to the PC). > The chargers firmware can bei flashed with a flashtool provided > by the vendor. The communication is via serial port. I have > a PCI=>serial.ports-card installed in my PC. > > The command > > file > > results in this information > > PE32 executable (GUI) Intel 80386, for MS Windows > > . As Linux user by heart I have no Windows. > > May the attempt to install wine and use it for this purpose > a thinkable way or are the precoditions that way, that it > is due to those a NO-NO...? Flashing via serial port should be no problem from within Wine. It requires no special driver implementation. However, if the hardware implements its own driver behind the serial port, it won't work anyways because on the Wine side there will be no such driver. So I think, it should either work or fail early without doing damage. > Does anyone have experience with such an attempt? I'm usually doing such things from VirtualBox by passing through the hardware (usually USB, that's easily done from within the GUI). VirtualBox can also pass COM ports to the VM. You may want to try that as a second chance. -- Regards, Kai Replies to list-only preferred.
[gentoo-user] Flashing hardware via WINE ?
Hi, I have a smart NiMH-charger with serial port (normally used to dump chargeing curves to the PC). The chargers firmware can bei flashed with a flashtool provided by the vendor. The communication is via serial port. I have a PCI=>serial.ports-card installed in my PC. The command file results in this information PE32 executable (GUI) Intel 80386, for MS Windows . As Linux user by heart I have no Windows. May the attempt to install wine and use it for this purpose a thinkable way or are the precoditions that way, that it is due to those a NO-NO...? Does anyone have experience with such an attempt? Cheers Meino