Re: X Intel driver update. [TESTING NEEDED]
On Mon, 12 Sep 2011, Owain Ainsworth wrote: On Mon, Sep 12, 2011 at 12:31:46AM +0100, Owain Ainsworth wrote: I've been sitting on various stages of this update for far too long, about time i sent it out. This updates the rendering code in the in-tree intel driver to much more recent versions of the upstream intel driver, while retaining user modesetting code (backporting work by me as well as a few openbsd specific changes). This fixes many bugs and provides a large speed improvement (especially text rendering) on 965 and above chipsets. A few bugfixes from kettenis@ are also present fixing some nagging issues. This is a prerequisite for support for sandybridge chipsets so it would be good to get it into the tree soon. Testing would be much appreciated. Instructions follow: Download the tarball at http://xenocara.org/src/intel_update.tgz move /usr/xenocara/driver/xf86-video-intel out of the way and untar the tgz from xenocara/drivers cd xf86-video-intel make -f Makefile.bsd-wrapper obj make -f Makefile.bsd-wrapper build Please let me know if you find any issues, otherwise reports of which hardware this was testing on to me privately please. The driver on the web has been updated to not have the sandybridge pciids set to match. The occasional PGTBL_ER... resetting gpu: done! message from the kernel I was experiencing in the past seems to have disappeared definitely... Thanks, David
Re: X Intel driver update. [TESTING NEEDED]
On Fri, 23 Sep 2011, David Coppa wrote: On Mon, 12 Sep 2011, Owain Ainsworth wrote: On Mon, Sep 12, 2011 at 12:31:46AM +0100, Owain Ainsworth wrote: I've been sitting on various stages of this update for far too long, about time i sent it out. This updates the rendering code in the in-tree intel driver to much more recent versions of the upstream intel driver, while retaining user modesetting code (backporting work by me as well as a few openbsd specific changes). This fixes many bugs and provides a large speed improvement (especially text rendering) on 965 and above chipsets. A few bugfixes from kettenis@ are also present fixing some nagging issues. This is a prerequisite for support for sandybridge chipsets so it would be good to get it into the tree soon. Testing would be much appreciated. Instructions follow: Download the tarball at http://xenocara.org/src/intel_update.tgz move /usr/xenocara/driver/xf86-video-intel out of the way and untar the tgz from xenocara/drivers cd xf86-video-intel make -f Makefile.bsd-wrapper obj make -f Makefile.bsd-wrapper build Please let me know if you find any issues, otherwise reports of which hardware this was testing on to me privately please. The driver on the web has been updated to not have the sandybridge pciids set to match. The occasional PGTBL_ER... resetting gpu: done! message from the kernel I was experiencing in the past seems to have disappeared definitely... Pardon me, It was a tough day... Forgot to add the relevant informations: OpenBSD 5.0-current (GENERIC.MP) #1: Mon Sep 19 19:40:12 CEST 2011 dco...@latitude.dacolab.dom:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4283801600 (4085MB) avail mem = 4155645952 (3963MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf68e0 (62 entries) bios0: vendor Dell Inc. version A17 date 01/04/2010 bios0: Dell Inc. Latitude D630 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET APIC ASF! MCFG TCPA SLIC SSDT acpi0: wakeup devices PCI0(S5) PCIE(S4) USB1(S0) USB2(S0) USB3(S0) USB4(S0) USB5(S0) EHC2(S0) EHCI(S0) AZAL(S3) RP01(S3) RP02(S4) RP03(S3) RP04(S3) RP05(S3) RP06(S5) LID_(S3) PBTN(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz, 1995.32 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG cpu0: 2MB 64b/line 8-way L2 cache cpu0: apic clock running at 199MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz, 1995.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG cpu1: 2MB 64b/line 8-way L2 cache ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 2 acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 3 (PCIE) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 11 (RP01) acpiprt3 at acpi0: bus 12 (RP02) acpiprt4 at acpi0: bus -1 (RP03) acpiprt5 at acpi0: bus -1 (RP04) acpiprt6 at acpi0: bus -1 (RP05) acpiprt7 at acpi0: bus 9 (RP06) acpiprt8 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpitz0 at acpi0: critical temperature is 99 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: PBTN acpibtn2 at acpi0: SBTN acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT0 not present acpibat1 at acpi0: BAT1 not present acpidock0 at acpi0: GDCK not docked (0) acpivideo0 at acpi0: VID_ acpivideo1 at acpi0: VID_ acpivideo2 at acpi0: VID2 cpu0: Enhanced SpeedStep 1995 MHz: speeds: 2001, 2000, 1600, 1200, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel GM965 Host rev 0x0c vga1 at pci0 dev 2 function 0 Intel GM965 Video rev 0x0c wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0xe000, size 0x1000 inteldrm0 at vga1: apic 2 int 16 drm0 at inteldrm0 Intel GM965 Video rev 0x0c at pci0 dev 2 function 1 not configured uhci0 at pci0 dev 26 function 0 Intel 82801H USB rev 0x02: apic 2 int 20 uhci1 at pci0 dev 26 function 1 Intel 82801H USB rev 0x02: apic 2 int 21 ehci0 at pci0 dev 26 function 7 Intel 82801H USB rev 0x02: apic 2 int 22 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 82801H HD Audio rev 0x02: msi azalia0: codecs: Sigmatel STAC9205X audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 82801H PCIE rev 0x02: msi pci1 at ppb0 bus 11 ppb1 at pci0
Re: Fix for openssl bug #2240
I was told the diff got mangled, so here's another attempt.
--
viq
Index: t1_lib.c
===
RCS file: /cvs/src/lib/libssl/src/ssl/t1_lib.c,v
retrieving revision 1.8
diff -u -d -r1.8 t1_lib.c
--- t1_lib.c10 Feb 2011 22:40:27 - 1.8
+++ t1_lib.c23 Sep 2011 19:38:13 -
@@ -1453,23 +1453,20 @@
int al = SSL_AD_UNRECOGNIZED_NAME;
#ifndef OPENSSL_NO_EC
- /* If we are client and using an elliptic curve cryptography cipher
suite,
then server
-* must return a an EC point formats lists containing uncompressed.
+ /* If we are client and using an elliptic curve cryptography cipher
+* suite, then if server returns an EC point formats lists extension
+* it must contain uncompressed.
*/
unsigned long alg_k = s-s3-tmp.new_cipher-algorithm_mkey;
unsigned long alg_a = s-s3-tmp.new_cipher-algorithm_auth;
if ((s-tlsext_ecpointformatlist != NULL)
(s-tlsext_ecpointformatlist_length 0)
+ (s-session-tlsext_ecpointformatlist != NULL)
(s-session-tlsext_ecpointformatlist_length 0)
((alg_k (SSL_kEECDH|SSL_kECDHr|SSL_kECDHe)) || (alg_a
SSL_aECDSA)))
{
/* we are using an ECC cipher */
size_t i;
unsigned char *list;
int found_uncompressed = 0;
- if ((s-session-tlsext_ecpointformatlist == NULL) ||
(s-session-tlsext_ecpointformatlist_length == 0))
- {
-
SSLerr(SSL_F_SSL_CHECK_SERVERHELLO_TLSEXT,SSL_R_TLS_INVALID_ECPOINTFORMAT_LIS
T);
- return -1;
- }
list = s-session-tlsext_ecpointformatlist;
for (i = 0; i s-session-tlsext_ecpointformatlist_length;
i++)
{
[demime 1.01d removed an attachment of type application/pgp-signature]
Re: Fix for openssl bug #2240
Argh, maybe this time...
--
viq
Index: t1_lib.c
===
RCS file: /cvs/src/lib/libssl/src/ssl/t1_lib.c,v
retrieving revision 1.8
diff -u -d -r1.8 t1_lib.c
--- t1_lib.c10 Feb 2011 22:40:27 - 1.8
+++ t1_lib.c23 Sep 2011 19:38:13 -
@@ -1453,23 +1453,20 @@
int al = SSL_AD_UNRECOGNIZED_NAME;
#ifndef OPENSSL_NO_EC
- /* If we are client and using an elliptic curve cryptography cipher
suite,
then server
-* must return a an EC point formats lists containing uncompressed.
+ /* If we are client and using an elliptic curve cryptography cipher
+* suite, then if server returns an EC point formats lists extension
+* it must contain uncompressed.
*/
unsigned long alg_k = s-s3-tmp.new_cipher-algorithm_mkey;
unsigned long alg_a = s-s3-tmp.new_cipher-algorithm_auth;
if ((s-tlsext_ecpointformatlist != NULL)
(s-tlsext_ecpointformatlist_length 0)
+ (s-session-tlsext_ecpointformatlist != NULL)
(s-session-tlsext_ecpointformatlist_length 0)
((alg_k (SSL_kEECDH|SSL_kECDHr|SSL_kECDHe)) || (alg_a
SSL_aECDSA)))
{
/* we are using an ECC cipher */
size_t i;
unsigned char *list;
int found_uncompressed = 0;
- if ((s-session-tlsext_ecpointformatlist == NULL) ||
(s-session-tlsext_ecpointformatlist_length == 0))
- {
-
SSLerr(SSL_F_SSL_CHECK_SERVERHELLO_TLSEXT,SSL_R_TLS_INVALID_ECPOINTFORMAT_LIS
T);
- return -1;
- }
list = s-session-tlsext_ecpointformatlist;
for (i = 0; i s-session-tlsext_ecpointformatlist_length;
i++)
{
[demime 1.01d removed an attachment of type application/pgp-signature]
Re: Newbie project idea: New POSIX 2008 functionality for ln(1)
Hey everyone, so I got a handful of positive responses to this. I've replied to a few individuals already, but it's been a hectic week so I haven't had a chance to reply to everyone yet. I just wanted to write a quick note to let everyone know that I *will* get back to you this weekend, and also a heads up that I already have two or three diffs in my inbox now for this assignment. :) I'll also try to think of more little tasks like this and try to better organize them in the future. Thanks everyone! On Mon, Sep 19, 2011 at 9:56 AM, Matthew Dempsky matt...@dempsky.org wrote: Here's a small project for someone with basic C programming experience and an understanding of UNIX system calls (e.g., file descriptors and symbolic vs hard links). Thought I'd send it to tech@ first in case anyone's interested in working on it as a starter project. POSIX 2008 added two new flags for the ln(1) utility: -P and -L (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ln.html). See the spec for details, but the basic idea is that if you have a symbolic link foo pointing at bar, then running ln -L foo xyzzy creates xyzzy as a new hard link to the file bar (i.e., the same as ln foo xyzzy), but running ln -P foo xyzzy instead creates xyzzy as a new hard link to the *symbolic link* foo. To do this, you'll need to take advantage of the new linkat(2) system call (already supported by OpenBSD: http://www.openbsd.org/cgi-bin/man.cgi?query=linkat). The relevant new functionality for this project is that it accepts a flag argument to control whether to follow symbolic links or not when creating the hard link. I suggest creating some regression tests to check that your new code works and hasn't broken anything. (You can use lstat(2) to programmatically check that two directory entries refer to the same file by checking that their st_dev and st_ino fields are equal.) Finally, with some clever use of the new *at(2) functionality, you should be able to avoid doing any explicit string concatenation of path names. E.g., for ln x/file1 y/file2 z/file3 path/to/dir, instead of calling: link(x/file1, path/to/dir/file1); link(y/file2, path/to/dir/file2); link(z/file3, path/to/dir/file3); you should be able to do: int dirfd = open(path/to/dir, O_RDWR|O_DIRECTORY); linkat(AT_FDCWD, x/file1, dirfd, file1, AT_SYMLINK_FOLLOW); linkat(AT_FDCWD, y/file2, dirfd, file2, AT_SYMLINK_FOLLOW); linkat(AT_FDCWD, z/file3, dirfd, file3, AT_SYMLINK_FOLLOW); Feel free to privately contact me if you're interested and/or have any questions about this project.
Re: Fix for openssl bug #2240
Apologies, if it doesn't work this last time I give up...
--
viq
Index: t1_lib.c
===
RCS file: /cvs/src/lib/libssl/src/ssl/t1_lib.c,v
retrieving revision 1.8
diff -u -d -r1.8 t1_lib.c
--- t1_lib.c10 Feb 2011 22:40:27 - 1.8
+++ t1_lib.c23 Sep 2011 19:38:13 -
@@ -1453,23 +1453,20 @@
int al = SSL_AD_UNRECOGNIZED_NAME;
#ifndef OPENSSL_NO_EC
- /* If we are client and using an elliptic curve cryptography cipher
suite, then server
-* must return a an EC point formats lists containing uncompressed.
+ /* If we are client and using an elliptic curve cryptography cipher
+* suite, then if server returns an EC point formats lists extension
+* it must contain uncompressed.
*/
unsigned long alg_k = s-s3-tmp.new_cipher-algorithm_mkey;
unsigned long alg_a = s-s3-tmp.new_cipher-algorithm_auth;
if ((s-tlsext_ecpointformatlist != NULL)
(s-tlsext_ecpointformatlist_length 0)
+ (s-session-tlsext_ecpointformatlist != NULL)
(s-session-tlsext_ecpointformatlist_length 0)
((alg_k (SSL_kEECDH|SSL_kECDHr|SSL_kECDHe)) || (alg_a
SSL_aECDSA)))
{
/* we are using an ECC cipher */
size_t i;
unsigned char *list;
int found_uncompressed = 0;
- if ((s-session-tlsext_ecpointformatlist == NULL) ||
(s-session-tlsext_ecpointformatlist_length == 0))
- {
-
SSLerr(SSL_F_SSL_CHECK_SERVERHELLO_TLSEXT,SSL_R_TLS_INVALID_ECPOINTFORMAT_LIST);
- return -1;
- }
list = s-session-tlsext_ecpointformatlist;
for (i = 0; i s-session-tlsext_ecpointformatlist_length;
i++)
{
Re: sftp diff to allow uploading from command line
On Wed, 21 Sep 2011, Loganaden Velvindron wrote: s/similar/A little bit like The diff has issues with stuff like sftp 127.0.0.1. I've fixed it. I think this might get confused by something like: sftp blah user@host: foo user2@host: IMO it would be better to walk all the arguments and then either error (if multiple remote entries were specified) or continue. What do you think? -d
