ThinkPad W530 Intel HD Graphics 4000 friendly to puffy?
Hello this is Jorge, Just wondering I just recently bought my workstation, now I am looking into a laptop. From this place, http://laclinux.com/gnu/Laptop they are pretty much configuring a ThinkPad W530 (laptop workstation). They give you the option of choosing the nVidia card or the Intel HD Graphics 4000. Given that the Intel HD Graphics is open source I am wondering how friendly it is to puffy? I tried searching the mailing list, and man pages. To be honest I kind of did not even know where to look given that it is integrated graphics (other than using the search feature could not find anything in the usual places). The main reason why I want this laptop is because it has upgradeable RAM up to 32 GB. If there are no drivers written for this yet, how much until you think it will be compatible (that is the drivers written for it)? Thanks appreciate the help. [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: ThinkPad W530 Intel HD Graphics 4000 friendly to puffy?
On Sun, Nov 18, 2012 at 10:56 AM, Jorge Armendariz tedeumjo...@lavabit.com wrote: Hello this is Jorge, Just wondering I just recently bought my workstation, now I am looking into a laptop. From this place, http://laclinux.com/gnu/Laptop they are pretty much configuring a ThinkPad W530 (laptop workstation). They give you the option of choosing the nVidia card or the Intel HD Graphics 4000. Given that the Intel HD Graphics is open source I am wondering how friendly it is to puffy? I tried searching the mailing list, and man pages. To be honest I kind of did not even know where to look given that it is integrated graphics (other than using the search feature could not find anything in the usual places). The main reason why I want this laptop is because it has upgradeable RAM up to 32 GB. If there are no drivers written for this yet, how much until you think it will be compatible (that is the drivers written for it)? Not sure if it's still Sandrybridge http://www.lenovo.com/products/us/tech-specs/laptop/thinkpad/w-series/w530/ , but OpenBSD doesn't have KMS yet (just partiall parts) which means that most probably it will work, just don't expect much 3D power on Intel. Best option will be to try install latest snapshot if you can and post dmesg, pcidump -v, usbdevs -v, Xorg.0.log outputs. Thanks appreciate the help. [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: ThinkPad W530 Intel HD Graphics 4000 friendly to puffy?
On Sun, Nov 18, 2012 at 11:12:36AM +0100, Tomas Bodzar wrote: On Sun, Nov 18, 2012 at 10:56 AM, Jorge Armendariz tedeumjo...@lavabit.com wrote: Hello this is Jorge, Just wondering I just recently bought my workstation, now I am looking into a laptop. From this place, http://laclinux.com/gnu/Laptop they are pretty much configuring a ThinkPad W530 (laptop workstation). They give you the option of choosing the nVidia card or the Intel HD Graphics 4000. Given that the Intel HD Graphics is open source I am wondering how friendly it is to puffy? I tried searching the mailing list, and man pages. To be honest I kind of did not even know where to look given that it is integrated graphics (other than using the search feature could not find anything in the usual places). The main reason why I want this laptop is because it has upgradeable RAM up to 32 GB. If there are no drivers written for this yet, how much until you think it will be compatible (that is the drivers written for it)? Not sure if it's still Sandrybridge http://www.lenovo.com/products/us/tech-specs/laptop/thinkpad/w-series/w530/ , but OpenBSD doesn't have KMS yet (just partiall parts) which means that most probably it will work, just don't expect much 3D power on Intel. Best option will be to try install latest snapshot if you can and post dmesg, pcidump -v, usbdevs -v, Xorg.0.log outputs. The intel graphics is currently your best bet to be well supported. Even if it is not at the moment the chances are fairly high it will be supported sometimes in the hopefully not to far future. -- :wq Claudio
Re: tmux segfault in 5.2 with join-pane
Hi, This problem seems to be solved with the nicm@ commit: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/tmux/names.c.diff?r1=1.16;r2=1.17;f=h. I hope it helps. On Sat, Nov 17, 2012 at 6:04 PM, LEVAI Daniel l...@ecentrum.hu wrote: Hi! I've just noticed this crash with tmux(1): Just start tmux(1), open a second window, enter command mode, type 'join-pane -s 1' from window no. 0 - crash. I've recompiled and installed tmux and libevent with symbols and without stripping, and I could get this backtrace from the coredump (hope it's useful): GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-openbsd5.2... Core was generated by `tmux'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.11.3...done. Loaded symbols for /usr/lib/libutil.so.11.3 Reading symbols from /usr/lib/libcurses.so.12.1...done. Loaded symbols for /usr/lib/libcurses.so.12.1 Reading symbols from /usr/lib/libevent.so.3.0...done. Loaded symbols for /usr/lib/libevent.so.3.0 Reading symbols from /usr/lib/libc.so.65.0...done. Loaded symbols for /usr/lib/libc.so.65.0 Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so #0 0x1c01d676 in window_name_callback (fd=-1, events=1, data=0x86a53000) at /usr/src/usr.bin/tmux/names.c:60 60 if (w-active-screen != w-active-base) (gdb) bt full #0 0x1c01d676 in window_name_callback (fd=-1, events=1, data=0x86a53000) at /usr/src/usr.bin/tmux/names.c:60 name = Variable name is not available. (gdb) frame #0 0x1c01d676 in window_name_callback (fd=-1, events=1, data=0x86a53000) at /usr/src/usr.bin/tmux/names.c:60 60 if (w-active-screen != w-active-base) (gdb) list 55 event_del(w-name_timer); 56 return; 57 } 58 queue_window_name(w); 59 60 if (w-active-screen != w-active-base) 61 name = NULL; 62 else 63 name = get_proc_name(w-active-fd, w-active-tty); 64 if (name == NULL) (gdb) bt #0 0x1c01d676 in window_name_callback (fd=-1, events=1, data=0x86a53000) at /usr/src/usr.bin/tmux/names.c:60 #1 0x0c7d30a2 in event_base_loop (base=0x804bd000, flags=1) at /usr/src/lib/libevent/event.c:402 #2 0x0c7d3359 in event_loop (flags=1) at /usr/src/lib/libevent/event.c:478 #3 0x1c026274 in server_loop () at /usr/src/usr.bin/tmux/server.c:211 #4 0x1c0267ec in server_start (lockfd=4, lockfile=0x80f14aa0 S) at /usr/src/usr.bin/tmux/server.c:202 #5 0x1c004640 in client_connect (path=0x3c0223c0 /tmp/tmux-1000/default, start_server=1) at /usr/src/usr.bin/tmux/client.c:124 #6 0x1c004731 in client_main (argc=0, argv=0xcfbdb700, flags=1) at /usr/src/usr.bin/tmux/client.c:220 #7 0x1c02cb7e in main (argc=0, argv=0xcfbdb6fc) at /usr/src/usr.bin/tmux/tmux.c:396 (gdb) Daniel -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: no BIOS memory map supplied
On Nov 14 08:39:22, h...@stare.cz wrote: On Nov 14 08:35:37, h...@stare.cz wrote: With today's i386 snapshot (Nov 14th) and the previous (Nov 11th), the booting bsd goes straight to ddb prompt saying panic: no BIOS memory map supplied This is on a Thinkpad T40. Is anyone else seeing this? Forgot to add: here is an older snapshot that worked fine: The current/i386 snapshot (Nov 17th) is working fine again.
Re: ThinkPad W530 Intel HD Graphics 4000 friendly to puffy?
On Sun, 18 Nov 2012 11:12:36 +0100 Tomas Bodzar tomas.bod...@gmail.com wrote: Not sure if it's still Sandrybridge http://www.lenovo.com/products/us/tech-specs/laptop/thinkpad/w-series/w530/ All thinkpad models ending in 30 are Ivy Bridge, just as all ending in 20 are Sandy. , but OpenBSD doesn't have KMS yet (just partiall parts) which means that most probably it will work, just don't expect much 3D power on Intel. Best option will be to try install latest snapshot if you can and post dmesg, pcidump -v, usbdevs -v, Xorg.0.log outputs. Thanks appreciate the help. [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] -- Rares Aioanei
Re: tmux segfault in 5.2 with join-pane
On v, nov 18, 2012 at 08:53:26 -0200, Rafael Ferreira Neves wrote: Hi, This problem seems to be solved with the nicm@ commit: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/tmux/names.c.diff?r1=1.16;r2=1.17;f=h. I hope it helps. [...] Ah, thanks, I've missed that. I just wonder if it is worth giving an OPENBSD_5_2 tag, giving that it is a fairly commonly used feature. Daniel -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: ThinkPad W530 Intel HD Graphics 4000 friendly to puffy?
El Sun, 18 Nov 2012 13:14:32 +0200 Rares Aioanei bsdlis...@gmail.com escribió: On Sun, 18 Nov 2012 11:12:36 +0100 Tomas Bodzar tomas.bod...@gmail.com wrote: Not sure if it's still Sandrybridge http://www.lenovo.com/products/us/tech-specs/laptop/thinkpad/w-series/w530/ All thinkpad models ending in 30 are Ivy Bridge, just as all ending in 20 are Sandy. , but OpenBSD doesn't have KMS yet (just partiall parts) which means that most probably it will work, just don't expect much 3D power on Intel. Best option will be to try install latest snapshot if you can and post dmesg, pcidump -v, usbdevs -v, Xorg.0.log outputs. Thanks appreciate the help. [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] Mine is a T410 with Sandybridge. Graphics work very well, no problem with that. Good performance in general, everything works as it should except USB after resume. The machine is able to suspend and resume but with no power in USB ports. It's a know problem, affecting other thinkpads like X201, I guess.. Theo was trying to fix it, some time ago, without success, at least in my knowledge. BR Jes
Re: Can I change ssh port forwardings on a active connection *non-interactively* ?
On Sun (18/11/12), Darren Tucker wrote: On Fri, Nov 16, 2012 at 12:10:19AM +0200, Manolis Tzanidakis wrote: Hello all, I want to send the '~C' escape to ssh followed by ie. '-L 1024:localhost:1024' from the active ssh connection's shell, non-interactively from a script. Is it possible? Or is there a better way to accomplish this? If you start ssh with ControlMaster mode enabled you can use ssh -O forward to add forwardings to an established connection, eg: $ ssh -o ControlMaster=yes -o ControlPath=/tmp/ctl localhost $ ssh -o ControlMaster=no -o ControlPath=/tmp/ctl -O forward \ -L 1234:127.0.0.1:22 localhost I've tested some options (including ControlMaster) with one of the will-be users of this system and I think I should abandon this plan altogether and give me them pre-defined ssh_configs and putty confs instead. Anyway, thanks for your time Darren and Alexander. -- Manolis Tzanidakis http://mtzanidakis.com/ mtzanidakis[at]gmail[dot]com
Re: tmux segfault in 5.2 with join-pane
You should contact Nicholas Marriott about this. If possible, verify if that commit (full message and files involved in http://marc.info/?l=openbsd-cvsm=134554327203377w=2) actually solves you problem. You could checkout the OPENBSD_5_2 tree, apply that commit changes, and verify if the problem persists. If you get rid of the problem, your message with an attached patch against OPENBSD_5_2 should save him some time and effort. In the case problem persists, you'll have to find on the another commits. What I can say is that in -current that crash doesn't occur. On Sun, Nov 18, 2012 at 9:28 AM, LEVAI Daniel l...@ecentrum.hu wrote: On v, nov 18, 2012 at 08:53:26 -0200, Rafael Ferreira Neves wrote: Hi, This problem seems to be solved with the nicm@ commit: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/tmux/names.c.diff?r1=1.16;r2=1.17;f=h. I hope it helps. [...] Ah, thanks, I've missed that. I just wonder if it is worth giving an OPENBSD_5_2 tag, giving that it is a fairly commonly used feature. Daniel -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: tmux segfault in 5.2 with join-pane
On v, nov 18, 2012 at 10:41:43 -0200, Rafael Ferreira Neves wrote: You should contact Nicholas Marriott about this. If possible, verify if that commit (full message and files involved in http://marc.info/?l=openbsd-cvsm=134554327203377w=2) actually solves you problem. Yes it does; I thought that thanking for the pointer to the patch implied this :) You could checkout the OPENBSD_5_2 tree, apply that commit changes, and verify if the problem persists. If you get rid of the problem, your message with an attached patch against OPENBSD_5_2 should save him some time and effort. I've already stated that I've recompiled the 5.2 tmux source (not sure what do mean under apply that commit changes, but of course, it was not _BASE), so it must have been with an OPENBSD_5_2 tree. Furthermore, the diff in question applies to 5.2. In the case problem persists, you'll have to find on the another commits. What I can say is that in -current that crash doesn't occur. Yes I know that, that's why I reported this against 5.2. Daniel -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: OpenBSD hangs when i unplug USB disk
On Thu, Nov 15, 2012 at 01:04:02PM -0300, Marcos Laufer wrote: | I did this quite often a couple of weeks ago. Haven't tried for a | while (no need) and have upgraded to newer snaps a bunch of times | since. Tonight I'll confirm I can unplug safely on the latest snap. | | Thank you Paul, i look forward for the results of your testing tonight. Apologies for the late response; my Thursday plans got changed at the last minute. However, I've verified that unplugging works fine with the latest snapshot. So no regressions from my POV. Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
Re: Why anyone in their right mind would like to use NAT64
sigh. another essay without actual content. * Daniel Ouellet dan...@presscom.net [2012-10-24 20:00]: NAT always makes connectivity less efficient yeah, right. NAT was sadly a quick way to setup security b***s***. NAT needs to process every packets opposed to the !NAT case, where a router doesn't have to process every packet. rrright. changed the header both in incoming and outgoing traffic opposed to the !NAT case, right. and as bandwidth keep increasing only make the totally not optimize NAT table getting bigger parser error as more traffic is present and increase jitter, latency, etc. Much more powerful router needs to be used and many of the sadly loved firewall appliance by some admin like the SonicWall and the like running out of power on intensive UDP traffic and do not allow the end users to actually get the benefit of their increase line capacity that are more common these days! one thing is clear: you have no clue what you are talking about. once stateful firewalling is in place, the cost of NAT is neglible. IN IPv6, the smallest assigned to remote site is so big anyway and based on the RFC recommendation to provide a /48 to remote site and even a /56 to a single house, how could anyone possibly think he/she would even run of IP's and need NAT64? there are gazillion more (very very valid) use cases for NAT than to preserve IP addresses. Isn't it just a side effect of a sadly miss guided use of NAT in the only miss guided person here is you. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: Why anyone in their right mind would like to use NAT64
* Jussi Peltola pe...@pelzi.net [2012-10-24 21:37]: This is something that can only be fixed by getting rid of the assumption about non-changing host addresses. what a brilliant design. instead of fixing a networking problem at the networking layer change all the layers above, up to and including the application layer. but NAT is bad, right. NATs tend to break my idle SSH sessions that is just one more of the lies spread all over the place. NAT doesn't have ANYTHING to do with that really. what you are seeing are broken devices throwing away state they must not. yes, they are common. and NAT is common. but blaming one on the other is still just wrong. Do your ssh sessions stay up if one of your upstreams starts blackholing but still announces you a full table of routes? now that is even more ridulous. the problem is blackholing, the solution is to not blackhole, not to apply gazillions of stupid workarounds. and guess what: in practice, accidental blackholing is extremely rare. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: Why anyone in their right mind would like to use NAT64
* Otto Moerbeek o...@drijf.net [2012-10-25 16:34]: On Thu, Oct 25, 2012 at 02:23:06PM +, Stuart Henderson wrote: and they get the time between crashes down to an acceptable amount down? I hope you mean up ;-) we're talking about the industry that has gazillions of gsm access points installed with baseband controllers that crash more than once a minute. and instead of fixing their broken software they apply workaround hacks, and since these are of the same quality they apply another layer of workaround hacks, and ... and now THESE PEOPLE apply THEIR APPROACH to the internet, and we're supposed to implement their workaround hacks so that they can continue to deploy shit? brilliant approach. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: ftp(1) errors on an HTTPS url
On Fri, Nov 16, 2012 at 08:23:40PM +, Rodolfo Gouveia wrote: Hello, It seems that https://www.prelude-ids.org doesn't play well with the ftp(1). I normally get an 'improper response': $ ftp -v -d https://www.prelude-ids.org/attachments/download/241/libprelude-1.0.1.tar.gz host www.prelude-ids.org, port (null), path attachments/download/241/libprelude-1.0.1.tar.gz, save as libprelude-1.0.1.tar.gz. Trying 88.190.33.136... Requesting https://www.prelude-ids.org/attachments/download/241/libprelude-1.0.1.tar.gz received 'f' ftp: Improper response from www.prelude-ids.org Tried this with wget and got: $ wget https://www.prelude-ids.org/attachments/download/241/libprelude-1.0.1.tar.gz --2012-11-18 19:34:08-- https://www.prelude-ids.org/attachments/download/241/libprelude-1.0.1.tar.gz Resolving www.prelude-ids.org (www.prelude-ids.org)... 88.190.33.136 Connecting to www.prelude-ids.org (www.prelude-ids.org)|88.190.33.136|:443... connected. ERROR: cannot verify www.prelude-ids.org's certificate, issued by `/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=EssentialSSL CA': Unable to locally verify the issuer's authority. To connect to www.prelude-ids.org insecurely, use `--no-check-certificate'. So maybe the problem is the certificate? This particular URL is from a port that I'm working on so I'll be using wget for FETCH_CMD.
Re: tmux segfault in 5.2 with join-pane
On Sun, Nov 18, 2012 at 10:58 AM, LEVAI Daniel l...@ecentrum.hu wrote: On v, nov 18, 2012 at 10:41:43 -0200, Rafael Ferreira Neves wrote: You should contact Nicholas Marriott about this. If possible, verify if that commit (full message and files involved in http://marc.info/?l=openbsd-cvsm=134554327203377w=2) actually solves you problem. Yes it does; I thought that thanking for the pointer to the patch implied this :) You could checkout the OPENBSD_5_2 tree, apply that commit changes, and verify if the problem persists. If you get rid of the problem, your message with an attached patch against OPENBSD_5_2 should save him some time and effort. I've already stated that I've recompiled the 5.2 tmux source (not sure what do mean under apply that commit changes, but of course, it was not _BASE), so it must have been with an OPENBSD_5_2 tree. Sorry, those changes should mean all the four files changed by nicm commit. Furthermore, the diff in question applies to 5.2. In the case problem persists, you'll have to find on the another commits. What I can say is that in -current that crash doesn't occur. Yes I know that, that's why I reported this against 5.2. Sorry, I coudn't know that you're accustomed to run -current. :) Daniel -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
