Re: Fix found - Debian

This is a discussion on Re: Fix found - Debian ; Hi Max and Debian Kernel Team Thanks for all the testing, Max! To the kernel team: Is there any chance you could upload a kernel with Max's patch? The relevant parts are already in the upstream kernel. The other part ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: Re: Fix found

  1. Re: Fix found

    Hi Max and Debian Kernel Team

    Thanks for all the testing, Max!

    To the kernel team:
    Is there any chance you could upload a kernel with Max's patch? The relevant
    parts are already in the upstream kernel. The other part is a revert of a commit
    in the upstream kernel which is incompatible with the X server in lenny. See the
    bug log for more details. Is there another upload of linux-2.6 planned before the
    release of lenny or do you plan to release with -9?

    As this affects a major part of all SPARC machines, I really think this is release
    critical and the bug severity should be upgraded again. If you don't disagree strongly
    I will upgrade it in the next days.

    Gaudenz

    On Tue, Nov 04, 2008 at 11:20:09PM +0300, Max Dmitrichenko wrote:
    > Ok!
    >
    > I've rolled back to the lenny's X.org and applied both patches to the
    > kernel. It works!
    >
    > The final patch which incorporates both patches against 2.6.26.6 (i.e.
    > sid's current kernel) is attached.
    >
    > --
    > Max


    > diff -urpN linux-source-2.6.26/arch/sparc64/kernel/pci.c linux-source-2.6.26.pci-fix/arch/sparc64/kernel/pci.c
    > --- linux-source-2.6.26/arch/sparc64/kernel/pci.c 2008-10-18 14:33:11.000000000 +0400
    > +++ linux-source-2.6.26.pci-fix/arch/sparc64/kernel/pci.c 2008-11-04 18:15:31.000000000 +0300
    > @@ -350,7 +350,8 @@ static void pci_parse_of_addrs(struct of
    >
    > struct pci_dev *of_create_pci_dev(struct pci_pbm_info *pbm,
    > struct device_node *node,
    > - struct pci_bus *bus, int devfn)
    > + struct pci_bus *bus, int devfn,
    > + int host_controller)
    > {
    > struct dev_archdata *sd;
    > struct pci_dev *dev;
    > @@ -389,28 +390,43 @@ struct pci_dev *of_create_pci_dev(struct
    > dev->devfn = devfn;
    > dev->multifunction = 0; /* maybe a lie? */
    >
    > - dev->vendor = of_getintprop_default(node, "vendor-id", 0xffff);
    > - dev->device = of_getintprop_default(node, "device-id", 0xffff);
    > - dev->subsystem_vendor =
    > - of_getintprop_default(node, "subsystem-vendor-id", 0);
    > - dev->subsystem_device =
    > - of_getintprop_default(node, "subsystem-id", 0);
    > -
    > - dev->cfg_size = pci_cfg_space_size(dev);
    > -
    > - /* We can't actually use the firmware value, we have
    > - * to read what is in the register right now. One
    > - * reason is that in the case of IDE interfaces the
    > - * firmware can sample the value before the the IDE
    > - * interface is programmed into native mode.
    > - */
    > - pci_read_config_dword(dev, PCI_CLASS_REVISION, &class);
    > - dev->class = class >> 8;
    > - dev->revision = class & 0xff;
    > -
    > - sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(bus),
    > - dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
    > + if (host_controller) {
    > + if (tlb_type != hypervisor) {
    > + pci_read_config_word(dev, PCI_VENDOR_ID,
    > + &dev->vendor);
    > + pci_read_config_word(dev, PCI_DEVICE_ID,
    > + &dev->device);
    > + } else {
    > + dev->vendor = PCI_VENDOR_ID_SUN;
    > + dev->device = 0x80f0;
    > + }
    > + dev->cfg_size = 256;
    > + dev->class = PCI_CLASS_BRIDGE_HOST << 8;
    > + sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(bus),
    > + 0x00, PCI_SLOT(devfn), PCI_FUNC(devfn));
    > + } else {
    > + dev->vendor = of_getintprop_default(node, "vendor-id", 0xffff);
    > + dev->device = of_getintprop_default(node, "device-id", 0xffff);
    > + dev->subsystem_vendor =
    > + of_getintprop_default(node, "subsystem-vendor-id", 0);
    > + dev->subsystem_device =
    > + of_getintprop_default(node, "subsystem-id", 0);
    > +
    > + dev->cfg_size = pci_cfg_space_size(dev);
    > +
    > + /* We can't actually use the firmware value, we have
    > + * to read what is in the register right now. One
    > + * reason is that in the case of IDE interfaces the
    > + * firmware can sample the value before the the IDE
    > + * interface is programmed into native mode.
    > + */
    > + pci_read_config_dword(dev, PCI_CLASS_REVISION, &class);
    > + dev->class = class >> 8;
    > + dev->revision = class & 0xff;
    >
    > + sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(bus),
    > + dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
    > + }
    > if (ofpci_verbose)
    > printk(" class: 0x%x device name: %s\n",
    > dev->class, pci_name(dev));
    > @@ -425,21 +441,26 @@ struct pci_dev *of_create_pci_dev(struct
    > dev->current_state = 4; /* unknown power state */
    > dev->error_state = pci_channel_io_normal;
    >
    > - if (!strcmp(node->name, "pci")) {
    > - /* a PCI-PCI bridge */
    > + if (host_controller) {
    > dev->hdr_type = PCI_HEADER_TYPE_BRIDGE;
    > dev->rom_base_reg = PCI_ROM_ADDRESS1;
    > - } else if (!strcmp(type, "cardbus")) {
    > - dev->hdr_type = PCI_HEADER_TYPE_CARDBUS;
    > + dev->irq = PCI_IRQ_NONE;
    > } else {
    > - dev->hdr_type = PCI_HEADER_TYPE_NORMAL;
    > - dev->rom_base_reg = PCI_ROM_ADDRESS;
    > + if (!strcmp(type, "pci") || !strcmp(type, "pciex")) {
    > + /* a PCI-PCI bridge */
    > + dev->hdr_type = PCI_HEADER_TYPE_BRIDGE;
    > + dev->rom_base_reg = PCI_ROM_ADDRESS1;
    > + } else if (!strcmp(type, "cardbus")) {
    > + dev->hdr_type = PCI_HEADER_TYPE_CARDBUS;
    > + } else {
    > + dev->hdr_type = PCI_HEADER_TYPE_NORMAL;
    > + dev->rom_base_reg = PCI_ROM_ADDRESS;
    >
    > - dev->irq = sd->op->irqs[0];
    > - if (dev->irq == 0xffffffff)
    > - dev->irq = PCI_IRQ_NONE;
    > + dev->irq = sd->op->irqs[0];
    > + if (dev->irq == 0xffffffff)
    > + dev->irq = PCI_IRQ_NONE;
    > + }
    > }
    > -
    > pci_parse_of_addrs(sd->op, node, dev);
    >
    > if (ofpci_verbose)
    > @@ -728,7 +749,7 @@ static void __devinit pci_of_scan_bus(st
    > prev_devfn = devfn;
    >
    > /* create a new pci_dev for this device */
    > - dev = of_create_pci_dev(pbm, child, bus, devfn);
    > + dev = of_create_pci_dev(pbm, child, bus, devfn, 0);
    > if (!dev)
    > continue;
    > if (ofpci_verbose)
    > @@ -775,9 +796,48 @@ static void __devinit pci_bus_register_o
    > pci_bus_register_of_sysfs(child_bus);
    > }
    >
    > +int pci_host_bridge_read_pci_cfg(struct pci_bus *bus_dev,
    > + unsigned int devfn,
    > + int where, int size,
    > + u32 *value)
    > +{
    > + static u8 fake_pci_config[] = {
    > + 0x8e, 0x10, /* Vendor: 0x108e (Sun) */
    > + 0xf0, 0x80, /* Device: 0x80f0 (Fire) */
    > + 0x46, 0x01, /* Command: 0x0146 (SERR, PARITY, MASTER, MEM) */
    > + 0xa0, 0x22, /* Status: 0x02a0 (DEVSEL_MED, FB2B, 66MHZ) */
    > + 0x00, 0x00, 0x00, 0x06, /* Class: 0x06000000 host bridge */
    > + 0x00, /* Cacheline: 0x00 */
    > + 0x40, /* Latency: 0x40 */
    > + 0x00, /* Header-Type: 0x00 normal */
    > + };
    > +
    > + *value = 0;
    > + if (where >= 0 && where < sizeof(fake_pci_config) &&
    > + (where + size) >= 0 &&
    > + (where + size) < sizeof(fake_pci_config) &&
    > + size <= sizeof(u32)) {
    > + while (size--) {
    > + *value <<= 8;
    > + *value |= fake_pci_config[where + size];
    > + }
    > + }
    > +
    > + return PCIBIOS_SUCCESSFUL;
    > +}
    > +
    > +int pci_host_bridge_write_pci_cfg(struct pci_bus *bus_dev,
    > + unsigned int devfn,
    > + int where, int size,
    > + u32 value)
    > +{
    > + return PCIBIOS_SUCCESSFUL;
    > +}
    > +
    > struct pci_bus * __devinit pci_scan_one_pbm(struct pci_pbm_info *pbm)
    > {
    > struct device_node *node = pbm->prom_node;
    > + struct pci_dev *host_pdev;
    > struct pci_bus *bus;
    >
    > printk("PCI: Scanning PBM %s\n", node->full_name);
    > @@ -795,6 +855,10 @@ struct pci_bus * __devinit pci_scan_one_
    > bus->resource[0] = &pbm->io_space;
    > bus->resource[1] = &pbm->mem_space;
    >
    > + /* Create the dummy host bridge and link it in. */
    > + host_pdev = of_create_pci_dev(pbm, node, bus, 0x00, 1);
    > + bus->self = host_pdev;
    > +
    > pci_of_scan_bus(pbm, node, bus);
    > pci_bus_add_devices(bus);
    > pci_bus_register_of_sysfs(bus);
    > @@ -1017,6 +1081,7 @@ static int __pci_mmap_make_offset(struct
    >
    > for (i = 0; i <= PCI_ROM_RESOURCE; i++) {
    > struct resource *rp = &pdev->resource[i];
    > + resource_size_t aligned_end;
    >
    > /* Active? */
    > if (!rp->flags)
    > @@ -1034,8 +1099,15 @@ static int __pci_mmap_make_offset(struct
    > continue;
    > }
    >
    > + /* Align the resource end to the next page address.
    > + * PAGE_SIZE intentionally added instead of (PAGE_SIZE - 1),
    > + * because actually we need the address of the next byte
    > + * after rp->end.
    > + */
    > + aligned_end = (rp->end + PAGE_SIZE) & PAGE_MASK;
    > +
    > if ((rp->start <= user_paddr) &&
    > - (user_paddr + user_size) <= (rp->end + 1UL))
    > + (user_paddr + user_size) <= aligned_end)
    > break;
    > }
    >
    > diff -urpN linux-source-2.6.26/arch/sparc64/kernel/pci_common.c linux-source-2.6.26.pci-fix/arch/sparc64/kernel/pci_common.c
    > --- linux-source-2.6.26/arch/sparc64/kernel/pci_common.c 2008-07-14 01:51:29.000000000 +0400
    > +++ linux-source-2.6.26.pci-fix/arch/sparc64/kernel/pci_common.c 2008-11-04 18:15:27.000000000 +0300
    > @@ -264,6 +264,9 @@ static int sun4v_read_pci_cfg(struct pci
    > unsigned int func = PCI_FUNC(devfn);
    > unsigned long ret;
    >
    > + if (!bus && devfn == 0x00)
    > + return pci_host_bridge_read_pci_cfg(bus_dev, devfn, where,
    > + size, value);
    > if (config_out_of_range(pbm, bus, devfn, where)) {
    > ret = ~0UL;
    > } else {
    > @@ -297,6 +300,9 @@ static int sun4v_write_pci_cfg(struct pc
    > unsigned int func = PCI_FUNC(devfn);
    > unsigned long ret;
    >
    > + if (!bus && devfn == 0x00)
    > + return pci_host_bridge_write_pci_cfg(bus_dev, devfn, where,
    > + size, value);
    > if (config_out_of_range(pbm, bus, devfn, where)) {
    > /* Do nothing. */
    > } else {
    > diff -urpN linux-source-2.6.26/arch/sparc64/kernel/pci_impl.h linux-source-2.6.26.pci-fix/arch/sparc64/kernel/pci_impl.h
    > --- linux-source-2.6.26/arch/sparc64/kernel/pci_impl.h 2008-07-14 01:51:29.000000000 +0400
    > +++ linux-source-2.6.26.pci-fix/arch/sparc64/kernel/pci_impl.h 2008-11-04 18:15:27.000000000 +0300
    > @@ -167,6 +167,15 @@ extern void pci_get_pbm_props(struct pci
    > extern struct pci_bus *pci_scan_one_pbm(struct pci_pbm_info *pbm);
    > extern void pci_determine_mem_io_space(struct pci_pbm_info *pbm);
    >
    > +extern int pci_host_bridge_read_pci_cfg(struct pci_bus *bus_dev,
    > + unsigned int devfn,
    > + int where, int size,
    > + u32 *value);
    > +extern int pci_host_bridge_write_pci_cfg(struct pci_bus *bus_dev,
    > + unsigned int devfn,
    > + int where, int size,
    > + u32 value);
    > +
    > /* Error reporting support. */
    > extern void pci_scan_for_target_abort(struct pci_pbm_info *, struct pci_bus *);
    > extern void pci_scan_for_master_abort(struct pci_pbm_info *, struct pci_bus *);



    --
    Ever tried. Ever failed. No matter.
    Try again. Fail again. Fail better.
    ~ Samuel Beckett ~


    --
    To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  2. Bug#500358: Fix found

    severity 500358 grave
    Thanks

    On Thu, Nov 06, 2008 at 06:24:57PM +0100, Gaudenz Steinlin wrote:
    > As this affects a major part of all SPARC machines, I really think thisis release
    > critical and the bug severity should be upgraded again. If you don't disagree strongly
    > I will upgrade it in the next days.


    OK, since there was no opposition and there is still no explaination on
    why this bug was donwgraded in the first place I'm upgrading it back to the
    initial severity.

    What's the best way forward on this issue? I'm a bit hesitant on just preparing
    an NMU*for the kernel, for obvious reasons. It would much prefer it, ifa member
    of the kernel team would take care of appling the patch.

    Are the changes currently in SVN targeted at lenny or not? If it helps I could prepare
    an NMU patch complete with changelog entry and everything.

    Gaudenz

    --
    Ever tried. Ever failed. No matter.
    Try again. Fail again. Fail better.
    ~ Samuel Beckett ~



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  3. Bug#500358: Fix found

    severity 500358 important
    thanks

    On Sat, Nov 08, 2008 at 11:54:38PM +0100, Gaudenz Steinlin wrote:
    > On Thu, Nov 06, 2008 at 06:24:57PM +0100, Gaudenz Steinlin wrote:
    > > As this affects a major part of all SPARC machines, I really think thisis release
    > > critical and the bug severity should be upgraded again. If you don't disagree strongly
    > > I will upgrade it in the next days.

    > OK, since there was no opposition and there is still no explaination on
    > why this bug was donwgraded in the first place I'm upgrading it back to the
    > initial severity.


    There is only a small fraction of machines affected, so this is not RC.

    > What's the best way forward on this issue? I'm a bit hesitant on just preparing
    > an NMUÂ*for the kernel, for obvious reasons. It would much prefer it,if a member
    > of the kernel team would take care of appling the patch.


    I fail to find anything near this patch in upstream (Linus' tree), which
    would be the first target. So please provide commit IDs along with
    patches. If you want to force us to apply patches which does not follow
    our guidelines, you have to ask CTTE.

    Bastian

    --
    Beam me up, Scotty!

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iEYEARECAAYFAkkWLdsACgkQnw66O/MvCNGQugCeMzN21SD0ibglAGAiqLHsnVPB
    PpcAnAmBlwcw6Ihtn8H9Uk2Js9PeL0RG
    =PEFc
    -----END PGP SIGNATURE-----


  4. Bug#500358: Fix found

    2008/11/9 Bastian Blank :
    >> OK, since there was no opposition and there is still no explaination on
    >> why this bug was donwgraded in the first place I'm upgrading it back to the
    >> initial severity.

    >
    > There is only a small fraction of machines affected, so this is not RC.


    This is not a PC case where one can assemble some unique set of components which
    will not work together well. SPARC is a traditionally brand
    architecture. This case
    affects Ultra 5 and may be several other workstation. So if something
    doesn't function
    on one box it doesn't function on a whole generation of boxes. I think this is
    quite a big part of all Debian SPARC users. And if SPARC is qualified
    for release
    then this is definitely RC.

    And do not hesitate to use common sense. Refusal of fixing the bug
    should be made
    only if you are afraid of breaking something else. This patch targets
    only SPARC. It has
    absolutely no influence on other archs, so it won't break anything
    else even in the worst case.

    > I fail to find anything near this patch in upstream (Linus' tree), which
    > would be the first target. So please provide commit IDs along with
    > patches. If you want to force us to apply patches which does not follow
    > our guidelines, you have to ask CTTE.


    http://git.kernel.org/?p=linux/kerne...f9e4ee5c1e0821

    --
    Max



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  5. Bug#500358: Fix found

    On Sun, Nov 09, 2008 at 09:37:11PM +0300, Max Dmitrichenko wrote:
    > 2008/11/9 Bastian Blank :
    > >> OK, since there was no opposition and there is still no explaination on
    > >> why this bug was donwgraded in the first place I'm upgrading it back to the
    > >> initial severity.

    > >
    > > There is only a small fraction of machines affected, so this is not RC.

    >
    > This is not a PC case where one can assemble some unique set of components which
    > will not work together well.


    Hmm, my Sparc got PCI-X and PCIe. Okay, I never tried to put a random
    card in it, but why should it not work?

    > SPARC is a traditionally brand
    > architecture. This case
    > affects Ultra 5 and may be several other workstation. So if something
    > doesn't function
    > on one box it doesn't function on a whole generation of boxes. I think this is
    > quite a big part of all Debian SPARC users.


    This still does not qualify for the severity "grave":

    | makes the package in question unusable or mostly so,

    It still runs. And the Sparc machines I use don't show such problems.

    > And if SPARC is qualified
    > for release
    > then this is definitely RC.


    It is the decision of the maintainer if nothing else matches.

    > And do not hesitate to use common sense. Refusal of fixing the bug
    > should be made
    > only if you are afraid of breaking something else. This patch targets
    > only SPARC. It has
    > absolutely no influence on other archs, so it won't break anything
    > else even in the worst case.


    NMUing a properly maintained package without action from the CTTE is
    also a no-go.

    > http://git.kernel.org/?p=linux/kerne...f9e4ee5c1e0821


    This is a different patch then
    http://bugs.debian.org/cgi-bin/bugre...t=1;bug=500358

    Bastian

    --
    History tends to exaggerate.
    -- Col. Green, "The Savage Curtain", stardate 5906.4



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  6. Bug#500358: Fix found

    > It is the decision of the maintainer if nothing else matches.
    Ok. Who is the maintainer?

    > NMUing a properly maintained package without action from the CTTE is
    > also a no-go.


    Sorry, I'm not a DD and I'm very bad in your politics and burocracy.

    >> http://git.kernel.org/?p=linux/kerne...f9e4ee5c1e0821

    >
    > This is a different patch then
    > http://bugs.debian.org/cgi-bin/bugre...t=1;bug=500358
    >


    Go on and read the discussion of this bug if you really interested why
    these patches differ. In short, the last patch is the first patch
    merged with Gaudenz's patch which revert changes of SPARC PCI in
    2.6.26 which breaks xserver-xorg-video-ati package.

    --
    Max



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  7. Bug#500358: Fix found

    On Sun, Nov 09, 2008 at 10:30:38PM +0100, Bastian Blank wrote:
    > > SPARC is a traditionally brand
    > > architecture. This case
    > > affects Ultra 5 and may be several other workstation. So if something
    > > doesn't function
    > > on one box it doesn't function on a whole generation of boxes. I think this is
    > > quite a big part of all Debian SPARC users.

    >
    > This still does not qualify for the severity "grave":
    >
    > | makes the package in question unusable or mostly so,
    >
    > It still runs. And the Sparc machines I use don't show such problems.


    Seeing how you're interested in this kind of bureaucratic nitpicking
    I should point out that "grave" is actually too light a severity for this
    bug, and "critical" should be used instead - the kernel upgrade broke the X
    server, so it's a critical bug by definition ("makes unrelated software on
    the system break"). The part that fit the grave severity was "makes the
    package in question mostly unusable", which is what any typical X user would
    say in this situation.

    In any case this is a pointless exercise, let's just make sure the bug is
    fixed and go forward. I hope I'll be verifying the submitted patch on my
    Ultra 5 soon.

    --
    2. That which causes joy or happiness.



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  8. Bug#500358: Fix found

    On Mon, Nov 10, 2008 at 11:46:24AM +0300, Max Dmitrichenko wrote:
    > > It is the decision of the maintainer if nothing else matches.

    > Ok. Who is the maintainer?


    debian-kernel, represented by whom doing the work.

    > Go on and read the discussion of this bug if you really interested why
    > these patches differ.


    You want something from us. Also the bugreport reads itself as two
    different bugs, which does not make it easier to understand.

    > In short, the last patch is the first patch
    > merged with Gaudenz's patch which revert changes of SPARC PCI in
    > 2.6.26 which breaks xserver-xorg-video-ati package.


    The first patch is fine. The revert is not.

    Bastian

    --
    Worlds are conquered, galaxies destroyed -- but a woman is always a woman.
    -- Kirk, "The Conscience of the King", stardate 2818.9



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  9. Bug#500358: Fix found

    2008/11/11, Bastian Blank :
    >> Go on and read the discussion of this bug if you really interested why
    >> these patches differ.

    >
    > You want something from us. Also the bugreport reads itself as two
    > different bugs, which does not make it easier to understand.


    Bastian, what should I do? Forward you all emails from the bug
    tracker? Or copy-paste the contents explaning why these two patches
    differ? I agree with you that it's a bit hard to follow the bug
    discussion, but this is probaly issue of the bug tracker, not mine. I
    also had the same problem when I started to search a fix.

    I don't want anything from you except from what you (the Debian Team)
    declare as your target - a well-tested, safe and working distro. With
    working X on SPARC. I did testing, writing the patch, again testing
    and posting all the results to the bug tracker. My soul is clear. As a
    programmer, I dream about such perfect users of my products. But what
    I see now is DD's fetish in arguing and not fixing the bugs. It seems
    to me that discussion "to fix or not to fix" became bigger than actual
    discussion of thing related to the bug. And you don't even bother to
    tell us why you made such decision. You simply tell us that patch is
    not fine. No further discussion, no suggestion, no interest to the
    problem. Leave it as it is. The Wall.

    >> In short, the last patch is the first patch
    >> merged with Gaudenz's patch which revert changes of SPARC PCI in
    >> 2.6.26 which breaks xserver-xorg-video-ati package.

    >
    > The first patch is fine. The revert is not.


    Well... The revert fixes X server's bug which exposed on 2.6.26 but
    works fine on previous kernel. New X server doesn't suffer from it and
    works on both pre-2.6.26 kernels and the new ones, but backporting
    this fix to the lenny's X server is very complicated task, AFAIK. So
    we see, that a well-written code works perfectly everywhere. And this
    should point us to the statement, that the revert doesn't break
    anything except buggy programs, like lenny's version of X. But buggy
    programs which deals with PCI in userspace are rare animals. And most
    of them, I think are not so important as X.

    A good question why you should care for X's bugs while being a kernel
    maintainer. But if religion doesn't allow you to include this patch
    then go on. I think most users will be excited if they know that
    during testing there was a fix for "getting this thing work", but some
    maintainer saw that patch as "not fine enough". This will serve a good
    service for the Debian reputation.

    --
    Max



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  10. Bug#500358: Fix found

    On Tue, Nov 11, 2008 at 18:22:57 +0100, Bastian Blank wrote:

    > The first patch is fine. The revert is not.
    >

    Even if the revert is the only way to get X to work on those machines in
    lenny?

    Cheers,
    Julien



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  11. Bug#500358: Fix found

    On Tue, Nov 11, 2008 at 08:20:01PM +0100, Julien Cristau wrote:
    > On Tue, Nov 11, 2008 at 18:22:57 +0100, Bastian Blank wrote:
    > > The first patch is fine. The revert is not.

    > Even if the revert is the only way to get X to work on those machines in
    > lenny?


    I fail to see the _kernel_ bug it fixes. I now know that this change
    triggers a bug in the old (considered broken by design[1]) PCI code in
    _X.org_.

    So this bug actually contains three:
    - The missalignment in the PCI code in the kernel.
    - The broken PCI access code in X.org.
    - A request to readd the workaround to the kernel to make X.org work
    again (and possibly break other things).

    Bastian

    [1]: <20080603.135449.193702216.davem@davemloft.net>
    --
    Warp 7 -- It's a law we can live with.



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  12. Bug#500358: Fix found

    On Tue, Nov 11, 2008 at 22:10:03 +0100, Bastian Blank wrote:

    > On Tue, Nov 11, 2008 at 08:20:01PM +0100, Julien Cristau wrote:
    > > On Tue, Nov 11, 2008 at 18:22:57 +0100, Bastian Blank wrote:
    > > > The first patch is fine. The revert is not.

    > > Even if the revert is the only way to get X to work on those machines in
    > > lenny?

    >
    > I fail to see the _kernel_ bug it fixes. I now know that this change
    > triggers a bug in the old (considered broken by design[1]) PCI code in
    > _X.org_.
    >

    The revert doesn't fix a kernel bug. It works around an X bug. I
    thought that was clear all along, sorry if it wasn't.

    Even if the revert breaks other things, it wouldn't be a regression from
    previous releases, though. We're not going to ship a newer Xorg in
    lenny, so with that revert we'd be fixing a known important regression
    by reopening a long-standing bug. I agree it's not ideal, but it
    doesn't seem like we can make everyone happy here, and that seems to be
    the least bad solution for this bug as far as lenny is concerned.
    Thanks for considering it.

    Cheers,
    Julien



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread