Re: [RFC PATCH 0/4] DirectX on Linux
On Tuesday 2020-05-19 22:36, Sasha Levin wrote: > >> - Why DX12 on linux? Looking at this feels like classic divide and > > There is a single usecase for this: WSL2 developer who wants to run > machine learning on his GPU. The developer is working on his laptop, > which is running Windows and that laptop has a single GPU that Windows > is using. It does not feel right conceptually. If the target is a Windows API (DX12/ML), why bother with Linux environments? Make it a Windows executable, thereby skipping the WSL translation layer and passthrough. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: gitlab.fd.o financial situation and impact on services
On Friday 2020-02-28 08:59, Daniel Stone wrote: > >I believe that in January, we had $2082 of network cost (almost >entirely egress; ingress is basically free) and $1750 of >cloud-storage cost (almost all of which was download). That's based >on 16TB of cloud-storage (CI artifacts, container images, file >uploads, Git LFS) egress and 17.9TB of other egress (the web service >itself, repo activity). Projecting that out [×12 for a year] gives >us roughly $45k of network activity alone, I had come to a similar conclusion a few years back: It is not very economic to run ephemereal buildroots (and anything like it) between two (or more) "significant locations" of which one end is located in a Large Cloud datacenter like EC2/AWS/etc. As for such usecases, me and my surrounding peers have used (other) offerings where there is 50 TB free network/month, and yes that may have entailed doing more adminning than elsewhere - but an admin appreciates $2000 a lot more than a corporation, too. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] UAPI: Check headers by compiling all together as C++
On Wednesday 2018-09-05 18:55, Greg KH wrote: >On Wed, Sep 05, 2018 at 04:54:27PM +0100, David Howells wrote: >> >> Here's a set of patches that inserts a step into the build process to make >> sure that the UAPI headers can all be built together with C++ (if the >> compiler being used supports C++). All but the final patch perform fixups, >> including: > >Wait, why do we care? What has recently changed to start to directly >import kernel uapi files into C++ code? With C++11, C++ has become a much nicer language to use (for userspace, anyway). >And if userspace wants to do this, can't they do the C namespace trick >themselves when they do the import? The only trick is to use an extra C source file and extensively wrap things. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 7/7] uapi: export all headers under uapi directories
On Thursday 2017-01-12 16:52, Nicolas Dichtel wrote: >Le 09/01/2017 à 13:56, Christoph Hellwig a écrit : >> On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote: >>> Regularly, when a new header is created in include/uapi/, the developer >>> forgets to add it in the corresponding Kbuild file. This error is usually >>> detected after the release is out. >>> >>> In fact, all headers under uapi directories should be exported, thus it's >>> useless to have an exhaustive list. >>> >>> After this patch, the following files, which were not exported, are now >>> exported (with make headers_install_all): >> >> ... snip ... >> >>> linux/genwqe/.install >>> linux/genwqe/..install.cmd >>> linux/cifs/.install >>> linux/cifs/..install.cmd >> >> I'm pretty sure these should not be exported! >> >Those files are created in every directory: >$ find usr/include/ -name '\.\.install.cmd' | wc -l >71 That still does not mean they should be exported. Anything but headers (and directories as a skeleton structure) is maximally suspicious. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
i915: pipe state still does not match
On Friday 2013-11-29 11:48, Chris Wilson wrote: >> What I could collect so far: > >Thanks, I broke the handling of cropped XvImages along the fast paths. >It should be fixed by: > >commit fd007d9d465b9b3ddbbaf769931ec921a6f5ecb8 >Author: Chris Wilson >Date: Thu Nov 28 21:13:33 2013 + > >sna/video: Correct handling of cropped images along packed fast path I didn't manage to crash X within an hour, so that's commit is looking good. The kernel error message for i915 pipe state however still appears - namely, whenever the X server is terminating, including "reasonably proper" terminations induced with sending SIGTERM to the X process. Could it be that the i915 module does not handle sudden shutdowns (which however can occur at any time) of the /dev/dri/cardN file descriptor well enough?
i915: pipe state still does not match
On Wednesday 2013-11-27 12:08, Chris Wilson wrote: >On Wed, Nov 27, 2013 at 11:59:56AM +0100, Jan Engelhardt wrote: >> >> Despite the i915/drm fixes added in v3.11.8, the X server still >> terminates due to some pipe state bug in 3.11.9. > >X terminating is entirely unconnected with that *ERROR*. Are you sure? Whenever X crashed, that inteldrv kernel message was showing up in dmesg. Affected versions: xorg-x11-server-1.14.3.901 xf86-video-intel-2.99.906-4.1.x86_64 Working versions: xorg-x11-server-1.13.2 xf86-video-intel-2.20.19 >Can you please attach your Xorg.0.log with the crash information? What I could collect so far: [47.331] This is a pre-release version of the X server from The X.Org Foundation. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the "xorg" product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the X.Org Foundation git repository. See http://wiki.x.org/wiki/GitPage for git access instructions. [47.331] X.Org X Server 1.14.3.901 (1.14.4 RC 1) Release Date: 2013-10-26 [47.331] X Protocol Version 11, Revision 0 [47.331] Build Operating System: openSUSE SUSE LINUX [47.331] Current Operating System: Linux nakamura.inai.de 3.11.9-jng20-desktop #1 SMP PREEMPT Wed Nov 27 09:56:23 UTC 2013 (a089a7e) x86_64 [47.331] Kernel command line: root=/dev/disk/by-label/nakamura-root splash=silent showopts video=640x480 [47.332] Build Date: 06 November 2013 10:07:38AM [47.332] [47.332] Current version of pixman: 0.30.2 [47.332]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [47.332] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [47.333] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Nov 28 20:15:00 2013 [47.335] (==) Using config directory: "/etc/X11/xorg.conf.d" [47.335] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [47.378] (==) No Layout section. Using the first Screen section. [47.379] (==) No screen section available. Using defaults. [47.379] (**) |-->Screen "Default Screen Section" (0) [47.379] (**) | |-->Monitor "" [47.395] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [47.395] (==) Automatically adding devices [47.395] (==) Automatically enabling devices [47.395] (==) Automatically adding GPU devices [47.396] (WW) The directory "/usr/share/fonts/misc/sgi" does not exist. [47.396]Entry deleted from font path. [47.396] (==) FontPath set to: /usr/share/fonts/misc:unscaled, /usr/share/fonts/Type1/, /usr/share/fonts/100dpi:unscaled, /usr/share/fonts/75dpi:unscaled, /usr/share/fonts/ghostscript/, /usr/share/fonts/cyrillic:unscaled, /usr/share/fonts/truetype/, built-ins [47.396] (==) ModulePath set to "/usr/lib64/xorg/modules/updates,/usr/lib64/xorg/modules" [47.396] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [47.411] (II) Loader magic: 0x803c20 [47.411] (II) Module ABI versions: [47.411]X.Org ANSI C Emulation: 0.4 [47.411]X.Org Video Driver: 14.1 [47.411]X.Org XInput driver : 19.1 [47.411]X.Org Server Extension : 7.0 [47.412] (II) xfree86: Adding drm device (/dev/dri/card0) [47.416] (--) PCI:*(0:0:2:0) 8086:a011:104d:9075 rev 0, Mem @ 0xfea8/524288, 0xe000/268435456, 0xfe80/1048576, I/O @ 0xf0f0/8 [47.417] (--) PCI: (0:0:2:1) 8086:a012:104d:9075 rev 0, Mem @ 0xfea0/524288 [47.418] Initializing built-in extension Generic Event Extension [47.419] Initializing built-in extension SHAPE [47.419] Initializing built-in extension MIT-SHM [47.419] Initializing built-in extension XInputExtension [47.419] Initializing built-in extension XTEST [47.419] Initializing built-in extension BIG-REQUESTS [47.419] Initializing built-in extension SYNC [47.419] Initializing built-in extension XKEYBOARD [47.419] Initializing built-in extension XC-MISC [47.419] Initializing built-in extension SECURITY [47.419] Initializing built-in extension XINERAMA [47.419] Initializing built-in extension XFIXES [47.420] Initializing built-in extension RENDER [47.420] Initializing built-in extension RANDR [47.420] Initializing built-in extension COMPOSITE [47.420] Initializing built-in extension DAMAGE [47.420] Initializing
i915: pipe state still does not match
Greetings. Despite the i915/drm fixes added in v3.11.8, the X server still terminates due to some pipe state bug in 3.11.9. I have a fb setup to span two crtcs in below's configuration, and the kernel problem is easily triggerable for me by moving an Xv window (such as by using mplayer) forth and back between the two crtc. The problem did not exist in 3.9.9. > xrandr Screen 0: minimum 320 x 200, current 1280 x 1624, maximum 32767 x 32767 LVDS1 connected primary 1024x600+0+1024 (normal left inverted right x axis y axis) 220mm x 129mm 1024x600 60.0*+ 800x60060.3 56.2 640x48059.9 VGA1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 301mm 1280x1024 60.0*+ 75.0 72.0 1152x864 75.0 1024x768 75.1 70.1 60.0 832x62474.6 800x60072.2 75.0 60.3 640x48075.0 72.8 66.7 60.0 720x40070.1 640x35070.1 VIRTUAL1 disconnected (normal left inverted right x axis y axis) [drm:intel_pipe_config_compare] *ERROR* mismatch in adjusted_mode.flags (expected 4, found 0) [ cut here ] WARNING: CPU: 1 PID: 714 at /home/abuild/rpmbuild/BUILD/kernel-desktop-3.11.9~jng20/linux-3.11/drivers/gpu/drm/i915/intel_display.c:8329 check_crtc_state+0x637/0x6a5 [i915]() pipe state doesn't match! Modules linked in: ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipt_REJECT xt_tcpudp xt_owner xt_multiport xt_conntrack iptable_filter af_packet ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 cpufreq_conservative nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack xt_mark iptable_mangle ip_tables x_tables snd_hda_codec_realtek uvcvideo videobuf2_core snd_hda_intel snd_hda_codec snd_hwdep videodev snd_pcm_oss snd_pcm videobuf2_vmalloc iTCO_wdt jme gpio_ich coretemp snd_seq snd_timer pcspkr jmb38x_ms videobuf2_memops iTCO_vendor_support sdhci_pci lpc_ich memstick i2c_i801 snd_seq_device mii sdhci joydev mfd_core snd_mixer_oss led_class mmc_core serio_raw ata_generic acpi_cpufreq battery snd mperf ac shpchp soundcore snd_page_alloc sg tcp_veno sony_laptop rfkill autofs4 btrfs raid6_pq zlib_deflate xor libcrc32c sha256_generic cbc hid_generic usbhid hid uhci_hcd ata_piix i915 drm_kms_helper ehci_pci ehci_hcd drm usbcore usb_common i2c_algo_bit i2c_core video intel_agp intel_gtt agpgart button processor thermal_sys hwmon scsi_dh_emc scsi_dh_alua scsi_dh_rdac scsi_dh_hp_sw scsi_dh dm_snapshot dm_mirror dm_region_hash dm_log dm_crypt dm_mod xts gf128mul aes_x86_64 CPU: 1 PID: 714 Comm: X Tainted: GW3.11.9-jng20-desktop #1 Hardware name: Sony Corporation VPCM11M1E/VAIO, BIOS R0090Z4 01/23/2010 8141925d 88003b5d1788 8103ba85 a01a689b 880037462000 88003b5d17d8 88003b5d1800 8800374626d0 8103bae1 a01e97bb 0018 Call Trace: [] dump_trace+0x8c/0x296 [] show_stack_log_lvl+0x13e/0x14d [] show_stack+0x2f/0x31 [] dump_stack+0x50/0x89 [] warn_slowpath_common+0x74/0x89 [] warn_slowpath_fmt+0x47/0x49 [] check_crtc_state+0x637/0x6a5 [i915] [] intel_modeset_check_state+0x37e/0x604 [i915] [] intel_set_mode+0x1b/0x22 [i915] [] intel_crtc_set_config+0x612/0x789 [i915] [] drm_mode_set_config_internal+0x44/0xac [drm] [] drm_fb_helper_set_par+0x55/0x98 [drm_kms_helper] [] fb_set_var+0x250/0x33b [] fbcon_blank+0x75/0x1c0 [] do_unblank_screen+0xca/0x136 [] vt_ioctl+0x4d5/0xf28 [] tty_ioctl+0x910/0x976 [] vfs_ioctl+0x1b/0x28 [] do_vfs_ioctl+0x32d/0x3e8 [] SyS_ioctl+0x4e/0x7e [] system_call_fastpath+0x1a/0x1f [<7fe31322a1e7>] 0x7fe31322a1e6 ---[ end trace 36d598c7e5fa5f63 ]---
3.5-rc6 nouveau and no text/graphics
Hi, I have here some old classy laptop (Dell Precision M40 PP01X, Pentium3 Mobile CPU) which has, according to lspci, 01:00.0 VGA compatible controller: nVidia Corporation NV11GL [Quadro2 MXR/EX/Go] (rev b2) 01:00.0 0300: 10de:0113 (rev b2) Unfortunately, when loading nouveaufb.ko, all that happens is that the screen goes blank. This occurs on both 2.6.37, 3.1.0, 3.4.4 . The backlight remains on, but there is no more tty1 text or X showing, though, the machine is running and ssh-able. nomodeset is possible as a boot option, but of course does not get me the luxury of framebuffer or Xorg. Anything to try? thanks, Jan -- full dmesg -- [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.5.0-rc6-2-desktop (geeko@buildhost) (gcc version 4.7.1 20120615 [gcc-4_7-branch revision 188649] (SUSE Linux) ) #1 SMP PREEMPT Tue Jul 10 18:52:42 UTC 2012 (8442da0) [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved [0.00] BIOS-e820: [mem 0x0010-0x1ffea7ff] usable [0.00] BIOS-e820: [mem 0x1ffea800-0x1fff] reserved [0.00] BIOS-e820: [mem 0xfeea-0xfeef] reserved [0.00] BIOS-e820: [mem 0xffb8-0x] reserved [0.00] Notice: NX (Execute Disable) protection missing in CPU! [0.00] DMI 2.3 present. [0.00] DMI: Dell Computer Corporation Precision M40 /Precision M40, BIOS A04 09/13/2001 [0.00] e820: update [mem 0x-0x] usable == reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x1ffea max_arch_pfn = 0x100 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-CBFFF write-protect [0.00] CC000-E uncachable [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask FE000 write-back [0.00] 1 base 0FEEA mask E write-through [0.00] 2 disabled [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] PAT not supported by CPU. [0.00] initial memory mapped: [mem 0x-0x011f] [0.00] Base memory trampoline at [c009b000] 9b000 size 16384 [0.00] init_memory_mapping: [mem 0x-0x1ffe9fff] [0.00] [mem 0x-0x001f] page 4k [0.00] [mem 0x0020-0x1fdf] page 2M [0.00] [mem 0x1fe0-0x1ffe9fff] page 4k [0.00] kernel direct mapping tables up to 0x1ffe9fff @ [mem 0x011f5000-0x011f] [0.00] RAMDISK: [mem 0x1f6df000-0x1ffd9fff] [0.00] ACPI: RSDP 000fde50 00014 (v00 DELL ) [0.00] ACPI: RSDT 000fde64 00028 (v01 DELLCPi R 27D1090D ASL 0061) [0.00] ACPI: FACP 000fde90 00074 (v01 DELLCPi R 27D1090D ASL 0061) [0.00] ACPI: DSDT fffe4000 02BB7 (v01 INT430 SYSFexxx 1001 MSFT 010D) [0.00] ACPI: FACS 1800 00040 [0.00] No NUMA configuration found [0.00] Faking a node at [mem 0x-0x1ffe9fff] [0.00] node 0 pfn: [0 - 1ffea] [0.00] remap_alloc: node 0 [1f00-1f60) - [dea0-df00) [0.00] Initmem setup node 0 [mem 0x-0x1ffe9fff] [0.00] NODE_DATA [mem 0x1ea0-0x1ea01fff] (remapped) [0.00] 0MB HIGHMEM available. [0.00] 511MB LOWMEM available. [0.00] max_low_pfn = 1ffea, highstart_pfn = 1ffea [0.00] Low memory ends at vaddr dffea000 [0.00] High memory starts at vaddr dffea000 [0.00] mapped low ram: 0 - 1ffea000 [0.00] low ram: 0 - 1ffea000 [0.00] Node: 0, start_pfn: 10, end_pfn: 9f [0.00] Setting physnode_map array to node 0 for pfns: [0.00] 10 [0.00] Node: 0, start_pfn: 100, end_pfn: 1ffea [0.00] Setting physnode_map array to node 0 for pfns: [0.00] 100 4100 8100 c100 10100 14100 18100 1c100 [0.00] Zone ranges: [0.00] DMA [mem 0x0001-0x00ff] [0.00] Normal [mem 0x0100-0x1ffe9fff] [0.00] HighMem empty [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x0001-0x0009efff] [0.00] node 0: [mem 0x0010-0x1ffe9fff] [0.00] On node 0 totalpages: 130937 [0.00] free_area_init_node: node 0, pgdat dea0, node_mem_map dea02200 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA
3.5-rc6 nouveau and no text/graphics
Hi, I have here some old classy laptop (Dell Precision M40 PP01X, Pentium3 Mobile CPU) which has, according to lspci, 01:00.0 VGA compatible controller: nVidia Corporation NV11GL [Quadro2 MXR/EX/Go] (rev b2) 01:00.0 0300: 10de:0113 (rev b2) Unfortunately, when loading nouveaufb.ko, all that happens is that the screen goes blank. This occurs on both 2.6.37, 3.1.0, 3.4.4 . The backlight remains on, but there is no more tty1 text or X showing, though, the machine is running and ssh-able. "nomodeset" is possible as a boot option, but of course does not get me the luxury of framebuffer or Xorg. Anything to try? thanks, Jan -- full dmesg -- [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.5.0-rc6-2-desktop (geeko at buildhost) (gcc version 4.7.1 20120615 [gcc-4_7-branch revision 188649] (SUSE Linux) ) #1 SMP PREEMPT Tue Jul 10 18:52:42 UTC 2012 (8442da0) [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved [0.00] BIOS-e820: [mem 0x0010-0x1ffea7ff] usable [0.00] BIOS-e820: [mem 0x1ffea800-0x1fff] reserved [0.00] BIOS-e820: [mem 0xfeea-0xfeef] reserved [0.00] BIOS-e820: [mem 0xffb8-0x] reserved [0.00] Notice: NX (Execute Disable) protection missing in CPU! [0.00] DMI 2.3 present. [0.00] DMI: Dell Computer Corporation Precision M40 /Precision M40, BIOS A04 09/13/2001 [0.00] e820: update [mem 0x-0x] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x1ffea max_arch_pfn = 0x100 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-CBFFF write-protect [0.00] CC000-E uncachable [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask FE000 write-back [0.00] 1 base 0FEEA mask E write-through [0.00] 2 disabled [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] PAT not supported by CPU. [0.00] initial memory mapped: [mem 0x-0x011f] [0.00] Base memory trampoline at [c009b000] 9b000 size 16384 [0.00] init_memory_mapping: [mem 0x-0x1ffe9fff] [0.00] [mem 0x-0x001f] page 4k [0.00] [mem 0x0020-0x1fdf] page 2M [0.00] [mem 0x1fe0-0x1ffe9fff] page 4k [0.00] kernel direct mapping tables up to 0x1ffe9fff @ [mem 0x011f5000-0x011f] [0.00] RAMDISK: [mem 0x1f6df000-0x1ffd9fff] [0.00] ACPI: RSDP 000fde50 00014 (v00 DELL ) [0.00] ACPI: RSDT 000fde64 00028 (v01 DELLCPi R 27D1090D ASL 0061) [0.00] ACPI: FACP 000fde90 00074 (v01 DELLCPi R 27D1090D ASL 0061) [0.00] ACPI: DSDT fffe4000 02BB7 (v01 INT430 SYSFexxx 1001 MSFT 010D) [0.00] ACPI: FACS 1800 00040 [0.00] No NUMA configuration found [0.00] Faking a node at [mem 0x-0x1ffe9fff] [0.00] node 0 pfn: [0 - 1ffea] [0.00] remap_alloc: node 0 [1f00-1f60) -> [dea0-df00) [0.00] Initmem setup node 0 [mem 0x-0x1ffe9fff] [0.00] NODE_DATA [mem 0x1ea0-0x1ea01fff] (remapped) [0.00] 0MB HIGHMEM available. [0.00] 511MB LOWMEM available. [0.00] max_low_pfn = 1ffea, highstart_pfn = 1ffea [0.00] Low memory ends at vaddr dffea000 [0.00] High memory starts at vaddr dffea000 [0.00] mapped low ram: 0 - 1ffea000 [0.00] low ram: 0 - 1ffea000 [0.00] Node: 0, start_pfn: 10, end_pfn: 9f [0.00] Setting physnode_map array to node 0 for pfns: [0.00] 10 [0.00] Node: 0, start_pfn: 100, end_pfn: 1ffea [0.00] Setting physnode_map array to node 0 for pfns: [0.00] 100 4100 8100 c100 10100 14100 18100 1c100 [0.00] Zone ranges: [0.00] DMA [mem 0x0001-0x00ff] [0.00] Normal [mem 0x0100-0x1ffe9fff] [0.00] HighMem empty [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x0001-0x0009efff] [0.00] node 0: [mem 0x0010-0x1ffe9fff] [0.00] On node 0 totalpages: 130937 [0.00] free_area_init_node: node 0, pgdat dea0, node_mem_map dea02200 [0.00] DMA zone: 32 pages used for memmap [0.00]
Re: psb_gfx removal
On Tuesday 2012-06-05 18:29, Alan Cox wrote: [Wortmann AG's terra Pad 1051, with a 8086:4102 display chip] 0x4102 is an Oaktrail device (GMA600). The driver supports it providing you have the GMA600 option set. Thanks for the info. Setting GMA600=y works, as in, it results in graphical mode on tty1. However, the gma600 driver seems to default to a backlight value of 0 in Linux 3.4.1; getting a dark screen after loading gma500_gfx.ko is rather unexpected. Furthermore, there are four entries in sysfs, and the one required to change the panel brightness is acpi_video2 (and this one alone). Changing any others, e.g. acpi_video0/brightness, does not have any visible effect. linux-kisn:/sys/class/backlight # ls -l total 0 lrwxrwxrwx 1 root root 0 Jun 7 17:31 acpi_video0 - ../../devices/pci:00/:00:02.0/backlight/acpi_video0 lrwxrwxrwx 1 root root 0 Jun 7 17:31 acpi_video1 - ../../devices/pci:00/:00:02.0/backlight/acpi_video1 lrwxrwxrwx 1 root root 0 Jun 7 17:31 acpi_video2 - ../../devices/pci:00/:00:02.0/backlight/acpi_video2 lrwxrwxrwx 1 root root 0 Jun 7 17:31 oaktrail-bl - ../../devices/virtual/backlight/oaktrail-bl ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
psb_gfx removal
On Tuesday 2012-06-05 18:29, Alan Cox wrote: >> >> [Wortmann AG's terra Pad 1051, with a 8086:4102 display chip] > >0x4102 is an Oaktrail device (GMA600). The driver supports it providing >you have the GMA600 option set. Thanks for the info. Setting GMA600=y works, as in, it results in graphical mode on tty1. However, the gma600 driver seems to default to a backlight value of "0" in Linux 3.4.1; getting a dark screen after loading gma500_gfx.ko is rather unexpected. Furthermore, there are four entries in sysfs, and the one required to change the panel brightness is acpi_video2 (and this one alone). Changing any others, e.g. acpi_video0/brightness, does not have any visible effect. linux-kisn:/sys/class/backlight # ls -l total 0 lrwxrwxrwx 1 root root 0 Jun 7 17:31 acpi_video0 -> ../../devices/pci:00/:00:02.0/backlight/acpi_video0 lrwxrwxrwx 1 root root 0 Jun 7 17:31 acpi_video1 -> ../../devices/pci:00/:00:02.0/backlight/acpi_video1 lrwxrwxrwx 1 root root 0 Jun 7 17:31 acpi_video2 -> ../../devices/pci:00/:00:02.0/backlight/acpi_video2 lrwxrwxrwx 1 root root 0 Jun 7 17:31 oaktrail-bl -> ../../devices/virtual/backlight/oaktrail-bl
psb_gfx removal
Hi, I have here a "Wortmann AG terra Pad 1051", which has a GMA500-like device (PCI ID 8086:4102). Using Linux 3.1.x (openSUSE 12.1's default), loading psb_gfx.ko crashed the machine. I therefore tried Linux 3.4.0, where this crash does not occur thankfully. According to your commit b7cdd9e6323af368e26121c5b791eddc78e79fea, GMA500 is now available through the DRM tree. I take it you mean kernel/drivers/gpu/drm/gma500/gma500_gfx.ko by that. However, gma500_gfx.ko does not provide support for 8086:4102, i.e. modinfo does not show the alias. So, am I correct in the assumption that the 4102 code never really worked, and deletion of psb_gfx was therefore ok without having 4102 support in gma500_gfx? thanks, Jan
psb_gfx removal
Hi, I have here a Wortmann AG terra Pad 1051, which has a GMA500-like device (PCI ID 8086:4102). Using Linux 3.1.x (openSUSE 12.1's default), loading psb_gfx.ko crashed the machine. I therefore tried Linux 3.4.0, where this crash does not occur thankfully. According to your commit b7cdd9e6323af368e26121c5b791eddc78e79fea, GMA500 is now available through the DRM tree. I take it you mean kernel/drivers/gpu/drm/gma500/gma500_gfx.ko by that. However, gma500_gfx.ko does not provide support for 8086:4102, i.e. modinfo does not show the alias. So, am I correct in the assumption that the 4102 code never really worked, and deletion of psb_gfx was therefore ok without having 4102 support in gma500_gfx? thanks, Jan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
drm/radeon: white screen after X does modeswitch from KMS con
Hello, the SONY PCG U3 device has a 00:0c.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon Mobility M6 LY [1002:4c59] graphics card. With linux 3.1.10, X.org server 7.6_1.10.4 and xf86-video-ati-6.14.2, switching from KMS'd console to X on tty7 yields a white screen that also stays when attempting to back to tty1. I have to boot with nomodeset to get a usable Xorg picture. Is it just that radeon_drv does not work together with KMS? = log when starting X from a KMS console = [ 837.009] X.Org X Server 1.10.4 Release Date: 2011-08-19 [ 837.012] X Protocol Version 11, Revision 0 [ 837.013] Build Operating System: openSUSE SUSE LINUX [12.1] [ 837.014] Current Operating System: Linux takeshi 3.1.10-jng3-desktop #1 SMP PREEMPT Sun Jan 22 13:04:41 UTC 2012 (479c31a) i586 [ 837.016] Kernel command line: root=/dev/mapper/root quiet 3 [ 837.018] Build Date: 10 November 2011 03:34:02PM [ 837.019] [ 837.020] Current version of pixman: 0.24.0 [ 837.021]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 837.024] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 837.031] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Feb 14 04:18:10 2012 [ 837.035] (==) Using config directory: "/etc/X11/xorg.conf.d" [ 837.037] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 837.042] (==) No Layout section. Using the first Screen section. [ 837.042] (==) No screen section available. Using defaults. [ 837.042] (**) |-->Screen "Default Screen Section" (0) [ 837.042] (**) | |-->Monitor "" [ 837.044] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 837.044] (==) Automatically adding devices [ 837.044] (==) Automatically enabling devices [ 837.046] (==) FontPath set to: /usr/share/fonts/misc:unscaled, /usr/share/fonts/Type1/, /usr/share/fonts/100dpi:unscaled, /usr/share/fonts/75dpi:unscaled, /usr/share/fonts/URW/, /usr/share/fonts/cyrillic:unscaled, /usr/share/fonts/truetype/, built-ins [ 837.046] (==) ModulePath set to "/usr/lib/xorg/modules/updates,/usr/lib/xorg/modules" [ 837.046] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 837.046] (II) Loader magic: 0x8233d40 [ 837.046] (II) Module ABI versions: [ 837.046]X.Org ANSI C Emulation: 0.4 [ 837.046]X.Org Video Driver: 10.0 [ 837.047]X.Org XInput driver : 12.2 [ 837.047]X.Org Server Extension : 5.0 [ 837.054] (--) PCI:*(0:0:12:0) 1002:4c59:104d:810f rev 0, Mem @ 0xf000/134217728, 0xe811/65536, I/O @ 0x2000/256, BIOS @ 0x/131072 [ 837.060] (II) Open ACPI successful (/var/run/acpid.socket) [ 837.061] (II) LoadModule: "extmod" [ 837.069] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so [ 837.070] (II) Module extmod: vendor="X.Org Foundation" [ 837.071]compiled for 1.10.4, module version = 1.0.0 [ 837.071]Module class: X.Org Server Extension [ 837.071]ABI class: X.Org Server Extension, version 5.0 [ 837.071] (II) Loading extension MIT-SCREEN-SAVER [ 837.071] (II) Loading extension XFree86-VidModeExtension [ 837.071] (II) Loading extension XFree86-DGA [ 837.071] (II) Loading extension DPMS [ 837.071] (II) Loading extension XVideo [ 837.071] (II) Loading extension XVideo-MotionCompensation [ 837.071] (II) Loading extension X-Resource [ 837.072] (II) LoadModule: "dbe" [ 837.075] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so [ 837.077] (II) Module dbe: vendor="X.Org Foundation" [ 837.077]compiled for 1.10.4, module version = 1.0.0 [ 837.077]Module class: X.Org Server Extension [ 837.077]ABI class: X.Org Server Extension, version 5.0 [ 837.077] (II) Loading extension DOUBLE-BUFFER [ 837.077] (II) LoadModule: "glx" [ 837.081] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 837.083] (II) Module glx: vendor="X.Org Foundation" [ 837.083]compiled for 1.10.4, module version = 1.0.0 [ 837.083]ABI class: X.Org Server Extension, version 5.0 [ 837.083] (==) AIGLX enabled [ 837.083] (II) Loading extension GLX [ 837.084] (II) LoadModule: "record" [ 837.088] (II) Loading /usr/lib/xorg/modules/extensions/librecord.so [ 837.089] (II) Module record: vendor="X.Org Foundation" [ 837.089]compiled for 1.10.4, module version = 1.13.0 [ 837.089]Module class: X.Org Server Extension [ 837.089]ABI class: X.Org Server Extension, version 5.0 [ 837.089] (II) Loading extension RECORD [ 837.089] (II) LoadModule: "dri" [ 837.094] (II) Loading /usr/lib/xorg/modules/extensions/libdri.so [
drm/radeon: white screen after X does modeswitch from KMS con
Hello, the SONY PCG U3 device has a 00:0c.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon Mobility M6 LY [1002:4c59] graphics card. With linux 3.1.10, X.org server 7.6_1.10.4 and xf86-video-ati-6.14.2, switching from KMS'd console to X on tty7 yields a white screen that also stays when attempting to back to tty1. I have to boot with nomodeset to get a usable Xorg picture. Is it just that radeon_drv does not work together with KMS? = log when starting X from a KMS console = [ 837.009] X.Org X Server 1.10.4 Release Date: 2011-08-19 [ 837.012] X Protocol Version 11, Revision 0 [ 837.013] Build Operating System: openSUSE SUSE LINUX [12.1] [ 837.014] Current Operating System: Linux takeshi 3.1.10-jng3-desktop #1 SMP PREEMPT Sun Jan 22 13:04:41 UTC 2012 (479c31a) i586 [ 837.016] Kernel command line: root=/dev/mapper/root quiet 3 [ 837.018] Build Date: 10 November 2011 03:34:02PM [ 837.019] [ 837.020] Current version of pixman: 0.24.0 [ 837.021]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 837.024] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 837.031] (==) Log file: /var/log/Xorg.0.log, Time: Tue Feb 14 04:18:10 2012 [ 837.035] (==) Using config directory: /etc/X11/xorg.conf.d [ 837.037] (==) Using system config directory /usr/share/X11/xorg.conf.d [ 837.042] (==) No Layout section. Using the first Screen section. [ 837.042] (==) No screen section available. Using defaults. [ 837.042] (**) |--Screen Default Screen Section (0) [ 837.042] (**) | |--Monitor default monitor [ 837.044] (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. [ 837.044] (==) Automatically adding devices [ 837.044] (==) Automatically enabling devices [ 837.046] (==) FontPath set to: /usr/share/fonts/misc:unscaled, /usr/share/fonts/Type1/, /usr/share/fonts/100dpi:unscaled, /usr/share/fonts/75dpi:unscaled, /usr/share/fonts/URW/, /usr/share/fonts/cyrillic:unscaled, /usr/share/fonts/truetype/, built-ins [ 837.046] (==) ModulePath set to /usr/lib/xorg/modules/updates,/usr/lib/xorg/modules [ 837.046] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 837.046] (II) Loader magic: 0x8233d40 [ 837.046] (II) Module ABI versions: [ 837.046]X.Org ANSI C Emulation: 0.4 [ 837.046]X.Org Video Driver: 10.0 [ 837.047]X.Org XInput driver : 12.2 [ 837.047]X.Org Server Extension : 5.0 [ 837.054] (--) PCI:*(0:0:12:0) 1002:4c59:104d:810f rev 0, Mem @ 0xf000/134217728, 0xe811/65536, I/O @ 0x2000/256, BIOS @ 0x/131072 [ 837.060] (II) Open ACPI successful (/var/run/acpid.socket) [ 837.061] (II) LoadModule: extmod [ 837.069] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so [ 837.070] (II) Module extmod: vendor=X.Org Foundation [ 837.071]compiled for 1.10.4, module version = 1.0.0 [ 837.071]Module class: X.Org Server Extension [ 837.071]ABI class: X.Org Server Extension, version 5.0 [ 837.071] (II) Loading extension MIT-SCREEN-SAVER [ 837.071] (II) Loading extension XFree86-VidModeExtension [ 837.071] (II) Loading extension XFree86-DGA [ 837.071] (II) Loading extension DPMS [ 837.071] (II) Loading extension XVideo [ 837.071] (II) Loading extension XVideo-MotionCompensation [ 837.071] (II) Loading extension X-Resource [ 837.072] (II) LoadModule: dbe [ 837.075] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so [ 837.077] (II) Module dbe: vendor=X.Org Foundation [ 837.077]compiled for 1.10.4, module version = 1.0.0 [ 837.077]Module class: X.Org Server Extension [ 837.077]ABI class: X.Org Server Extension, version 5.0 [ 837.077] (II) Loading extension DOUBLE-BUFFER [ 837.077] (II) LoadModule: glx [ 837.081] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 837.083] (II) Module glx: vendor=X.Org Foundation [ 837.083]compiled for 1.10.4, module version = 1.0.0 [ 837.083]ABI class: X.Org Server Extension, version 5.0 [ 837.083] (==) AIGLX enabled [ 837.083] (II) Loading extension GLX [ 837.084] (II) LoadModule: record [ 837.088] (II) Loading /usr/lib/xorg/modules/extensions/librecord.so [ 837.089] (II) Module record: vendor=X.Org Foundation [ 837.089]compiled for 1.10.4, module version = 1.13.0 [ 837.089]Module class: X.Org Server Extension [ 837.089]ABI class: X.Org Server Extension, version 5.0 [ 837.089] (II) Loading extension RECORD [ 837.089] (II) LoadModule: dri [ 837.094] (II) Loading /usr/lib/xorg/modules/extensions/libdri.so [ 837.095] (II) Module dri:
(Short?) merge window reminder
On Tuesday 2011-05-24 20:48, eschvoca wrote: >On Tue, May 24, 2011 at 1:41 PM, Linus Torvalds wrote: >> >> It's not about features. It hasn't been about features for forever. > >Using the date also clearly communicates it is not about features. On the contrary: Whenever a 2.6.x release was set out the door, there was at least one new feature in the cycle. Given the endless manpower that seems to trail Linux, that seems unlikely to change in the near term. On "It is not about features" - it is not /just/ about features - it is also about fixes, which are equally important, and they also warrant a version bump of some sort on their own. Pointing out the obvious, the stable serieses. "Fleeing" to date-based version numbering seems like an excuse for making way for releases without any change whatsoever. (IOW, if there were features/fixes, a non-date based scheme of incremental numbers could indicate them already.) >Me, a nobody end user, would prefer a version number that corresponded >to the date. Something like: > >%y.%m. >%Y.%m. Except that LINUX_KERNEL_VERSION has only 8 bits for each, so 2011 is out of range, which would need to kept in mind. And a 2-digit spec.. nah that does not feel very 100-year proof. (Just look at struct tm.tm_year for the mess 2-digits made technically.) >Then users would know the significance of the number and when a vendor >says they support Linux 11.09 the user will immediately know if they >are up to date. An added issue with that would be that numbers would not increase in same-sized steps anymore and leave gaps. (There would probably be no 11.06 between 11.05 aka 2.6.39 and 11.07-or-so aka 2.6.40) My 2?.
Re: (Short?) merge window reminder
On Tuesday 2011-05-24 17:46, Ralf Baechle wrote: On Tue, May 24, 2011 at 03:43:48PM +0100, Alan Cox wrote: Can we drop most of MCA, EISA and ISA bus if we are going to have a big version change ? A driver spring clean is much overdue and it's all in git in case someone wishes to sneak out at midnight and bring some crawly horror back from the dead. Dunno about MCA but I doubt we can kill all of (E)ISA. i8253, i8259 and a few others still refuse hard to die. Is it worth to setup a system to track success / failure reports for drivers and ditch drivers once there are no success reports for a driver for too long? It may not be a good idea - people tend not report success much more rarely than failure. (On that matter, I wonder if there are 5.25 USB floppy drives ...) If there were, they would appear as Mass Storage devices (at least the 3.5 USB floppy gadgets do), and as such, don't depend on ISA or the classic floppy driver at all. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tuesday 2011-05-24 20:48, eschvoca wrote: On Tue, May 24, 2011 at 1:41 PM, Linus Torvalds wrote: It's not about features. It hasn't been about features for forever. Using the date also clearly communicates it is not about features. On the contrary: Whenever a 2.6.x release was set out the door, there was at least one new feature in the cycle. Given the endless manpower that seems to trail Linux, that seems unlikely to change in the near term. On It is not about features - it is not /just/ about features - it is also about fixes, which are equally important, and they also warrant a version bump of some sort on their own. Pointing out the obvious, the stable serieses. Fleeing to date-based version numbering seems like an excuse for making way for releases without any change whatsoever. (IOW, if there were features/fixes, a non-date based scheme of incremental numbers could indicate them already.) Me, a nobody end user, would prefer a version number that corresponded to the date. Something like: %y.%m.stable patch %Y.%m.stable patch Except that LINUX_KERNEL_VERSION has only 8 bits for each, so 2011 is out of range, which would need to kept in mind. And a 2-digit spec.. nah that does not feel very 100-year proof. (Just look at struct tm.tm_year for the mess 2-digits made technically.) Then users would know the significance of the number and when a vendor says they support Linux 11.09 the user will immediately know if they are up to date. An added issue with that would be that numbers would not increase in same-sized steps anymore and leave gaps. (There would probably be no 11.06 between 11.05 aka 2.6.39 and 11.07-or-so aka 2.6.40) My 2円. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
(Short?) merge window reminder
On Tuesday 2011-05-24 17:46, Ralf Baechle wrote: >On Tue, May 24, 2011 at 03:43:48PM +0100, Alan Cox wrote: > >> Can we drop most of MCA, EISA and ISA bus if we are going to have a big >> version change ? A driver spring clean is much overdue and it's all in >> git in case someone wishes to sneak out at midnight and bring some crawly >> horror back from the dead. > >Dunno about MCA but I doubt we can kill all of (E)ISA. i8253, i8259 and a >few others still refuse hard to die. > >Is it worth to setup a system to track success / failure reports for >drivers and ditch drivers once there are no success reports for a driver >for too long? It may not be a good idea - people tend not report success >much more rarely than failure. > >(On that matter, I wonder if there are 5.25" USB floppy drives ...) If there were, they would appear as Mass Storage devices (at least the 3.5" USB floppy gadgets do), and as such, don't depend on ISA or the classic floppy driver at all.
(Short?) merge window reminder
On Tuesday 2011-05-24 14:30, Jacek Luczak wrote:
>2011/5/24 Jan Engelhardt :
>> On Tuesday 2011-05-24 01:33, Linus Torvalds wrote:
>>
>>>Another advantage of switching numbering models (ie 3.0 instead of
>>>2.8.x) would be that it would also make the "odd numbers are also
>>>numbers" transition much more natural.
>>>
>>>Because of our historical even/odd model, I wouldn't do a 2.7.x -
>>>there's just too much history of 2.1, 2.3, 2.5 being development
>>>trees.
>>
>> .oO(Though once 2.{7 or more, odd} trickle into the distros, it would
>> become pretty much apparent that they are not devel.)
>>
>>>And then in another few years (probably before getting close to 3.40,
>>>so I'm not going to make a big deal of 3 = "third decade"), I'd just
>>>do 4.0 etc.
>>
>> While 2.6 has certainly worn out, already thinking of a 4.0 is highly
>> reminiscient of the version number arms race Firefox and ChromeBrowser
>> are doing currently.
>>
>>>Because all our releases are supposed to be stable releases these
>>>days, and if we get rid of one level of numbering, I feel perfectly
>>>fine with getting rid of the even/odd history too.
>>
>> If I remember past-time discussions right, ELF was the contributing
>> factor to bump the major number to 2.0 back then; ever since 2.0, no
>> similarly breakthrough-ing event has occurred.
>
>What then about BKL removal? Nice place to celebrate with version jump
>and heaving some beers.
The BKL going away was not a change that would require new
userspace programs.
(Short?) merge window reminder
On Tuesday 2011-05-24 01:33, Linus Torvalds wrote:
>Another advantage of switching numbering models (ie 3.0 instead of
>2.8.x) would be that it would also make the "odd numbers are also
>numbers" transition much more natural.
>
>Because of our historical even/odd model, I wouldn't do a 2.7.x -
>there's just too much history of 2.1, 2.3, 2.5 being development
>trees.
.oO(Though once 2.{7 or more, odd} trickle into the distros, it would
become pretty much apparent that they are not devel.)
>And then in another few years (probably before getting close to 3.40,
>so I'm not going to make a big deal of 3 = "third decade"), I'd just
>do 4.0 etc.
While 2.6 has certainly worn out, already thinking of a 4.0 is highly
reminiscient of the version number arms race Firefox and ChromeBrowser
are doing currently.
>Because all our releases are supposed to be stable releases these
>days, and if we get rid of one level of numbering, I feel perfectly
>fine with getting rid of the even/odd history too.
If I remember past-time discussions right, ELF was the contributing
factor to bump the major number to 2.0 back then; ever since 2.0, no
similarly breakthrough-ing event has occurred.
Re: (Short?) merge window reminder
On Tuesday 2011-05-24 01:33, Linus Torvalds wrote:
Another advantage of switching numbering models (ie 3.0 instead of
2.8.x) would be that it would also make the odd numbers are also
numbers transition much more natural.
Because of our historical even/odd model, I wouldn't do a 2.7.x -
there's just too much history of 2.1, 2.3, 2.5 being development
trees.
.oO(Though once 2.{7 or more, odd} trickle into the distros, it would
become pretty much apparent that they are not devel.)
And then in another few years (probably before getting close to 3.40,
so I'm not going to make a big deal of 3 = third decade), I'd just
do 4.0 etc.
While 2.6 has certainly worn out, already thinking of a 4.0 is highly
reminiscient of the version number arms race Firefox and ChromeBrowser
are doing currently.
Because all our releases are supposed to be stable releases these
days, and if we get rid of one level of numbering, I feel perfectly
fine with getting rid of the even/odd history too.
If I remember past-time discussions right, ELF was the contributing
factor to bump the major number to 2.0 back then; ever since 2.0, no
similarly breakthrough-ing event has occurred.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tuesday 2011-05-24 14:30, Jacek Luczak wrote:
2011/5/24 Jan Engelhardt jeng...@medozas.de:
On Tuesday 2011-05-24 01:33, Linus Torvalds wrote:
Another advantage of switching numbering models (ie 3.0 instead of
2.8.x) would be that it would also make the odd numbers are also
numbers transition much more natural.
Because of our historical even/odd model, I wouldn't do a 2.7.x -
there's just too much history of 2.1, 2.3, 2.5 being development
trees.
.oO(Though once 2.{7 or more, odd} trickle into the distros, it would
become pretty much apparent that they are not devel.)
And then in another few years (probably before getting close to 3.40,
so I'm not going to make a big deal of 3 = third decade), I'd just
do 4.0 etc.
While 2.6 has certainly worn out, already thinking of a 4.0 is highly
reminiscient of the version number arms race Firefox and ChromeBrowser
are doing currently.
Because all our releases are supposed to be stable releases these
days, and if we get rid of one level of numbering, I feel perfectly
fine with getting rid of the even/odd history too.
If I remember past-time discussions right, ELF was the contributing
factor to bump the major number to 2.0 back then; ever since 2.0, no
similarly breakthrough-ing event has occurred.
What then about BKL removal? Nice place to celebrate with version jump
and heaving some beers.
The BKL going away was not a change that would require new
userspace programs.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[patch] drm: fix "persistant" typo
parent 9e7e37e88264e35f3ba6d0dc1da8dd95e70f2b3f (v2.6.39-rc1-185-g9e7e37e)
commit b0ef5d4e28cd127eef94b300f27ba0104deb5ad6
Author: Jan Engelhardt
Date: Mon Apr 4 01:24:58 2011 +0200
drm: fix "persistant" typo
Signed-off-by: Jan Engelhardt
---
drivers/gpu/drm/nouveau/nouveau_gem.c |2 +-
drivers/gpu/drm/ttm/ttm_bo.c | 10 +-
drivers/gpu/drm/ttm/ttm_tt.c | 16
include/drm/ttm/ttm_bo_api.h | 18 +-
include/drm/ttm/ttm_bo_driver.h |4 ++--
5 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index e8b04f4..b52e460 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -97,7 +97,7 @@ nouveau_gem_new(struct drm_device *dev, struct
nouveau_channel *chan,
return -ENOMEM;
}
- nvbo->bo.persistant_swap_storage = nvbo->gem->filp;
+ nvbo->bo.persistent_swap_storage = nvbo->gem->filp;
nvbo->gem->driver_private = nvbo;
return 0;
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 0b6a55a..2e618b5 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1168,7 +1168,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
uint32_t page_alignment,
unsigned long buffer_start,
bool interruptible,
- struct file *persistant_swap_storage,
+ struct file *persistent_swap_storage,
size_t acc_size,
void (*destroy) (struct ttm_buffer_object *))
{
@@ -1211,7 +1211,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
bo->priv_flags = 0;
bo->mem.placement = (TTM_PL_FLAG_SYSTEM | TTM_PL_FLAG_CACHED);
bo->seq_valid = false;
- bo->persistant_swap_storage = persistant_swap_storage;
+ bo->persistent_swap_storage = persistent_swap_storage;
bo->acc_size = acc_size;
atomic_inc(>glob->bo_count);
@@ -1260,7 +1260,7 @@ int ttm_bo_create(struct ttm_bo_device *bdev,
uint32_t page_alignment,
unsigned long buffer_start,
bool interruptible,
- struct file *persistant_swap_storage,
+ struct file *persistent_swap_storage,
struct ttm_buffer_object **p_bo)
{
struct ttm_buffer_object *bo;
@@ -1282,7 +1282,7 @@ int ttm_bo_create(struct ttm_bo_device *bdev,
ret = ttm_bo_init(bdev, bo, size, type, placement, page_alignment,
buffer_start, interruptible,
- persistant_swap_storage, acc_size, NULL);
+ persistent_swap_storage, acc_size, NULL);
if (likely(ret == 0))
*p_bo = bo;
@@ -1863,7 +1863,7 @@ static int ttm_bo_swapout(struct ttm_mem_shrink *shrink)
if (bo->bdev->driver->swap_notify)
bo->bdev->driver->swap_notify(bo);
- ret = ttm_tt_swapout(bo->ttm, bo->persistant_swap_storage);
+ ret = ttm_tt_swapout(bo->ttm, bo->persistent_swap_storage);
out:
/**
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 86d5b17..90e23e0 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -332,7 +332,7 @@ void ttm_tt_destroy(struct ttm_tt *ttm)
ttm_tt_free_page_directory(ttm);
}
- if (!(ttm->page_flags & TTM_PAGE_FLAG_PERSISTANT_SWAP) &&
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_PERSISTENT_SWAP) &&
ttm->swap_storage)
fput(ttm->swap_storage);
@@ -503,7 +503,7 @@ static int ttm_tt_swapin(struct ttm_tt *ttm)
page_cache_release(from_page);
}
- if (!(ttm->page_flags & TTM_PAGE_FLAG_PERSISTANT_SWAP))
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_PERSISTENT_SWAP))
fput(swap_storage);
ttm->swap_storage = NULL;
ttm->page_flags &= ~TTM_PAGE_FLAG_SWAPPED;
@@ -514,7 +514,7 @@ out_err:
return ret;
}
-int ttm_tt_swapout(struct ttm_tt *ttm, struct file *persistant_swap_storage)
+int ttm_tt_swapout(struct ttm_tt *ttm, struct file *persistent_swap_storage)
{
struct address_space *swap_space;
struct file *swap_storage;
@@ -540,7 +540,7 @@ int ttm_tt_swapout(struct ttm_tt *ttm, struct file
*persistant_swap_storage)
return 0;
}
- if (!persistant_swap_storage) {
+ if (!persistent_swap_storage) {
swap_storage = shmem_file_setup("ttm swap",
ttm->num_pages << PAGE_SHIFT,
0);
@@ -549,7 +549,7
[alsa-devel] No mixers on ATI RS780 Azalia
On Monday 2010-06-07 17:03, Alex Deucher wrote: >> * Why is it that I am only allowed to have sound in graphics mode? > >HDMI audio is only enabled on active outputs during modeset. Bleh. If it shows text, that seems pretty active to me. >> * The radeon.ko module does not have any PCI IDs defined, thus does not >> get autoloaded like i915.ko. Is this intentional? It also seems >> to default to modeset=0. > >What kernel are you using? It definitely has pci ids and autoloads just fine. 17:20 lxwks:~ > modinfo radeon filename: /lib/modules/2.6.31.12-jen93-rt/kernel/drivers/gpu/drm/radeon/radeon.ko license:GPL and additional rights description:ATI Radeon author: Gareth Hughes, Keith Whitwell, others. srcversion: D95F7F85D05C72112F277F3 depends:drm vermagic: 2.6.31.12-jen93-rt SMP preempt mod_unload modversions 686 parm: no_wb:Disable AGP writeback for scratch registers (int) 17:23 samsung:~ # modinfo radeon filename: /lib/modules/2.6.35-rc2-default+/kernel/drivers/gpu/drm/radeon/radeon.ko license:GPL and additional rights description:ATI Radeon author: Gareth Hughes, Keith Whitwell, others. firmware: radeon/R520_cp.bin firmware: radeon/RS600_cp.bin firmware: radeon/RS690_cp.bin firmware: radeon/R420_cp.bin firmware: radeon/R300_cp.bin firmware: radeon/R200_cp.bin firmware: radeon/R100_cp.bin firmware: radeon/RV710_me.bin firmware: radeon/RV710_pfp.bin firmware: radeon/RV730_me.bin firmware: radeon/RV730_pfp.bin firmware: radeon/RV770_me.bin firmware: radeon/RV770_pfp.bin firmware: radeon/RS780_me.bin firmware: radeon/RS780_pfp.bin firmware: radeon/RV670_me.bin firmware: radeon/RV670_pfp.bin firmware: radeon/RV635_me.bin firmware: radeon/RV635_pfp.bin firmware: radeon/RV620_me.bin firmware: radeon/RV620_pfp.bin firmware: radeon/RV630_me.bin firmware: radeon/RV630_pfp.bin firmware: radeon/RV610_me.bin firmware: radeon/RV610_pfp.bin firmware: radeon/R600_me.bin firmware: radeon/R600_pfp.bin firmware: radeon/R520_cp.bin firmware: radeon/RS600_cp.bin firmware: radeon/RS690_cp.bin firmware: radeon/R420_cp.bin firmware: radeon/R300_cp.bin firmware: radeon/R200_cp.bin firmware: radeon/R100_cp.bin firmware: radeon/CYPRESS_rlc.bin firmware: radeon/CYPRESS_me.bin firmware: radeon/CYPRESS_pfp.bin firmware: radeon/JUNIPER_rlc.bin firmware: radeon/JUNIPER_me.bin firmware: radeon/JUNIPER_pfp.bin firmware: radeon/REDWOOD_rlc.bin firmware: radeon/REDWOOD_me.bin firmware: radeon/REDWOOD_pfp.bin firmware: radeon/CEDAR_rlc.bin firmware: radeon/CEDAR_me.bin firmware: radeon/CEDAR_pfp.bin firmware: radeon/R700_rlc.bin firmware: radeon/R600_rlc.bin firmware: radeon/RV710_me.bin firmware: radeon/RV710_pfp.bin firmware: radeon/RV730_me.bin firmware: radeon/RV730_pfp.bin firmware: radeon/RV770_me.bin firmware: radeon/RV770_pfp.bin firmware: radeon/RS780_me.bin firmware: radeon/RS780_pfp.bin firmware: radeon/RV670_me.bin firmware: radeon/RV670_pfp.bin firmware: radeon/RV635_me.bin firmware: radeon/RV635_pfp.bin firmware: radeon/RV620_me.bin firmware: radeon/RV620_pfp.bin firmware: radeon/RV630_me.bin firmware: radeon/RV630_pfp.bin firmware: radeon/RV610_me.bin firmware: radeon/RV610_pfp.bin firmware: radeon/R600_me.bin firmware: radeon/R600_pfp.bin srcversion: DF143D97DD12F63E6EEAF3F depends:drm,drm_kms_helper,ttm,i2c-core,i2c-algo-bit vermagic: 2.6.35-rc2-default+ SMP mod_unload modversions parm: no_wb:Disable AGP writeback for scratch registers (int) parm: modeset:Disable/Enable modesetting (int) parm: dynclks:Disable/Enable dynamic clocks (int) parm: r4xx_atom:Enable ATOMBIOS modesetting for R4xx (int) parm: vramlimit:Restrict VRAM for testing (int) parm: agpmode:AGP Mode (-1 == PCI) (int) parm: gartsize:Size of PCIE/IGP gart to setup in megabytes (32,64, etc) (int) parm: benchmark:Run benchmark (int) parm: test:Run tests (int) parm: connector_table:Force connector table (int) parm: tv:TV enable (0 = disable) (int) parm: new_pll:Select new PLL code (int) parm: audio:Audio enable (0 = disable) (int) parm: disp_priority:Display Priority (0 = auto, 1 = normal, 2 = high) (int) parm: hw_i2c:hw i2c engine enable (0 = disable) (int) 17:24 samsung:~/linux-2.6 # git describe v2.6.35-rc2-1-g386f40c 17:25 samsung:../gpu/drm # git grep PCI_DEVICE_TABLE radeon/ 17:25 samsung:../gpu/drm #
[alsa-devel] No mixers on ATI RS780 Azalia
On Thursday 2010-05-27 14:34, Clemens Ladisch wrote: >Clemens Ladisch wrote: >> Please do not assume that the "HDMI" device is the right one, since you >> never got either one to work in Linux. > >Hmm, that computer is separate from the actual LCD, which has an HDMI >input, so it's possible that the HDMI output would be correct. > >In that case, it's likely that you've run into this bug: >https://bugs.freedesktop.org/show_bug.cgi?id=28030 > >You might try the patch mentioned there, or radeonhd, or fglrx. Cc'ing drm. I conclude further tests. * Linux 2.6.35-rc2 - fbcon:radeondrmfb using "modprobe radeon modeset=1" - sound ok - Xorg (7.4) with 'radeonhd' - fbcon ok, no sound in Xorg - I figure radeonhd is obsolete - Xorg with 'radeon' - fbcon ok, xorg ok. There is a small breakdown when switching between fbcon and xorg * Linux 2.6.33.5 - like 2.6.35-rc2, but had a bug that prevented radeon.ko to go into graphics mode when initially loaded; workaround: modprobe fglrx; rmmod fglrx; modprobe radeon modeset=1 - or fglrx, also makes sound work - fglrx bug aside: switching from Xorg to console (either 80x25 or radeondrmfb) makes a fugly "pop" noise, and if the target is radeomdrmfb, display is garbled. So I'm happy. Conclusive questions however: * Why is it that I am only allowed to have sound in graphics mode? * The radeon.ko module does not have any PCI IDs defined, thus does not get autoloaded like i915.ko. Is this intentional? It also seems to default to modeset=0.
