Re: Sandy Bridge problems
On Fri, Feb 17, 2012 at 10:23:59AM +1100, Rod Whitworth wrote: On Thu, 16 Feb 2012 10:43:28 -0800, Mike Larkin wrote: Intel drivers later than 2.10 are KMS only, which OpenBSD does not support. The version in tree, based from CVS logs, is 2.9.1 with various backports added from later versions, and some one-off work done to support the later Intel chips in UMS. Thanks for the explanation. I guess that, for at least some time, I'm going to be able to experience the sort of environment that users of archs that don't support virtual consoles live with. One difference being that I will have to sudo reboot to get to a console or sudo halt -p when I want a shutdown. I did some reading about UMS vs KMS and noted a Phoronix page showing that for many of their benchmarks ran faster in UMS. Not that it will help us if we can't get UMS drivers for many GPUs. Or maybe some *BSD dev will write a UMS driver, but don't hold your breath 8-) Looks like you've swapped UMS and KMS at least partially. UMS (userland mode settings) is what XFree86 has done historically and it's still the only supported mode of operation for most X drivers in OpenBSD. Newer X drivers for both intel and radeon chipsets on Linux have switched to KMS (Kernel mode settings) where all the magic goo needed to initialized the graphics mode is moved into the kernel and driven by the DRI2 protocol from userland. Owain, kettenis and jcs backported the KMS code for ironlake and sandybridge chipsets from recent intel driver into the 2.9.1 UMS only driver to get some support. In both cases, since Linux switches to graphics mode early during boot and never goes back to text mode, the code to save / restore the text mode is missing. So to support newer chipset we need to implement KMS (and the TTM memory manager for the radeon driver) in the OpenBSD kernel. There have been some efforts toward this, FreeBSD is paying a developper on that, I've started a port during s2k11, but there is nothing ready for testing on our side yet, don't hold your breath. One intriguing thing I spotted was a statement that KMS allowed running X without root privs. There is some tension there I expect. That's partially true. A bit more work is needed, but it's right that KMS is the way to go security wise too. Finally, having wasted a bunch of money (by my standards) getting a machine that avoided broadcom wi-fi and nvidia graphics and had a supported 10/100/1000 NIC (alc), I'd love to know what I should look for in graphics in future in laptop land. Currently, even if not perfect intel chipsets are useable under OpenBSD (I switched to a Thinkpad X220 as my main hacking laptop 2 month ago, and except for crappy iwn performance, it rocks). For ATI chips, if you stay away from chips that require KMS (mostly the recent integrated ones), there are still a bunch of laptops with separate GPUs that should just work with the ati 6.14.3 driver once we figure out how to put it back in OpenBSD. -- Matthieu Herrb
Re: Sandy Bridge problems
Heavily chopped to provide less clutter for busy people On Fri, 17 Feb 2012 10:29:11 +0100, Matthieu Herrb wrote: I did some reading about UMS vs KMS and noted a Phoronix page showing that for many of their benchmarks ran faster in UMS. Not that it will help us if we can't get UMS drivers for many GPUs. Or maybe some *BSD dev will write a UMS driver, but don't hold your breath 8-) Looks like you've swapped UMS and KMS at least partially. Here is a link to the Phoroni story. http://www.phoronix.com/scan.php?page=articleitem=ati_ubuntu_kmsumsnum =1 pages 2 and 3 have the graphs. Every picture tells a story. skip lots Finally, having wasted a bunch of money (by my standards) getting a machine that avoided broadcom wi-fi and nvidia graphics and had a supported 10/100/1000 NIC (alc), I'd love to know what I should look for in graphics in future in laptop land. Currently, even if not perfect intel chipsets are useable under OpenBSD (I switched to a Thinkpad X220 as my main hacking laptop 2 month ago, and except for crappy iwn performance, it rocks). Well, I'd hardly call my machine usable with X given that it only works fine if you tread carefully and don't succumb to the muscle memory temporarily and hit ctl-alt-Fx. If I could get in and out of X and the wscons I wouldn't care about render speed For ATI chips, if you stay away from chips that require KMS (mostly the recent integrated ones), there are still a bunch of laptops with separate GPUs that should just work with the ati 6.14.3 driver once we figure out how to put it back in OpenBSD. The budget doesn't run to sending you my E320 and replacing it with an x220, sadly. If you missed my post on misc@ you can find i at: http://old.nabble.com/Lenovo-E320%3A-strange-things-happen-with-X-td3332 0989.html It is really wierd trying to find where the bug lies in the E320. I have found that the E320 seems to be frozen but it isn't totally. I can have an ssh session running from another host and it doesn't freeze. OTOH I cannot establish an ssh connection when I'm jammed in X. If I do have a session then top looks normal and nothing hits my eye using ps auxwww. I'll keep looking though and if you guys make changes I'll hopefully spot them and do tests. I am subscribed to cvs@ but if I'm away for many days I tend to rush through it on my return. So I'll sample http://www.openbsd.org/cgi-bin/cvsweb/xenocara/driver/xf86-video-intel/ from time to time. Merci beaucoup, Rod/ *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Re: Sandy Bridge problems
On Fri, Feb 17, 2012 at 09:28:16PM +1100, Rod Whitworth wrote: If you missed my post on misc@ you can find i at: http://old.nabble.com/Lenovo-E320%3A-strange-things-happen-with-X-td3332 0989.html It is really wierd trying to find where the bug lies in the E320. I have found that the E320 seems to be frozen but it isn't totally. I can have an ssh session running from another host and it doesn't freeze. OTOH I cannot establish an ssh connection when I'm jammed in X. If I do have a session then top looks normal and nothing hits my eye using ps auxwww. My use is biased, I never use the text mode. so I don't miss it. I'm not sure if you're running the latest version then. this looks like you machine panics while running X. Prior to my commit do xf86-video-intel of jan 31, attempts to use DRI for OpenGL would panic the kernel and leave your machine in a state similar to the one you describe. With DRI disabled, I can't trigger the panic from normal X use (of course the cause of the panic should be fixed in the kernel too, but I didn't have time to figure this out). -- Matthieu Herrb
Re: Sandy Bridge problems
On Thu, Feb 16, 2012 at 10:59:03AM +1100, Rod Whitworth wrote: Hi, I ran into a problem with X in a new Lenovo E320 so I put out a query on misc and got a rapid response from David Coppa which pointed out that my problem was caused by the Intel Sandy Bridge stuff. I didn't need to bug tech@ with that and misc answered me well enough. Why I am posting on tech is that I went hunting for info to see what the state of the Intel driver is at elsewhere and whether that could help us. A friend who is a Linux guru from way back told me that Linux had suffered from the early driver code and that, as far as he knew, it was now fixed. He mentioned 2.17.0 as the version that fixed heaps of bugs. So I did two things: I nailed a copy of the driver source tarball and I grabbed a copy of Fedora 16 that would run as a live cd. I ran the Fedora on the E320 and could not get it to misbehave in any way banging in and out of X and cosole sessions. I untarred the 2.17.0 sources in an isolated dir on my build machine and looked at the code and tried to see if any of it appeared in the current Xenocara code. My eyes are gritty from looking late into the night but I didn't see any matching stuff. Can one who knows tell me this: Do we have 2.17.0 in our tree? If we do it's obvious that there are yet more bugs for Intel and co to fix. If we don't have it can I help? Give me some pointers on using that code and merging it with existing stuff. I have the time and the boxes to work. I'm lacking the recipe. Heck I can even do it on the E320 it has 4GB and 4 cores and plenty of HDD and it doesn't matter if it crashes. Obligatory dmesg follows. It is Genuine Generic compiled about a week ago. It includes the hw.sensors because it is a copy of the one sent to dmesg@ = OpenBSD 5.1-beta (GENERIC.MP) #5: Tue Feb 7 08:26:54 EST 2012 r...@nero.witworx.com:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz (GenuineIntel 686-class) 2.50 GHz cpu0: FPU,V86,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,NXE,LONG,SSE3,PCLMUL,MWAI T,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AE S,XSAVE,AVX,LAHF real mem = 3133054976 (2987MB) avail mem = 3071692800 (2929MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/30/11, BIOS32 rev. 0 @ 0xfc000, SMBIOS rev. 2.6 @ 0xe0830 (71 entries) bios0: vendor LENOVO version 8NET32WW (1.16 ) date 12/01/2011 bios0: LENOVO 1298CTO acpi0 at bios0: rev 4 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP ASF! HPET APIC MCFG SLIC SSDT SSDT UEFI UEFI UEFI acpi0: wakeup devices P0P1(S4) EHC1(S3) EHC2(S3) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) BLAN(S4) PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEG2(S4) PEG3(S4) LID_(S3) 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: apic clock running at 99MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz (GenuineIntel 686-class) 2.50 GHz cpu1: FPU,V86,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,NXE,LONG,SSE3,PCLMUL,MWAI T,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AE S,XSAVE,AVX,LAHF cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz (GenuineIntel 686-class) 2.50 GHz cpu2: FPU,V86,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,NXE,LONG,SSE3,PCLMUL,MWAI T,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AE S,XSAVE,AVX,LAHF cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz (GenuineIntel 686-class) 2.50 GHz cpu3: FPU,V86,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,NXE,LONG,SSE3,PCLMUL,MWAI T,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AE S,XSAVE,AVX,LAHF ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0: bus 2 (RP02) acpiprt4 at acpi0: bus 3 (RP03) acpiprt5 at acpi0: bus -1 (RP04) acpiprt6 at acpi0: bus -1 (RP05) acpiprt7 at acpi0: bus 8 (RP06) acpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus -1 (PEG0) acpiprt11 at acpi0: bus -1 (PEG1) acpiprt12 at acpi0: bus -1 (PEG2) acpiprt13 at acpi0: bus -1 (PEG3) acpiec0 at acpi0 acpicpu0 at acpi0: C2, C1, PSS acpicpu1 at acpi0: C2, C1,
Re: Sandy Bridge problems
On Thu, 16 Feb 2012 10:43:28 -0800, Mike Larkin wrote: Intel drivers later than 2.10 are KMS only, which OpenBSD does not support. The version in tree, based from CVS logs, is 2.9.1 with various backports added from later versions, and some one-off work done to support the later Intel chips in UMS. Thanks for the explanation. I guess that, for at least some time, I'm going to be able to experience the sort of environment that users of archs that don't support virtual consoles live with. One difference being that I will have to sudo reboot to get to a console or sudo halt -p when I want a shutdown. I did some reading about UMS vs KMS and noted a Phoronix page showing that for many of their benchmarks ran faster in UMS. Not that it will help us if we can't get UMS drivers for many GPUs. Or maybe some *BSD dev will write a UMS driver, but don't hold your breath 8-) One intriguing thing I spotted was a statement that KMS allowed running X without root privs. There is some tension there I expect. Finally, having wasted a bunch of money (by my standards) getting a machine that avoided broadcom wi-fi and nvidia graphics and had a supported 10/100/1000 NIC (alc), I'd love to know what I should look for in graphics in future in laptop land. Thanks again, Rod/ *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Re: Sandy Bridge problems
On Fri, Feb 17, 2012 at 12:23 AM, Rod Whitworth glis...@witworx.com wrote: On Thu, 16 Feb 2012 10:43:28 -0800, Mike Larkin wrote: Intel drivers later than 2.10 are KMS only, which OpenBSD does not support. The version in tree, based from CVS logs, is 2.9.1 with various backports added from later versions, and some one-off work done to support the later Intel chips in UMS. Thanks for the explanation. I guess that, for at least some time, I'm going to be able to experience the sort of environment that users of archs that don't support virtual consoles live with. One difference being that I will have to sudo reboot to get to a console or sudo halt -p when I want a shutdown. I did some reading about UMS vs KMS and noted a Phoronix page showing that for many of their benchmarks ran faster in UMS. Not that it will help us if we can't get UMS drivers for many GPUs. Or maybe some *BSD dev will write a UMS driver, but don't hold your breath 8-) One intriguing thing I spotted was a statement that KMS allowed running X without root privs. There is some tension there I expect. Finally, having wasted a bunch of money (by my standards) getting a machine that avoided broadcom wi-fi and nvidia graphics and had a supported 10/100/1000 NIC (alc), I'd love to know what I should look for in graphics in future in laptop land. It looks more and more that pencil and paper will be only open(non Lin/Win only) solution :D Thanks again, Rod/ *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Sandy Bridge problems
Hi, I ran into a problem with X in a new Lenovo E320 so I put out a query on misc and got a rapid response from David Coppa which pointed out that my problem was caused by the Intel Sandy Bridge stuff. I didn't need to bug tech@ with that and misc answered me well enough. Why I am posting on tech is that I went hunting for info to see what the state of the Intel driver is at elsewhere and whether that could help us. A friend who is a Linux guru from way back told me that Linux had suffered from the early driver code and that, as far as he knew, it was now fixed. He mentioned 2.17.0 as the version that fixed heaps of bugs. So I did two things: I nailed a copy of the driver source tarball and I grabbed a copy of Fedora 16 that would run as a live cd. I ran the Fedora on the E320 and could not get it to misbehave in any way banging in and out of X and cosole sessions. I untarred the 2.17.0 sources in an isolated dir on my build machine and looked at the code and tried to see if any of it appeared in the current Xenocara code. My eyes are gritty from looking late into the night but I didn't see any matching stuff. Can one who knows tell me this: Do we have 2.17.0 in our tree? If we do it's obvious that there are yet more bugs for Intel and co to fix. If we don't have it can I help? Give me some pointers on using that code and merging it with existing stuff. I have the time and the boxes to work. I'm lacking the recipe. Heck I can even do it on the E320 it has 4GB and 4 cores and plenty of HDD and it doesn't matter if it crashes. Obligatory dmesg follows. It is Genuine Generic compiled about a week ago. It includes the hw.sensors because it is a copy of the one sent to dmesg@ = OpenBSD 5.1-beta (GENERIC.MP) #5: Tue Feb 7 08:26:54 EST 2012 r...@nero.witworx.com:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz (GenuineIntel 686-class) 2.50 GHz cpu0: FPU,V86,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,NXE,LONG,SSE3,PCLMUL,MWAI T,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AE S,XSAVE,AVX,LAHF real mem = 3133054976 (2987MB) avail mem = 3071692800 (2929MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/30/11, BIOS32 rev. 0 @ 0xfc000, SMBIOS rev. 2.6 @ 0xe0830 (71 entries) bios0: vendor LENOVO version 8NET32WW (1.16 ) date 12/01/2011 bios0: LENOVO 1298CTO acpi0 at bios0: rev 4 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP ASF! HPET APIC MCFG SLIC SSDT SSDT UEFI UEFI UEFI acpi0: wakeup devices P0P1(S4) EHC1(S3) EHC2(S3) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) BLAN(S4) PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEG2(S4) PEG3(S4) LID_(S3) 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: apic clock running at 99MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz (GenuineIntel 686-class) 2.50 GHz cpu1: FPU,V86,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,NXE,LONG,SSE3,PCLMUL,MWAI T,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AE S,XSAVE,AVX,LAHF cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz (GenuineIntel 686-class) 2.50 GHz cpu2: FPU,V86,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,NXE,LONG,SSE3,PCLMUL,MWAI T,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AE S,XSAVE,AVX,LAHF cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz (GenuineIntel 686-class) 2.50 GHz cpu3: FPU,V86,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,NXE,LONG,SSE3,PCLMUL,MWAI T,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AE S,XSAVE,AVX,LAHF ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0: bus 2 (RP02) acpiprt4 at acpi0: bus 3 (RP03) acpiprt5 at acpi0: bus -1 (RP04) acpiprt6 at acpi0: bus -1 (RP05) acpiprt7 at acpi0: bus 8 (RP06) acpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus -1 (PEG0) acpiprt11 at acpi0: bus -1 (PEG1) acpiprt12 at acpi0: bus -1 (PEG2) acpiprt13 at acpi0: bus -1 (PEG3) acpiec0 at acpi0 acpicpu0 at acpi0: C2, C1, PSS acpicpu1 at acpi0: C2, C1, PSS acpicpu2 at acpi0: C2, C1, PSS acpicpu3 at acpi0: C2, C1, PSS acpitz0 at acpi0: critical temperature is 100 degC acpithinkpad0 at acpi0 acpiac0 at acpi0: AC unit online
