Bug#602418: Bug#604096: Bug#601341: Bug#602418: #601341, #602418 and #604096 seem to be duplicates
(dropping all but one of the bugs from the cc, since they are now merged) On Wed, 2010-12-22 at 15:11 -0800, Jeremy Fitzhardinge wrote: On 12/22/2010 10:35 AM, Konrad Rzeszutek Wilk wrote: d541daf6b956 pvops: make pte_flags() go via pvops I've only hit that on a machine with a P4 Prescott with AGP. On nothing else - so it might not be required... If you don't have it you just get a bunch of WARN. It is technically necessary, but in practice it will only matter if things modify ptes with PAT bits set in them. I'm in two minds about it; we really need to benchmark the effect to see how much it matters. Thanks. I think I'll leave it out of the first version I commit to the Debian kernel, I can always re-add it later if it turns out to be necessary. Ian. -- Ian Campbell Marvelous! The super-user's going to boot me! What a finely tuned response to the situation! signature.asc Description: This is a digitally signed message part
Bug#601341: Bug#604096: Bug#601341: Bug#602418: #601341, #602418 and #604096 seem to be duplicates
On Tue, 2010-12-21 at 15:02 -0500, Konrad Rzeszutek Wilk wrote: [...] So e1687eae is upstream, yes, it's c07fbfd17e61 upstream. I switched to that since I prefer upstream versions where possible. [...] Hmm, did you also include: ttm: When TTM_PAGE_FLAG_DMA32 allocate pages under and in your tree, ah yes - you pulled the devel/ttm.pci-api-v2 which has an updated variant of that. dbbc947 and 95518271 seem to have a lot in common. Yup. The architecture of the ttm code changed from 2.6.34-2.6.37. Thanks. S since the Debian kernel has has DRM/TTM from 2.6.33 I assume I want the NEEDS_IOREMAP (95518271) version. I'm about to try my backport of devel/ttm.pci-api-v2 which contains: drm/ttm: Add ttm_tt_free_page ttm: Introduce a placeholder for DMA (bus) addresses. ttm: Utilize the dma_addr_t array for pages that are to in DMA32 pool. ttm: Expand (*populate) to support an array of DMA addresses. radeon/ttm/PCIe: Use dma_addr if TTM has set it. nouveau/ttm/PCIe: Use dma_addr if TTM has set it. radeon/PCIe: Use the correct index field. plus: 9551827190db ttm: Set VM_IO only on pages with TTM_MEMTYPE_FLAG_NEEDS_IOREMAP set. c54d5aa10b7a ttm: Change VMA flags if they != to the TTM flags. c07fbfd17e61 fbmem: VM_IO set, but not propagated d541daf6b956 pvops: make pte_flags() go via pvops In addition the Debian kernel already contains 25021c9 x86: define arch_vm_get_page_prot to set _PAGE_IOMAP on VM_IO vmas 2eb6682 drm: recompute vma-vm_page_prot after changing vm_flags pvops: make pte_flags() go via pvops was the only bit of the patches which were omitted from the Debian kernel (the revert of bcf16b6b4f34) which didn't already appear to have been replaced by the other patches (ignoring all the AGP stuff) so I figured I may as well give it a go. My previous attempt (with all of the above except but make pte_flags() go via pvops) failed because I botched the backport of radeon/PCIe: Use the correct index field. and only fixed one of the wrong indexes. FWIW I think that patch should be folded down into the original patch for upstreaming. Ian. -- Ian Campbell Current Noise: Raise Hell - To The Gallows Bo Derek ruined my life! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601341: Bug#604096: Bug#601341: Bug#602418: #601341, #602418 and #604096 seem to be duplicates
Thanks. S since the Debian kernel has has DRM/TTM from 2.6.33 I assume I want the NEEDS_IOREMAP (95518271) version. I'm about to try my backport of devel/ttm.pci-api-v2 which contains: drm/ttm: Add ttm_tt_free_page ttm: Introduce a placeholder for DMA (bus) addresses. ttm: Utilize the dma_addr_t array for pages that are to in DMA32 pool. ttm: Expand (*populate) to support an array of DMA addresses. radeon/ttm/PCIe: Use dma_addr if TTM has set it. nouveau/ttm/PCIe: Use dma_addr if TTM has set it. radeon/PCIe: Use the correct index field. plus: 9551827190db ttm: Set VM_IO only on pages with TTM_MEMTYPE_FLAG_NEEDS_IOREMAP set. c54d5aa10b7a ttm: Change VMA flags if they != to the TTM flags. c07fbfd17e61 fbmem: VM_IO set, but not propagated Looks good. d541daf6b956 pvops: make pte_flags() go via pvops I've only hit that on a machine with a P4 Prescott with AGP. On nothing else - so it might not be required... If you don't have it you just get a bunch of WARN. In addition the Debian kernel already contains 25021c9 x86: define arch_vm_get_page_prot to set _PAGE_IOMAP on VM_IO vmas 2eb6682 drm: recompute vma-vm_page_prot after changing vm_flags pvops: make pte_flags() go via pvops was the only bit of the patches which were omitted from the Debian kernel (the revert of bcf16b6b4f34) which didn't already appear to have been replaced by the other patches (ignoring all the AGP stuff) so I figured I may as well give it a go. My previous attempt (with all of the above except but make pte_flags() go via pvops) failed because I botched the backport of radeon/PCIe: Use the correct index field. and only fixed one of the wrong indexes. FWIW I think that patch should be folded down into the original patch for upstreaming. Yeah, good idea. And also actually put my SOB on them. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604096: Bug#601341: Bug#602418: #601341, #602418 and #604096 seem to be duplicates
On 12/22/2010 10:35 AM, Konrad Rzeszutek Wilk wrote: Thanks. S since the Debian kernel has has DRM/TTM from 2.6.33 I assume I want the NEEDS_IOREMAP (95518271) version. I'm about to try my backport of devel/ttm.pci-api-v2 which contains: drm/ttm: Add ttm_tt_free_page ttm: Introduce a placeholder for DMA (bus) addresses. ttm: Utilize the dma_addr_t array for pages that are to in DMA32 pool. ttm: Expand (*populate) to support an array of DMA addresses. radeon/ttm/PCIe: Use dma_addr if TTM has set it. nouveau/ttm/PCIe: Use dma_addr if TTM has set it. radeon/PCIe: Use the correct index field. plus: 9551827190db ttm: Set VM_IO only on pages with TTM_MEMTYPE_FLAG_NEEDS_IOREMAP set. c54d5aa10b7a ttm: Change VMA flags if they != to the TTM flags. c07fbfd17e61 fbmem: VM_IO set, but not propagated Looks good. d541daf6b956 pvops: make pte_flags() go via pvops I've only hit that on a machine with a P4 Prescott with AGP. On nothing else - so it might not be required... If you don't have it you just get a bunch of WARN. It is technically necessary, but in practice it will only matter if things modify ptes with PAT bits set in them. I'm in two minds about it; we really need to benchmark the effect to see how much it matters. J -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601341: Bug#604096: Bug#601341: Bug#602418: #601341, #602418 and #604096 seem to be duplicates
On Mon, 2010-12-20 at 11:42 -0500, Konrad Rzeszutek Wilk wrote: Then I got to eba164ec7e69 radeon/nouveau/ttm/AGP: Use dma_addr if TTM has set it. which complained: CC [M] drivers/gpu/drm/ttm/ttm_agp_backend.o drivers/gpu/drm/ttm/ttm_agp_backend.c: In function ‘ttm_agp_populate’: drivers/gpu/drm/ttm/ttm_agp_backend.c:66: error: ‘struct agp_memory’ has no member named ‘dma_addr’ and indeed the field is missing both in 2.6.32+drm33 and Linus' tree. Do I need to cherry pick something from another series or is this commit You can drop that patch. I've rebased the tree to: devel/ttm.pci-api-v2 which is exactly like the older except missing that patch. Thanks I saw the branch but didn't manage to actually spot the difference. I'll publish my backport in a git tree once I'm happy with it, I need to tidy it up and correct the cherry-picked from comments etc and then actually build something which uses it. I'll make Debian packages available for wider testing once I've done that (with Xmas coming up I don't know when that will actually be). FWIW I ran a patched kernel up on my home machine (radeon) and it didn't work. Without KMS the X server failed reasonably gracefuly (with some, presumably spurious, message about the keyboard driver) and with KMS it switched graphics mode and then hung on a black screen. I'll keep poking but I'm hampered a bit by my only suitable test machine actually being my home workstation. I suppose I should poke through 2.6.33..2.6.37-rc and see if anything jumps out for backporting. Did the series make any waves upstream? What are the chances that it will go upstream in something roughly like its current form? I hope so. I am putting the polishing touches on item c) to have it ready for upstream. Cool. Hrm, do I need some equivalent of c) in order to have a chance of this stuff working? Ian. -- Ian Campbell Current Noise: Emperor - Grey You show me an American who can keep his mouth shut and I'll eat him. -- Newspaperman from Frank Capra's _Meet_John_Doe_ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601341: Bug#604096: Bug#601341: Bug#602418: #601341, #602418 and #604096 seem to be duplicates
FWIW I ran a patched kernel up on my home machine (radeon) and it didn't work. Without KMS the X server failed reasonably gracefuly (with some, presumably spurious, message about the keyboard driver) and with KMS it switched graphics mode and then hung on a black screen. I'll keep poking but I'm hampered a bit by my only suitable test machine actually being my home workstation. That was not the machine with the AGP card, right? Did you get these patches in too: 25021c9 x86: define arch_vm_get_page_prot to set _PAGE_IOMAP on VM_IO vmas 2eb6682 drm: recompute vma-vm_page_prot after changing vm_flags dbbc947 ttm: Set VM_IO only on pages with TTM_MEMTYPE_FLAG_FIXED set. I suppose I should poke through 2.6.33..2.6.37-rc and see if anything jumps out for backporting. Did the series make any waves upstream? What are the chances that it will go upstream in something roughly like its current form? I hope so. I am putting the polishing touches on item c) to have it ready for upstream. Cool. Hrm, do I need some equivalent of c) in order to have a chance of this stuff working? Yes, and those three I mentioned earlier should suffice as a temporary solution. Or you can go straight ahead and look at devel/p2m-identity (however, there is a bug in them - ballooning in huge amounts of memory does not work right). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601341: Bug#604096: Bug#601341: Bug#602418: #601341, #602418 and #604096 seem to be duplicates
On Tue, 2010-12-21 at 11:25 -0500, Konrad Rzeszutek Wilk wrote: FWIW I ran a patched kernel up on my home machine (radeon) and it didn't work. Without KMS the X server failed reasonably gracefuly (with some, presumably spurious, message about the keyboard driver) and with KMS it switched graphics mode and then hung on a black screen. I'll keep poking but I'm hampered a bit by my only suitable test machine actually being my home workstation. That was not the machine with the AGP card, right? Correct. I'm not sure I have an AGP card in any running machine (I've got a bunch lying around, I think, but not machines to put them in). Did you get these patches in too: 25021c9 x86: define arch_vm_get_page_prot to set _PAGE_IOMAP on VM_IO vmas 2eb6682 drm: recompute vma-vm_page_prot after changing vm_flags dbbc947 ttm: Set VM_IO only on pages with TTM_MEMTYPE_FLAG_FIXED set. I seem to have 25021c9 and 2eb6682 but not dbbc947. I was experimenting with (from xen.git) 95518271 ttm: Set VM_IO only on pages with TTM_MEMTYPE_FLAG_NEEDS_IOREMAP set. c54d5aa1 ttm: Change VMA flags if they != to the TTM flags. e1687eae fb: propagate VM_IO to VMA. Is this a dead-end? dbbc947 and 95518271 seem to have a lot in common. I suppose I should poke through 2.6.33..2.6.37-rc and see if anything jumps out for backporting. Did the series make any waves upstream? What are the chances that it will go upstream in something roughly like its current form? I hope so. I am putting the polishing touches on item c) to have it ready for upstream. Cool. Hrm, do I need some equivalent of c) in order to have a chance of this stuff working? Yes, and those three I mentioned earlier should suffice as a temporary solution. Thanks, I'll try adding dbbc947. Should I ignore 95518271, c54d5aa1 and e1687eae for the time being? Or you can go straight ahead and look at devel/p2m-identity (however, there is a bug in them - ballooning in huge amounts of memory does not work right). I'd be very wary of taking an infrastructure change of that magnitude into Squeeze in its current frozen state. -- Ian Campbell Current Noise: Pentagram - Life Blood There are no answers, only cross-references. -- Weiner -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601341: Bug#604096: Bug#601341: Bug#602418: #601341, #602418 and #604096 seem to be duplicates
Did you get these patches in too: 25021c9 x86: define arch_vm_get_page_prot to set _PAGE_IOMAP on VM_IO vmas 2eb6682 drm: recompute vma-vm_page_prot after changing vm_flags dbbc947 ttm: Set VM_IO only on pages with TTM_MEMTYPE_FLAG_FIXED set. I seem to have 25021c9 and 2eb6682 but not dbbc947. Good. The first two are essential. I was experimenting with (from xen.git) 95518271 ttm: Set VM_IO only on pages with TTM_MEMTYPE_FLAG_NEEDS_IOREMAP set. c54d5aa1 ttm: Change VMA flags if they != to the TTM flags. e1687eae fb: propagate VM_IO to VMA. Is this a dead-end? So e1687eae is upstream, the other two become obsolete once devel/p2m-identity is flushed out. Hmm, did you also include: ttm: When TTM_PAGE_FLAG_DMA32 allocate pages under and in your tree, ah yes - you pulled the devel/ttm.pci-api-v2 which has an updated variant of that. dbbc947 and 95518271 seem to have a lot in common. Yup. The architecture of the ttm code changed from 2.6.34-2.6.37. .. snip.. Thanks, I'll try adding dbbc947. Should I ignore 95518271, c54d5aa1 and e1687eae for the time being? No, please do try those. So: ttm: Set VM_IO only on pages with TTM_MEMTYPE_FLAG_NEEDS_IOREMAP set without this, you would get these weird errors: (XEN) mm.c:1747:d0 Bad L1 flags c0 (XEN) mm.c:779:d0 Bad L1 flags c0 (XEN) mm.c:4659:d0 ptwr_emulate: could not get_page_from_l1e() [ 123.222339] BUG: unable to handle kernel paging request at 8800747382f8 [ 123.222339] IP: [8100e73a] xen_set_pte+0x31/0x36 [ 123.222339] PGD 1002067 PUD 2e4067 PMD 488067 PTE 1074738065 .. [ 123.385710] [8100e7e6] xen_set_pte_at+0xa7/0xb2 [ 123.385710] [8100c59d] ? __raw_callee_save_xen_make_pte+0x11/0x1e [ 123.385710] [810cd303] vm_insert_mixed+0x86/0xb0 [ 123.385710] [a003d68a] ttm_bo_vm_fault+0x201/0x26c [ttm] Or you can go straight ahead and look at devel/p2m-identity (however, there is a bug in them - ballooning in huge amounts of memory does not work right). I'd be very wary of taking an infrastructure change of that magnitude into Squeeze in its current frozen state. Good point. Don't take them. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601341: Bug#602418: #601341, #602418 and #604096 seem to be duplicates
Hi Konrad, On Tue, 2010-12-07 at 11:47 -0500, Konrad Rzeszutek Wilk wrote: On Tue, Dec 07, 2010 at 11:49:14AM +, Ian Campbell wrote: Is the series at https://lkml.org/lkml/2010/12/6/516 sufficient in its own right to make Nouveau and ATI work or is more needed? What about NV? Both Nouveau and ATI (PCIe) look to work. I did light testing (ATI ES1000, Radeon 3450, Nvidia 65.. something) and will need to do some more aggressive ones. Oh, and Intel GTT seems to work without any of these patches - but I've only tested it on a machine with 4GB so I need to add more memory to make sure. I decided to try backporting this series to the 2.6.32 + DRM form 2.6.33 tree which is used in Squeeze (maintained in git://git.kernel.org/pub/scm/linux/kernel/git/smb/linux-2.6.32.y-drm33.z.git). This was reasonably non-trivial for the first few commits in the series because 1403b1a38e8b drm/ttm: add pool wc/uc page allocator V3 is not present in this tree but I think I managed to do the right thing (I might run the patch by you once I've run it up on my machine, if that's ok with you) Then I got to eba164ec7e69 radeon/nouveau/ttm/AGP: Use dma_addr if TTM has set it. which complained: CC [M] drivers/gpu/drm/ttm/ttm_agp_backend.o drivers/gpu/drm/ttm/ttm_agp_backend.c: In function ‘ttm_agp_populate’: drivers/gpu/drm/ttm/ttm_agp_backend.c:66: error: ‘struct agp_memory’ has no member named ‘dma_addr’ and indeed the field is missing both in 2.6.32+drm33 and Linus' tree. Do I need to cherry pick something from another series or is this commit something which should be ignored per our previous discussion about PCIe vs AGP etc? (I'm going with the second option for now) I'll publish my backport in a git tree once I'm happy with it, I need to tidy it up and correct the cherry-picked from comments etc and then actually build something which uses it. I'll make Debian packages available for wider testing once I've done that (with Xmas coming up I don't know when that will actually be). Did the series make any waves upstream? What are the chances that it will go upstream in something roughly like its current form? Thanks, Ian. -- Ian Campbell Current Noise: Angelcorpse - Reap The Whirlwind Collaboration, n.: A literary partnership based on the false assumption that the other fellow can spell. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601341: Bug#602418: #601341, #602418 and #604096 seem to be duplicates
Then I got to eba164ec7e69 radeon/nouveau/ttm/AGP: Use dma_addr if TTM has set it. which complained: CC [M] drivers/gpu/drm/ttm/ttm_agp_backend.o drivers/gpu/drm/ttm/ttm_agp_backend.c: In function ‘ttm_agp_populate’: drivers/gpu/drm/ttm/ttm_agp_backend.c:66: error: ‘struct agp_memory’ has no member named ‘dma_addr’ and indeed the field is missing both in 2.6.32+drm33 and Linus' tree. Do I need to cherry pick something from another series or is this commit You can drop that patch. I've rebased the tree to: devel/ttm.pci-api-v2 which is exactly like the older except missing that patch. something which should be ignored per our previous discussion about PCIe vs AGP etc? (I'm going with the second option for now) Yup. I'll publish my backport in a git tree once I'm happy with it, I need to tidy it up and correct the cherry-picked from comments etc and then actually build something which uses it. I'll make Debian packages available for wider testing once I've done that (with Xmas coming up I don't know when that will actually be). Did the series make any waves upstream? What are the chances that it will go upstream in something roughly like its current form? I hope so. I am putting the polishing touches on item c) to have it ready for upstream. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601341: Bug#602418: #601341, #602418 and #604096 seem to be duplicates
On Mon, 2010-12-06 at 19:27 -0500, Konrad Rzeszutek Wilk wrote: a) Fix the GART/AGP backend (so drivers/char/agp/*.c) so they use the PCI API. Only the i915 and higher are using the PCI API and I've some of the older boxes with i860 so can actually test it. I've posted patches to address this (https://lkml.org/lkml/2010/12/6/480) and Dave question is why anyone cares about AGP in 2010. I was wondering if any folks could comment? His general principle of fixing the modern stuff first and then working backwards until nobody is complaining any more seems pretty sane to me. Is the series at https://lkml.org/lkml/2010/12/6/516 sufficient in its own right to make Nouveau and ATI work or is more needed? What about NV? More generally if we were to take the series from https://lkml.org/lkml/2010/12/6/516 but not the series from https://lkml.org/lkml/2010/12/6/480 which sets of cards would we be including/excluding support for? Ian. -- Ian Campbell Current Noise: Mistress - 38 What's done to children, they will do to society. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601341: Bug#602418: #601341, #602418 and #604096 seem to be duplicates
On Tue, Dec 07, 2010 at 11:49:14AM +, Ian Campbell wrote: On Mon, 2010-12-06 at 19:27 -0500, Konrad Rzeszutek Wilk wrote: a) Fix the GART/AGP backend (so drivers/char/agp/*.c) so they use the PCI API. Only the i915 and higher are using the PCI API and I've some of the older boxes with i860 so can actually test it. I've posted patches to address this (https://lkml.org/lkml/2010/12/6/480) and Dave question is why anyone cares about AGP in 2010. I was wondering if any folks could comment? His general principle of fixing the modern stuff first and then working backwards until nobody is complaining any more seems pretty sane to me. nods Is the series at https://lkml.org/lkml/2010/12/6/516 sufficient in its own right to make Nouveau and ATI work or is more needed? What about NV? Both Nouveau and ATI (PCIe) look to work. I did light testing (ATI ES1000, Radeon 3450, Nvidia 65.. something) and will need to do some more aggressive ones. Oh, and Intel GTT seems to work without any of these patches - but I've only tested it on a machine with 4GB so I need to add more memory to make sure. More generally if we were to take the series from https://lkml.org/lkml/2010/12/6/516 but not the series from https://lkml.org/lkml/2010/12/6/480 which sets of cards would we be including/excluding support for? PCIe = supported PCI = not supported AGP = not supported. Ian. -- Ian Campbell Current Noise: Mistress - 38 What's done to children, they will do to society. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604096: Bug#601341: Bug#602418: #601341, #602418 and #604096 seem to be duplicates
On Tue, 2010-12-07 at 11:47 -0500, Konrad Rzeszutek Wilk wrote: On Tue, Dec 07, 2010 at 11:49:14AM +, Ian Campbell wrote: On Mon, 2010-12-06 at 19:27 -0500, Konrad Rzeszutek Wilk wrote: a) Fix the GART/AGP backend (so drivers/char/agp/*.c) so they use the PCI API. Only the i915 and higher are using the PCI API and I've some of the older boxes with i860 so can actually test it. I've posted patches to address this (https://lkml.org/lkml/2010/12/6/480) and Dave question is why anyone cares about AGP in 2010. I was wondering if any folks could comment? His general principle of fixing the modern stuff first and then working backwards until nobody is complaining any more seems pretty sane to me. nods Is the series at https://lkml.org/lkml/2010/12/6/516 sufficient in its own right to make Nouveau and ATI work or is more needed? What about NV? Both Nouveau and ATI (PCIe) look to work. I did light testing (ATI ES1000, Radeon 3450, Nvidia 65.. something) and will need to do some more aggressive ones. Oh, and Intel GTT seems to work without any of these patches - but I've only tested it on a machine with 4GB so I need to add more memory to make sure. FWIW Bastian reported (either in one of these bug reports or on the mailing list) that Intel worked for him too. More generally if we were to take the series from https://lkml.org/lkml/2010/12/6/516 but not the series from https://lkml.org/lkml/2010/12/6/480 which sets of cards would we be including/excluding support for? PCIe = supported PCI = not supported AGP = not supported. Thanks. Having PCIe support would be a pretty good start IMHO. Dave's concerns seemed mainly to be about AGP bits rather than PCI, are they independent(-ish)? e.g. is only a subset of the .../480 series is needed to enable PCI support? Ian. -- Ian Campbell Current Noise: Firebird - Raise A Smile FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #4 A: Go west, young man, go west! Q: What do wabbits do when they get tiwed of wunning awound? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601341: Bug#602418: #601341, #602418 and #604096 seem to be duplicates
Dave's concerns seemed mainly to be about AGP bits rather than PCI, are Yeah, his concerns are valid: why touch it if nobody is using it. And if truly there aren't enough folks being interested in AGP support, then I am fine dropping it. they independent(-ish)? e.g. is only a subset of the .../480 series is The PCI cards I am taking about are the .. PCI Matrox G400 or like, so even older than AGP cards. needed to enable PCI support? You know, I might have not actually posted a patch for this. It was one of those DRM scattergather code. shrugs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601341: Bug#602418: #601341, #602418 and #604096 seem to be duplicates
a) Fix the GART/AGP backend (so drivers/char/agp/*.c) so they use the PCI API. Only the i915 and higher are using the PCI API and I've some of the older boxes with i860 so can actually test it. I've posted patches to address this (https://lkml.org/lkml/2010/12/6/480) and Dave question is why anyone cares about AGP in 2010. I was wondering if any folks could comment? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601341: Bug#602418: #601341, #602418 and #604096 seem to be duplicates
On Mon, 2010-11-29 at 02:52 +, Ben Hutchings wrote: On Sun, 2010-11-28 at 18:12 +, Ian Campbell wrote: On Sun, 2010-11-28 at 16:58 +, Ben Hutchings wrote: On Tue, 2010-11-23 at 12:56 +0100, Lionel Elie Mamane wrote: On Tue, Nov 23, 2010 at 10:41:57AM +0100, Alexander Kurtz wrote: The following bugs seem to be identical: #601341 #602418 #604096 They all seem to be fixed by this kernel: http://xenbits.xen.org/people/ianc/ I think it would be a good idea to *) merge them all *) assign to linux-2.6 *) mark as affecting xserver-xorg *) mark as patched *) possibly mark them as RC That's all fine by me (as reporter of #601341 and #602418). Possibly the patch tag is not adequate as the exact read-to-apply-to-the-Debian-package patch is not there, just one of the differences between the Debian package and http://xenbits.xen.org/people/ianc/ fixes this. Ian, can you identify which patch we're currently missing? They are the changes attached to Reinstating GPU fixes to Xen flavour on debian-kernel (1290518224.5514.27.ca...@zakaz.uk.xensource.com) last week. [...] IIRC the original discussion regarding the omission of these changes from the last Xen pvops merge starts at 20100817192832.ga22...@wavehammer.waldi.eu.org (on debian-kernel back in August). Thanks for the pointers. I agree with Bastian that some of these changes are really quite nasty. Do you and other Xen developers have any plan for how to fix the GART and TTM mapping problems in a cleaner way as Xen dom0 support goes upstream? I know that there is a plan to get rid of the _PAGE_IOMAP stuff altogether by simply arranging for a 1-1 mapping for the relevant device PFNs in the P2M array. However I'm not sure whether or not this knocks-on into a fix for the GART/TTM stuff. Konrad, do you have an idea how you plan to solve the GART/TTM issues upstream? If there is no such plan then I would rather disable these drivers than make them work temporarily with a hack. Thanks, Ian. -- Ian Campbell You will not be elected to public office this year. signature.asc Description: This is a digitally signed message part
Bug#601341: Bug#602418: #601341, #602418 and #604096 seem to be duplicates
On Tue, 2010-11-23 at 12:56 +0100, Lionel Elie Mamane wrote: On Tue, Nov 23, 2010 at 10:41:57AM +0100, Alexander Kurtz wrote: The following bugs seem to be identical: #601341 #602418 #604096 They all seem to be fixed by this kernel: http://xenbits.xen.org/people/ianc/ I think it would be a good idea to *) merge them all *) assign to linux-2.6 *) mark as affecting xserver-xorg *) mark as patched *) possibly mark them as RC That's all fine by me (as reporter of #601341 and #602418). Possibly the patch tag is not adequate as the exact read-to-apply-to-the-Debian-package patch is not there, just one of the differences between the Debian package and http://xenbits.xen.org/people/ianc/ fixes this. Ian, can you identify which patch we're currently missing? Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#601341: Bug#602418: #601341, #602418 and #604096 seem to be duplicates
On Sun, 2010-11-28 at 16:58 +, Ben Hutchings wrote: On Tue, 2010-11-23 at 12:56 +0100, Lionel Elie Mamane wrote: On Tue, Nov 23, 2010 at 10:41:57AM +0100, Alexander Kurtz wrote: The following bugs seem to be identical: #601341 #602418 #604096 They all seem to be fixed by this kernel: http://xenbits.xen.org/people/ianc/ I think it would be a good idea to *) merge them all *) assign to linux-2.6 *) mark as affecting xserver-xorg *) mark as patched *) possibly mark them as RC That's all fine by me (as reporter of #601341 and #602418). Possibly the patch tag is not adequate as the exact read-to-apply-to-the-Debian-package patch is not there, just one of the differences between the Debian package and http://xenbits.xen.org/people/ianc/ fixes this. Ian, can you identify which patch we're currently missing? They are the changes attached to Reinstating GPU fixes to Xen flavour on debian-kernel (1290518224.5514.27.ca...@zakaz.uk.xensource.com) last week. That patch correspond to several separate commits upstream in xen.git: d541daf6b95641953a1eb1938c640a0178bed726 pvops: make pte_flags() go via pvops e1687eae6f85475ebf8579039badafbbe5602014 fb: propagate VM_IO to VMA. c54d5aa10b7a96d182c6dff5160834a0374f9b31 ttm: Change VMA flags if they != to the TTM flags. c57bd3e45674e26c1eb99b65a8ed9db49651aa4a amd64-agp:Use Xen back-door to get page's physical address for AMD64 chipsets. 1e6dcf8d925ac125c780c693f89134532c6e121a intel-agp: Use Xen back-door to get page's physical address for i8[1,3]0 a2395df466453e0bf7ee223c449a29dd3b0ed7f0 intel-agp: Warn when !USE_PCI_DMA_API and inserting bogus bus addresses. 2b6c99e135cd8467f7a5999ee3e9bb877426a8b0 agp-backend: Use Xen back-door to get bus address for scratch page. 0f03e715260f3b715a0f55cd1efd0100d121c27b agp: If _GFP_DMA_32 flag is set enforce pages to be under 4GB under Xen. 597bbe84922e0966a77d05d62857f3553c7aeffe agp: Program the GART with the real physical address under Xen. 534c050301a7c672e3c035034fa6b9c7752f9066 agp: Use Xen back-door to get bus address for legacy code. 9551827190db2d34f106255f0b5bfdc452e85cd8 ttm: Set VM_IO only on pages with TTM_MEMTYPE_FLAG_NEEDS_IOREMAP set. 0675de9b57cf7afa00ceab93a3ca180c085c3f9a ttm: When TTM_PAGE_FLAG_DMA32 allocate pages under 4GB under Xen. but I think they can be considered as a single set for the purposes of resolving these tickets. IIRC the original discussion regarding the omission of these changes from the last Xen pvops merge starts at 20100817192832.ga22...@wavehammer.waldi.eu.org (on debian-kernel back in August). Ian. -- Ian Campbell I feel like a wet parking meter on Darvon! signature.asc Description: This is a digitally signed message part
Bug#601341: Bug#602418: #601341, #602418 and #604096 seem to be duplicates
On Tue, Nov 23, 2010 at 10:41:57AM +0100, Alexander Kurtz wrote: The following bugs seem to be identical: #601341 #602418 #604096 They all seem to be fixed by this kernel: http://xenbits.xen.org/people/ianc/ I think it would be a good idea to *) merge them all *) assign to linux-2.6 *) mark as affecting xserver-xorg *) mark as patched *) possibly mark them as RC That's all fine by me (as reporter of #601341 and #602418). Possibly the patch tag is not adequate as the exact read-to-apply-to-the-Debian-package patch is not there, just one of the differences between the Debian package and http://xenbits.xen.org/people/ianc/ fixes this. -- Lionel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
