Hi, I up- (from 2.0.4) and downgraded (from unstable) to 2.0.5 since I hoped I would get a working X. The kernel is the default -xen0 2.6.10. But as soon as I start X I get the screen on the following screenshot: http://www.fs.tum.de/~meyerm/ALT/XonRadeon.jpg I can start f.ex. a Xterm on the console and the mousepointer changes when I move into the upper left corner, but despite of the pointer the screen is always constant. I have an i845 with an ATI Radeon 9200 card inside a notebook. Jacob Gorm Hansen on the list suggested using the binary radeon driver - but this needs to be patched each time it changes and... well, I would really prefer the Xorg radeon driver. So, are there any known issues or suggestions in combination with 2.0.5? Thank you very much! Marcel -- Marcel Meyer | Netzwerk- und Rechnerorganisation | Fachschaft Mathematik/Physik/Informatik | Technische Universität München ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Hi Marcel, On Sun, Mar 13, 2005 at 04:55:34PM +0100, Marcel Meyer wrote:> I up- (from 2.0.4) and downgraded (from unstable) to 2.0.5 since I hoped I > would get a working X. The kernel is the default -xen0 2.6.10. But as soon > as I start X I get the screen on the following screenshot: > > http://www.fs.tum.de/~meyerm/ALT/XonRadeon.jpgHmm, my laptop (82855PM, Radeon Mobility 7500) just reboots if my old X server (XF86 4.3.99) tries to use DRM (kernel module from 2.6.11.x) :-( Regards, -- Kurt Garloff <kurt@garloff.de> [Koeln, DE] Physics:Plasma modeling <garloff@plasimo.phys.tue.nl> [TU Eindhoven, NL] Linux: SUSE Labs (Director) <garloff@suse.de> [Novell Inc]
> On Sun, Mar 13, 2005 at 04:55:34PM +0100, Marcel Meyer wrote: > > I up- (from 2.0.4) and downgraded (from unstable) to 2.0.5 > since I hoped I > > would get a working X. The kernel is the default -xen0 > 2.6.10. But as soon > > as I start X I get the screen on the following screenshot: > > > > http://www.fs.tum.de/~meyerm/ALT/XonRadeon.jpg > > Hmm, my laptop (82855PM, Radeon Mobility 7500) just reboots if my > old X server (XF86 4.3.99) tries to use DRM (kernel module from > 2.6.11.x) :-(OK, we thought this was a danger of building AGP in the default config, but it had been in 2.0-testing for some time and we hadn''t had any reports. Please can you say exactly which modules are being loaded and used. If you can get a serial line on the laptop to capture an oops message that would be really helpful. If you know how to tweak the Xconfig to avoid using AGP/DRM as a temporary measure that would be useful to put in the faq. If you''re having success with particular AGP or DRM modules that would be helpful to hear about too. Thanks, Ian ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Hi Ian, On Sun, Mar 13, 2005 at 06:15:33PM -0000, Ian Pratt wrote:> > Hmm, my laptop (82855PM, Radeon Mobility 7500) just reboots if my > > old X server (XF86 4.3.99) tries to use DRM (kernel module from > > 2.6.11.x) :-( > > OK, we thought this was a danger of building AGP in the default config,Well, the fact that it''s enabled in the SUSE kernel config does not directly depend on your default config ;-)> but it had been in 2.0-testing for some time and we hadn''t had any > reports.I thought it worked before, but that was because intel-agp did not crash the machine; the radeon DRM module was missing ...> Please can you say exactly which modules are being loaded and used.radeonfb intel-agp drm radeon If I disable radeon, everything is fine.> If > you can get a serial line on the laptop to capture an oops message that > would be really helpful.The laptop has no serial port :-( I don''t see an oops; does xen reboot the machine if domain 0 oopses? I could try noreboot to see whether this is the case, I guess?> If you know how to tweak the Xconfig to avoid using AGP/DRM as a > temporary measure that would be useful to put in the faq.mv radeon.ko radeon.ko_ is what I used.> If you''re having success with particular AGP or DRM modules that would > be helpful to hear about too.I will have to test on more machines. It seems to work on most, but I have to check whether DRM is used there. Regards, -- Kurt Garloff <kurt@garloff.de> [Koeln, DE] Physics:Plasma modeling <garloff@plasimo.phys.tue.nl> [TU Eindhoven, NL] Linux: SUSE Labs (Director) <garloff@suse.de> [Novell Inc]
> I thought it worked before, but that was because intel-agp did not > crash the machine; the radeon DRM module was missing ... > > > Please can you say exactly which modules are being loaded and used. > > radeonfb > intel-agp > drm > radeon > > If I disable radeon, everything is fine.I guess we''ll just have to do a code review of radeon and look to see whether there are any duff assumptions...> > If > > you can get a serial line on the laptop to capture an oops > message that > > would be really helpful. > > The laptop has no serial port :-( > I don''t see an oops; does xen reboot the machine if domain 0 oopses?If dom0 exits, Xen will reboot.> I could try noreboot to see whether this is the case, I guess?That should stop the reboot, though as you''re not in a text mode it probably won''t help :-(> > If you know how to tweak the Xconfig to avoid using AGP/DRM as a > > temporary measure that would be useful to put in the faq. > > mv radeon.ko radeon.ko_ > is what I used.That''s the sort of hack that I''d come up with ;-)> > If you''re having success with particular AGP or DRM modules > that would > > be helpful to hear about too. > > I will have to test on more machines. > It seems to work on most, but I have to check whether DRM is used > there.-thanks. Ian ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Hi Ian, On Sun, Mar 13, 2005 at 06:31:08PM -0000, Ian Pratt wrote:> Kurt wrote: > > If I disable radeon, everything is fine. > > I guess we''ll just have to do a code review of radeon and look to see > whether there are any duff assumptions...I did not find any phys_to_virt() or such. What else do I need to look for.> > I could try noreboot to see whether this is the case, I guess? > > That should stop the reboot, though as you''re not in a text mode it > probably won''t help :-(No, but at least the machine does not triple fault or writes the wrong values to the kbd controller. (Yeah, the latter is not likely.)> > mv radeon.ko radeon.ko_ > > is what I used. > > That''s the sort of hack that I''d come up with ;-)And I think it''s better than changing the X config. I use the same FS for booting the machine natively and in Xen mode. Regards, -- Kurt Garloff <kurt@garloff.de> [Koeln, DE] Physics:Plasma modeling <garloff@plasimo.phys.tue.nl> [TU Eindhoven, NL] Linux: SUSE Labs (Director) <garloff@suse.de> [Novell Inc]
> > I guess we''ll just have to do a code review of radeon and > look to see > > whether there are any duff assumptions... > > I did not find any phys_to_virt() or such. > What else do I need to look for.Some of the stuff in drm_vm looks pretty scary at first glance. It would be good to find out what code path its taking so we can concentrate on where to look. Knowing if the remap_pfn_range is called and completes OK would be useful. The code near the comment that says "It''s AGP memory - find the real physical page to map" is worth a closer look too. Ian ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Hi, On Sun, Mar 13, 2005 at 07:38:41PM +0100, Kurt Garloff wrote:> No, but at least the machine does not triple fault or writes the > wrong values to the kbd controller. (Yeah, the latter is not likely.)As expected, the machine does not reboot with noreboot. I tried netconsole, but did not see any oops. (Yes, netconsole worked; I used netcat on the other side and used SysRq to test.)> And I think it''s better than changing the X config. > I use the same FS for booting the machine natively and in Xen mode.And if we fail to fix the drm module, we''ll jsut disable its compilation. Regards, -- Kurt Garloff <kurt@garloff.de> [Koeln, DE] Physics:Plasma modeling <garloff@plasimo.phys.tue.nl> [TU Eindhoven, NL] Linux: SUSE Labs (Director) <garloff@suse.de> [Novell Inc]
> As expected, the machine does not reboot with noreboot. > I tried netconsole, but did not see any oops. > (Yes, netconsole worked; I used netcat on the other side and > used SysRq > to test.)It''s possible that the domain did something so heinous that Xen called domain_crash() on it rather than reflecting a fault to the guest. If only we had a debug build of Xen with a serial line attached to get Xen''s report... One idea might be to disable writeable page tables so that faults get reported synchronously, and hence more likely to avoid the need to call domain_crash. The easiest way of doing this on the unstable tree right now is to enable SMP in the guest config. There''s more chance of getting an oops message. Ian ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Hi Ian, On Sun, Mar 13, 2005 at 07:21:18PM -0000, Ian Pratt wrote:> Some of the stuff in drm_vm looks pretty scary at first glance. It would > be good to find out what code path its taking so we can concentrate on > where to look. > > Knowing if the remap_pfn_range is called and completes OK would be > useful.OK, netconsole proves useful after all. [drm:drm_stub_open] [drm:drm_open_helper] pid = 11664, minor = 0 [drm:drm_setup] [drm:drm_ioctl] pid=11664, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 [drm:drm_ioctl] pid=11664, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 [drm:drm_release] open_count = 1 [drm:drm_release] pid = 11664, device = 0xe200, open_count = 1 [drm:drm_fasync] fd = -1, device = 0xe200 [drm:drm_takedown] [drm:radeon_do_cleanup_cp] [drm:drm_stub_open] [drm:drm_open_helper] pid = 11664, minor = 0 [drm:drm_setup] [drm:drm_ioctl] pid=11664, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 [drm:drm_ioctl] pid=11664, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 [drm:drm_release] open_count = 1 [drm:drm_release] pid = 11664, device = 0xe200, open_count = 1 [drm:drm_fasync] fd = -1, device = 0xe200 [drm:drm_takedown] [drm:radeon_do_cleanup_cp] [drm:drm_stub_open] [drm:drm_open_helper] pid = 11664, minor = 0 [drm:drm_setup] [drm:drm_ioctl] pid=11664, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 [drm:drm_ioctl] pid=11664, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 [drm:drm_ioctl] pid=11664, cmd=0xc0086401, nr=0x01, dev 0xe200, auth=1 [drm:drm_ioctl] pid=11664, cmd=0xc0086401, nr=0x01, dev 0xe200, auth=1 [drm:drm_ioctl] pid=11664, cmd=0x40086410, nr=0x10, dev 0xe200, auth=1 [drm:drm_ioctl] pid=11664, cmd=0xc0186415, nr=0x15, dev 0xe200, auth=1 [drm:drm_addmap] offset = 0x00000000, size = 0x00002000, type = 2 [drm:drm_addmap] 8192 13 dce62000 [drm:drm_mmap] start = 0xb5d0f000, end = 0xb5d11000, offset = 0xdce62000 [drm:drm_vm_open] 0xb5d0f000,0x00002000 [drm:drm_do_vm_shm_nopage] shm_nopage 0xb5d0f000 [drm:drm_do_vm_shm_nopage] shm_nopage 0xb5d10000 [drm:drm_ioctl] pid=11664, cmd=0xc0186415, nr=0x15, dev 0xe200, auth=1 [drm:drm_addmap] offset = 0xe0000000, size = 0x02000000, type = 0 [drm:drm_ioctl] pid=11664, cmd=0xc0086426, nr=0x26, dev 0xe200, auth=1 [drm:drm_ioctl] pid=11664, cmd=0xc0086426, nr=0x26, dev 0xe200, auth=1 [drm:drm_ioctl] pid=11664, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 [drm:drm_ioctl] pid=11664, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 [drm:drm_ioctl] pid=11664, cmd=0x6430, nr=0x30, dev 0xe200, auth=1 [drm:drm_ioctl] pid=11664, cmd=0x80206433, nr=0x33, dev 0xe200, auth=1 [drm:drm_ioctl] pid=11664, cmd=0x80206433, nr=0x33, dev 0xe200, auth=1 [drm:drm_ioctl] pid=11664, cmd=0x80206433, nr=0x33, dev 0xe200, auth=1 [drm:drm_ioctl] pid=11664, cmd=0x40046432, nr=0x32, dev 0xe200, auth=1 [drm:drm_ioctl] pid=11664, cmd=0xc0106434, nr=0x34, dev 0xe200, auth=1 [drm:drm_ioctl] pid=11664, cmd=0x40086436, nr=0x36, dev 0xe200, auth=1 [drm:drm_agp_bind] base = 0xd0000000 entry->bound = 0xd0000000 [drm:drm_ioctl] pid=11664, cmd=0xc0186415, nr=0x15, dev 0xe200, auth=1 [drm:drm_addmap] offset = 0x00000000, size = 0x00101000, type = 3 [drm:drm_mmap] start = 0xb5c0e000, end = 0xb5d0f000, offset = 0xd0000000 [drm:drm_mmap] _DRM_REGISTERS: remap_pfn_range() And here it reboots. The last message is from this piece of code: drm_vm.c:636 @ drm_mmap() DRM_DEBUG(" _DRM_REGISTERS: remap_pfn_range()\n"); if (remap_pfn_range(DRM_RPR_ARG(vma) vma->vm_start, (VM_OFFSET(vma) + offset) >> PAGE_SHIFT, vma->vm_end - vma->vm_start, vma->vm_page_prot)) #endif return -EAGAIN; DRM_DEBUG(" Type = %d; start = 0x%lx, end = 0x%lx," " offset = 0x%lx\n", map->type, vma->vm_start, vma->vm_end, VM_OFFSET(vma) + offset); The first DRM_DEBUG statement has been added by me.> The code near the comment that says "It''s AGP memory - find the real > physical page to map" is worth a closer look too.It never seems to be reached (I inserted another DRM_DEBUG before the virt_to_page). Though it looks suspicious. Regards, -- Kurt Garloff <kurt@garloff.de> [Koeln, DE] Physics:Plasma modeling <garloff@plasimo.phys.tue.nl> [TU Eindhoven, NL] Linux: SUSE Labs (Director) <garloff@suse.de> [Novell Inc]
Hi Ian, On Sun, Mar 13, 2005 at 09:07:29PM -0000, Ian Pratt wrote:> If only we had a debug build of Xen with a serial line attached to get > Xen''s report...The xen packages are built with debugger support. But this laptop does not have serial connector.> One idea might be to disable writeable page tables so that faults get > reported synchronously, and hence more likely to avoid the need to call > domain_crash. The easiest way of doing this on the unstable tree right > now is to enable SMP in the guest config. There''s more chance of getting > an oops message.Maybe the drm trace points to something suspicious. Regards, -- Kurt Garloff <kurt@garloff.de> [Koeln, DE] Physics:Plasma modeling <garloff@plasimo.phys.tue.nl> [TU Eindhoven, NL] Linux: SUSE Labs (Director) <garloff@suse.de> [Novell Inc]
> The last message is from this piece of code: > drm_vm.c:636 @ drm_mmap() > > DRM_DEBUG(" _DRM_REGISTERS: remap_pfn_range()\n"); > if (remap_pfn_range(DRM_RPR_ARG(vma) vma->vm_start, > (VM_OFFSET(vma) + > offset) >> PAGE_SHIFT, > vma->vm_end - vma->vm_start, > vma->vm_page_prot))Remap_pfn_range will only work on RAM pages that have been marked PageReserved. It would be interesting to know what''s going on within remap_pte_range. If you use CONFIG_SMP on unstable.bk the errors should be synchronous. Ian ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Sun, Mar 13, 2005 at 10:29:32PM +0100, Kurt Garloff wrote:> [drm:drm_mmap] _DRM_REGISTERS: remap_pfn_range() > > And here it reboots.And I''m sure it does not return from the remap_pfn_range now: [drm:drm_ioctl] pid=11962, cmd=0x40086436, nr=0x36, dev 0xe200, auth=1 [drm:drm_agp_bind] base = 0xd0000000 entry->bound = 0xd0000000 [drm:drm_ioctl] pid=11962, cmd=0xc0186415, nr=0x15, dev 0xe200, auth=1 [drm:drm_addmap] offset = 0x00000000, size = 0x00101000, type = 3 [drm:drm_mmap] start = 0xb5c0e000, end = 0xb5d0f000, offset = 0xd0000000 [drm:drm_mmap] _DRM_REGISTERS: call remap_pfn_range(d4b8285c, 0xb5c0e000, 851968, 1052672, 39) translating: 0xd0000, 0x00101000, _PAGE_PRESENT | _RW | _USER | _ACCESSED DRM_DEBUG(" _DRM_REGISTERS: call remap_pfn_range(%p, 0x%lx, %li, %li, %li)\n", DRM_RPR_ARG(vma) vma->vm_start, (VM_OFFSET(vma) + offset) >> PAGE_SHIFT, vma->vm_end - vma->vm_start, vma->vm_page_prot); if (remap_pfn_range(DRM_RPR_ARG(vma) vma->vm_start, (VM_OFFSET(vma) + offset) >> PAGE_SHIFT, vma->vm_end - vma->vm_start, vma->vm_page_prot)) { #endif DRM_DEBUG(" ... = error\n"); return -EAGAIN; } DRM_DEBUG(" Type = %d; start = 0x%lx, end = 0x%lx," " offset = 0x%lx\n", map->type, vma->vm_start, vma->vm_end, VM_OFFSET(vma) + offset); It doe not give me any clue yet ... -- Kurt Garloff <kurt@garloff.de> [Koeln, DE] Physics:Plasma modeling <garloff@plasimo.phys.tue.nl> [TU Eindhoven, NL] Linux: SUSE Labs (Director) <garloff@suse.de> [Novell Inc]
Hi Ian, On Sun, Mar 13, 2005 at 09:07:29PM -0000, Ian Pratt wrote:> One idea might be to disable writeable page tables so that faults get > reported synchronously, and hence more likely to avoid the need to call > domain_crash. The easiest way of doing this on the unstable tree right > now is to enable SMP in the guest config. There''s more chance of getting > an oops message.It produced an Oops, indeed. Failed to execute MMU updates. ------------[ cut here ]------------ kernel BUG at <bad filename>:53227! invalid operand: 0000 [#1] PREEMPT SMP Modules linked in: radeon drm netconsole usbserial parport_pc lp parport edd sg st sr_mod nvram snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss radeonfb i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect i2c_core snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc intel_agp agpgart uhci_hcd ehci_hcd evdev pcmcia yenta_socket rsrc_nonstatic pcmcia_core usbcore ipt_MASQUERADE ipt_tos ipt_MARK ipt_length sch_htb ipt_TCPMSS ipt_TOS ipt_state ipt_LOG ipt_REJECT iptable_mangle iptable_filter ip_nat_ftp iptable_nat ip_conntrack_ftp ip_conntrack ip_tables e100 ppp_generic slhc rtc nls_cp437 vfat fat dm_mod serial_core CPU: 0 EIP: 0061:[<c0116daa>] Not tainted VLI EFLAGS: 00010286 (2.6.11-xen0) EIP is at xen_l1_entry_update+0xea/0xf0 eax: 00000022 ebx: c1387560 ecx: fbffc000 edx: d1c11e74 esi: 00ef3f60 edi: 00ef3f60 ebp: 00ef3f60 esp: d1c11e70 ds: 007b es: 007b ss: 0069 Process X (pid: 19601, threadinfo=d1c10000 task=d0ba5580) Stack: c03b16dc 00000000 00ba1027 000d0008 00016000 d9895058 0010f000 c0149e77 b5d0efff 0010f000 b5c00000 000cfff2 0000e000 d1ee3b5c 0010f000 b5c00000 000cfff2 0000e000 d1ee3b5c d221fd40 000002d7 d221fd00 b5d0f000 b5d0f000 Call Trace: [<c0149e77>] remap_pfn_range+0x237/0x310 [<dceb222a>] drm_mmap+0x20a/0x274 [drm] [<c014d51c>] get_unmapped_area+0x9c/0xd0 [<c014ce4f>] do_mmap_pgoff+0x36f/0x770 [<dceaa400>] drm_addmap+0x0/0x480 [drm] [<dceadf05>] drm_ioctl+0x115/0x206 [drm] [<c01124ae>] old_mmap+0xce/0x110 [<c01099df>] syscall_call+0x7/0xb Code: 24 04 b8 a8 90 3f c0 8b 5c 24 0c 8b 74 24 10 8b 7c 24 14 8b 6c 24 18 83 c4 1c e9 02 bf 27 00 c7 04 24 dc 16 3b c0 e8 66 81 00 00 <0f> 0b eb cf 89 f6 83 ec 1c 89 5c 24 0c bb 08 36 49 c0 89 74 24 <6>note: X[19601] exited with preempt_count 2 scheduling while atomic: X/0x00000002/19601 [<c03913c5>] schedule+0x915/0xb60 [<c010fe60>] do_IRQ+0x40/0x70 [<c0105d8e>] evtchn_do_upcall+0x5e/0xb0 [<c0109c09>] hypervisor_callback+0x31/0x3c [<c0392369>] rwsem_down_read_failed+0x99/0x190 [<c0122950>] .text.lock.exit+0x27/0x87 [<c01213b6>] do_exit+0x96/0x330 [<c010a465>] die+0x185/0x190 [<c010a535>] do_trap+0xc5/0xf0 [<c010a780>] do_invalid_op+0x0/0xa0 [<c010a813>] do_invalid_op+0x93/0xa0 [<c0116daa>] xen_l1_entry_update+0xea/0xf0 [<c013393b>] autoremove_wake_function+0x1b/0x50 [<c011a727>] __wake_up_common+0x37/0x70 [<c011a798>] __wake_up+0x38/0x50 [<c0109bd3>] error_code+0x4b/0x50 [<c0116daa>] xen_l1_entry_update+0xea/0xf0 [<c0149e77>] remap_pfn_range+0x237/0x310 [<dceb222a>] drm_mmap+0x20a/0x274 [drm] [<c014d51c>] get_unmapped_area+0x9c/0xd0 [<c014ce4f>] do_mmap_pgoff+0x36f/0x770 [<dceaa400>] drm_addmap+0x0/0x480 [drm] [<dceadf05>] drm_ioctl+0x115/0x206 [drm] [<c01124ae>] old_mmap+0xce/0x110 [<c01099df>] syscall_call+0x7/0xb Note that the radeonfb driver manages to mess up the display already, which does not happen on xen-2.0-testing, where radeonfb works. Regards, -- Kurt Garloff <kurt@garloff.de> [Koeln, DE] Physics:Plasma modeling <garloff@plasimo.phys.tue.nl> [TU Eindhoven, NL] Linux: SUSE Labs (Director) <garloff@suse.de> [Novell Inc]
On 13 Mar 2005, at 22:17, Ian Pratt wrote:> Remap_pfn_range will only work on RAM pages that have been marked > PageReserved. > It would be interesting to know what''s going on within remap_pte_range.This is not true -- remap_pfn_range can also be used to map ''invalid pages''. That is, those that are entirely outside the normal RAM map. The problem is that remap_pfn_range is expecting a pseudo-phys address range, but most drivers pass a real-phys address range. The fix is non-obvious: some callers *do* pass in pseudo-phys address ranges (see, for example, packet_mmap in af_packet.c). I think the correct fix is to extend the Linux interface with something like a io_remap_pfn_range, or an extra ''is_ram'' flag to remap_pfn_range. We then already have (almost) an implementation -- we just recycle io_remap_page_range. There are a lot of callers of remap_pfn_range, each would need auditing, and we''d have to try to get the patch checked in even though it only makes sense when running on Xen. -- Keir ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Hi Keir, On Mon, Mar 14, 2005 at 09:34:02AM +0000, Keir Fraser wrote:> I think the correct fix is to extend the Linux interface with something > like a io_remap_pfn_range, or an extra ''is_ram'' flag to > remap_pfn_range. We then already have (almost) an implementation -- we > just recycle io_remap_page_range. There are a lot of callers of > remap_pfn_range, each would need auditing, and we''d have to try to get > the patch checked in even though it only makes sense when running on > Xen.Shouldn''t we just use the __sparc__ code path in drm_vm.c:678, then ? Testing ... Regards, -- Kurt Garloff <kurt@garloff.de> [Koeln, DE] Physics:Plasma modeling <garloff@plasimo.phys.tue.nl> [TU Eindhoven, NL] Linux: SUSE Labs (Director) <garloff@suse.de> [Novell Inc]
On 14 Mar 2005, at 12:26, Kurt Garloff wrote:>> I think the correct fix is to extend the Linux interface with >> something >> like a io_remap_pfn_range, or an extra ''is_ram'' flag to >> remap_pfn_range. We then already have (almost) an implementation -- we >> just recycle io_remap_page_range. There are a lot of callers of >> remap_pfn_range, each would need auditing, and we''d have to try to get >> the patch checked in even though it only makes sense when running on >> Xen. > > Shouldn''t we just use the __sparc__ code path in drm_vm.c:678, then ?Well that would work short-term, but it doesn''t generalise to all the other drivers now using remap_pfn_range. Surely the maintainers would appreciate an io_remap_ call that just does the right thing on all architectures? Sounds suitable as a short-term vendor/distro patch or proof-of-concept. But we should think about cooking up our own, cleaner, patch to push upstream. In fact there are a bunch of generic-code patches in our sparse tree that I think we should actually have as patches we apply to our pristine tree at build time. Then we can have the aim of actively pushing each of those single-purpose patches upstream and always strive to get the patches subdir emptied. Comments? -- Keir ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Hi Keir, On Mon, Mar 14, 2005 at 12:56:10PM +0000, Keir Fraser wrote:> On 14 Mar 2005, at 12:26, Kurt Garloff wrote: > >Shouldn''t we just use the __sparc__ code path in drm_vm.c:678, then ? > > Well that would work short-term,Indeed, it does. See patch attached.> but it doesn''t generalise to all the > other drivers now using remap_pfn_range. Surely the maintainers would > appreciate an io_remap_ call that just does the right thing on all > architectures?I''m sure they would appreciate this.> Sounds suitable as a short-term vendor/distro patch or > proof-of-concept. But we should think about cooking up our own, > cleaner, patch to push upstream.Agreed.> In fact there are a bunch of generic-code patches in our sparse tree > that I think we should actually have as patches we apply to our > pristine tree at build time. Then we can have the aim of actively > pushing each of those single-purpose patches upstream and always strive > to get the patches subdir emptied.Yes, that''s a very good plan. Regards, -- Kurt Garloff <kurt@garloff.de> [Koeln, DE] Physics:Plasma modeling <garloff@plasimo.phys.tue.nl> [TU Eindhoven, NL] Linux: SUSE Labs (Director) <garloff@suse.de> [Novell Inc]
On 14 Mar 2005, at 15:01, Kurt Garloff wrote:>>> Shouldn''t we just use the __sparc__ code path in drm_vm.c:678, then ? >> >> Well that would work short-term, > > Indeed, it does. > See patch attached.There''s now a patch automatically applied during build in 2.0-testing and unstable. patches/linux-2.6.11/iomap.patch Probably this could be sent upstream to the kernel maintainers. -- Keir ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel