2.6.28-rc3-git6: Reported regressions from 2.6.27 - Kernel

This is a discussion on 2.6.28-rc3-git6: Reported regressions from 2.6.27 - Kernel ; "Rafael J. Wysocki" writes: > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11925 > Subject : cdrom: missing compat ioctls > Submitter : Andreas Schwab > Date : 2008-10-31 14:02 (10 days old) > First-Bad-Commit: http://git.kernel.org/?p=linux/kerne...0758d97e708ef6 > Handled-By : Andreas Schwab > Patch : http://marc.info/?l=linux-kernel&m=122548923531545&w=2 ...

+ Reply to Thread
Page 3 of 5 FirstFirst 1 2 3 4 5 LastLast
Results 41 to 60 of 85

Thread: 2.6.28-rc3-git6: Reported regressions from 2.6.27

  1. Re: [Bug #11925] cdrom: missing compat ioctls

    "Rafael J. Wysocki" writes:

    > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11925
    > Subject : cdrom: missing compat ioctls
    > Submitter : Andreas Schwab
    > Date : 2008-10-31 14:02 (10 days old)
    > First-Bad-Commit: http://git.kernel.org/?p=linux/kerne...0758d97e708ef6
    > Handled-By : Andreas Schwab
    > Patch : http://marc.info/?l=linux-kernel&m=122548923531545&w=2


    The patch has been picked up by akpm.

    Andreas.

    --
    Andreas Schwab, SuSE Labs, schwab@suse.de
    SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
    PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
    "And now for something completely different."
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [Bug #11925] cdrom: missing compat ioctls

    On Monday, 10 of November 2008, Andreas Schwab wrote:
    > "Rafael J. Wysocki" writes:
    >
    > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11925
    > > Subject : cdrom: missing compat ioctls
    > > Submitter : Andreas Schwab
    > > Date : 2008-10-31 14:02 (10 days old)
    > > First-Bad-Commit: http://git.kernel.org/?p=linux/kerne...0758d97e708ef6
    > > Handled-By : Andreas Schwab
    > > Patch : http://marc.info/?l=linux-kernel&m=122548923531545&w=2

    >
    > The patch has been picked up by akpm.


    OK, but has it been merged into mainline already?

    Rafael
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [Bug #11925] cdrom: missing compat ioctls

    "Rafael J. Wysocki" writes:

    > OK, but has it been merged into mainline already?


    No.

    Andreas.

    --
    Andreas Schwab, SuSE Labs, schwab@suse.de
    SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
    PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
    "And now for something completely different."
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [Bug #11911] new PCMCIA device instance after resume - orinoco can't download firmware

    On Sunday 09 November 2008, Rafael J. Wysocki wrote:
    > This message has been generated automatically as a part of a report
    > of recent regressions.
    >
    > The following bug entry is on the current list of known regressions
    > from 2.6.27. Please verify if it still should be listed and let me know
    > (either way).
    >


    Still present in rc4.

    >
    > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11911
    > Subject : new PCMCIA device instance after resume - orinoco can't download firmware
    > Submitter : Andrey Borzenkov
    > Date : 2008-10-28 19:19 (13 days old)
    > References : http://marc.info/?l=linux-wireless&m...2165719760&w=4
    > Handled-By : Dave
    > Patch : http://marc.info/?l=linux-wireless&m...9058601588&w=4
    >
    >
    >




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

    iEYEABECAAYFAkkXsKkACgkQR6LMutpd94yt0QCgrQYJ6zF5aT P/vriXRdtqO+GT
    a7AAn0kunfwD9Xx0jVgs9cvP9hT8NuBJ
    =PG3I
    -----END PGP SIGNATURE-----


  5. Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

    On Sun, 2008-11-09 at 18:59 +0100, Rafael J. Wysocki wrote:
    > This message has been generated automatically as a part of a report
    > of recent regressions.
    >
    > The following bug entry is on the current list of known regressions
    > from 2.6.27. Please verify if it still should be listed and let me know
    > (either way).


    Allright, so I finally managed to find a machine to reproduce it and
    I have a patch that fixes it here. I'm basically implementing the same
    thing as X which is to ensure the bitmap is padded to 32 pixels. The
    core fbcon has support for that to a certain extent so it's a fairly
    small change.

    Note that there was another bug, I think I was missing one
    wait_for_fifo() though fixing that didn't make a difference here.

    However, it's possible that this significantly impacts the performances,
    maybe to the point where we may want to back out the imageblt
    acceleration.

    David, would you mind testing on your machine ? It's the one that shows
    the biggest performance improvement, and I would like to know how much
    it is affected by that patch. As long as the "worst case" performance
    is still reasonable, I'm ok to take the hit if the improvement for you
    is still significant.

    Cheers,
    Ben.

    radeonfb: Fix accel problems with new imageblit hook

    Some radeon chips have issues with color expansion of pixmaps that
    aren't a multiple of 32 pixels wide. This works around it the same
    way X does by requesting the right pitch alignment from fbcon and
    then using the chip scissors to do clipping to the requested size.

    Signed-off-by: Benjamin Herrenschmidt
    ---

    If confirmed by the reporters (in CC), please apply for .28 as it
    fixes a regression.

    Index: linux-work/drivers/video/aty/radeon_accel.c
    ================================================== =================
    --- linux-work.orig/drivers/video/aty/radeon_accel.c 2008-11-10 14:05:06.000000000 +1100
    +++ linux-work/drivers/video/aty/radeon_accel.c 2008-11-10 14:34:45.000000000 +1100
    @@ -179,7 +179,7 @@ static void radeonfb_prim_imageblit(stru

    radeonfb_set_creg(rinfo, DP_GUI_MASTER_CNTL, &rinfo->dp_gui_mc_cache,
    rinfo->dp_gui_mc_base |
    - GMC_BRUSH_NONE |
    + GMC_BRUSH_NONE | GMC_DST_CLIP_LEAVE |
    GMC_SRC_DATATYPE_MONO_FG_BG |
    ROP3_S |
    GMC_BYTE_ORDER_MSB_TO_LSB |
    @@ -189,9 +189,6 @@ static void radeonfb_prim_imageblit(stru
    radeonfb_set_creg(rinfo, DP_SRC_FRGD_CLR, &rinfo->dp_src_fg_cache, fg);
    radeonfb_set_creg(rinfo, DP_SRC_BKGD_CLR, &rinfo->dp_src_bg_cache, bg);

    - radeon_fifo_wait(rinfo, 1);
    - OUTREG(DST_Y_X, (image->dy << 16) | image->dx);
    -
    /* Ensure the dst cache is flushed and the engine idle before
    * issuing the operation.
    *
    @@ -205,13 +202,19 @@ static void radeonfb_prim_imageblit(stru

    /* X here pads width to a multiple of 32 and uses the clipper to
    * adjust the result. Is that really necessary ? Things seem to
    - * work ok for me without that and the doco doesn't seem to imply
    + * work ok for me without that and the doco doesn't seem to imply]
    * there is such a restriction.
    */
    - OUTREG(DST_WIDTH_HEIGHT, (image->width << 16) | image->height);
    + radeon_fifo_wait(rinfo, 4);
    + OUTREG(SC_TOP_LEFT, (image->dy << 16) | image->dx);
    + OUTREG(SC_BOTTOM_RIGHT, ((image->dy + image->height) << 16) |
    + (image->dx + image->width));
    + OUTREG(DST_Y_X, (image->dy << 16) | image->dx);
    +
    + OUTREG(DST_HEIGHT_WIDTH, (image->height << 16) | ((image->width + 31) & ~31));

    - src_bytes = (((image->width * image->depth) + 7) / 8) * image->height;
    - dwords = (src_bytes + 3) / 4;
    + dwords = (image->width + 31) >> 5;
    + dwords *= image->height;
    bits = (u32*)(image->data);

    while(dwords >= 8) {
    Index: linux-work/drivers/video/aty/radeon_base.c
    ================================================== =================
    --- linux-work.orig/drivers/video/aty/radeon_base.c 2008-11-10 14:01:50.000000000 +1100
    +++ linux-work/drivers/video/aty/radeon_base.c 2008-11-10 14:36:26.000000000 +1100
    @@ -1875,6 +1875,7 @@ static int __devinit radeon_set_fbinfo (
    info->fbops = &radeonfb_ops;
    info->screen_base = rinfo->fb_base;
    info->screen_size = rinfo->mapped_vram;
    +
    /* Fill fix common fields */
    strlcpy(info->fix.id, rinfo->name, sizeof(info->fix.id));
    info->fix.smem_start = rinfo->fb_base_phys;
    @@ -1889,8 +1890,25 @@ static int __devinit radeon_set_fbinfo (
    info->fix.mmio_len = RADEON_REGSIZE;
    info->fix.accel = FB_ACCEL_ATI_RADEON;

    + /* Allocate colormap */
    fb_alloc_cmap(&info->cmap, 256, 0);

    + /* Setup pixmap used for acceleration */
    +#define PIXMAP_SIZE (2048 * 4)
    +
    + info->pixmap.addr = kmalloc(PIXMAP_SIZE, GFP_KERNEL);
    + if (!info->pixmap.addr) {
    + printk(KERN_ERR "radeonfb: Failed to allocate pixmap !\n");
    + noaccel = 1;
    + goto bail;
    + }
    + info->pixmap.size = PIXMAP_SIZE;
    + info->pixmap.flags = FB_PIXMAP_SYSTEM;
    + info->pixmap.scan_align = 4;
    + info->pixmap.buf_align = 4;
    + info->pixmap.access_align = 32;
    +
    +bail:
    if (noaccel)
    info->flags |= FBINFO_HWACCEL_DISABLED;



    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

    Benjamin Herrenschmidt writes:

    > On Sun, 2008-11-09 at 18:59 +0100, Rafael J. Wysocki wrote:
    >> This message has been generated automatically as a part of a report
    >> of recent regressions.
    >>
    >> The following bug entry is on the current list of known regressions
    >> from 2.6.27. Please verify if it still should be listed and let me know
    >> (either way).

    >
    > Allright, so I finally managed to find a machine to reproduce it and
    > I have a patch that fixes it here. I'm basically implementing the same
    > thing as X which is to ensure the bitmap is padded to 32 pixels.


    Works great here (as you might expect).

    --
    Paul Collins
    Wellington, New Zealand

    Dag vijandelijk luchtschip de huismeester is dood
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

    From: Benjamin Herrenschmidt
    Date: Mon, 10 Nov 2008 16:46:25 +1100

    > David, would you mind testing on your machine ? It's the one that shows
    > the biggest performance improvement, and I would like to know how much
    > it is affected by that patch. As long as the "worst case" performance
    > is still reasonable, I'm ok to take the hit if the improvement for you
    > is still significant.


    I will test this out at the very next opportunity.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

    On Mon, 2008-11-10 at 20:13 +1300, Paul Collins wrote:
    > Benjamin Herrenschmidt writes:
    >
    > > On Sun, 2008-11-09 at 18:59 +0100, Rafael J. Wysocki wrote:
    > >> This message has been generated automatically as a part of a report
    > >> of recent regressions.
    > >>
    > >> The following bug entry is on the current list of known regressions
    > >> from 2.6.27. Please verify if it still should be listed and let me know
    > >> (either way).

    > >
    > > Allright, so I finally managed to find a machine to reproduce it and
    > > I have a patch that fixes it here. I'm basically implementing the same
    > > thing as X which is to ensure the bitmap is padded to 32 pixels.

    >
    > Works great here (as you might expect).


    Yeah, well, Albook G4 with rv350, I think we have the same machine :-)

    Ben.


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [Bug #11989] Suspend failure on NForce4-based boards due to chanes in stop_machine

    On Sun, Nov 09, 2008 at 06:59:16PM +0100, Rafael J. Wysocki wrote:
    > This message has been generated automatically as a part of a report
    > of recent regressions.
    >
    > The following bug entry is on the current list of known regressions
    > from 2.6.27. Please verify if it still should be listed and let me know
    > (either way).
    >
    >
    > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11989
    > Subject : Suspend failure on NForce4-based boards due to chanes in stop_machine
    > Submitter : Rafael J. Wysocki
    > Date : 2008-11-03 0:28 (7 days old)
    > First-Bad-Commit: http://git.kernel.org/?p=linux/kerne...3c0bde6c50d9cc
    > References : http://marc.info/?l=linux-kernel&m=122567187604356&w=4


    Hi Rafael,

    could you provide more informations for this, please?

    What is your kernel configuration?
    Do you have any binary only modules (nvidia?) loaded?

    Is it possible to recreate the bug by e.g. just doing something like

    echo 0 > /sys/devices/system/cpu/cpu1/online

    (or any other online cpu)? Or does it trigger any lockdep warnings?
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [Bug #11989] Suspend failure on NForce4-based boards due to chanes in stop_machine

    On Monday, 10 of November 2008, Heiko Carstens wrote:
    > On Sun, Nov 09, 2008 at 06:59:16PM +0100, Rafael J. Wysocki wrote:
    > > This message has been generated automatically as a part of a report
    > > of recent regressions.
    > >
    > > The following bug entry is on the current list of known regressions
    > > from 2.6.27. Please verify if it still should be listed and let me know
    > > (either way).
    > >
    > >
    > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11989
    > > Subject : Suspend failure on NForce4-based boards due to chanes in stop_machine
    > > Submitter : Rafael J. Wysocki
    > > Date : 2008-11-03 0:28 (7 days old)
    > > First-Bad-Commit: http://git.kernel.org/?p=linux/kerne...3c0bde6c50d9cc
    > > References : http://marc.info/?l=linux-kernel&m=122567187604356&w=4

    >
    > Hi Rafael,


    Hi,

    > could you provide more informations for this, please?
    >
    > What is your kernel configuration?


    Available at: http://www.sisk.pl/kernel/debug/main...3/kitty-config

    > Do you have any binary only modules (nvidia?) loaded?


    No, I don't.

    > Is it possible to recreate the bug by e.g. just doing something like
    >
    > echo 0 > /sys/devices/system/cpu/cpu1/online


    I haven't checked (yet), I'll do that later today and let you know.

    > (or any other online cpu)? Or does it trigger any lockdep warnings?


    Thanks,
    Rafael
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [Bug #11895] 2.6.28-rc2 regression: keyboard dead after reboot on Toshiba Portege 4000

    On Sunday 09 November 2008, Rafael J. Wysocki wrote:
    > This message has been generated automatically as a part of a report
    > of recent regressions.
    >
    > The following bug entry is on the current list of known regressions
    > from 2.6.27. Please verify if it still should be listed and let me know
    > (either way).
    >


    it is fixed in rc4

    >
    > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11895


    Could you reassign this to ACPI product so this bug could be further
    investigated or should I open seperate one?

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

    iEYEABECAAYFAkkYZxIACgkQR6LMutpd94yiXACgrflMkzLbzT blHKx5yOQ9Uuia
    y78An0CfjaYBKgP7gf2b5cNju67CwYQ5
    =1ICX
    -----END PGP SIGNATURE-----


  12. Re: [Bug #11895] 2.6.28-rc2 regression: keyboard dead after reboot on Toshiba Portege 4000

    On Monday, 10 of November 2008, Andrey Borzenkov wrote:
    > On Sunday 09 November 2008, Rafael J. Wysocki wrote:
    > > This message has been generated automatically as a part of a report
    > > of recent regressions.
    > >
    > > The following bug entry is on the current list of known regressions
    > > from 2.6.27. Please verify if it still should be listed and let me know
    > > (either way).
    > >

    >
    > it is fixed in rc4
    >
    > >
    > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11895

    >
    > Could you reassign this to ACPI product so this bug could be further
    > investigated or should I open seperate one?


    Since you're saying it's fixed in -rc4, I'll close it and please open a
    separate one for the issue that's not been fixed yet.

    Thanks,
    Rafael
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

    Benjamin Herrenschmidt writes:

    > radeonfb: Fix accel problems with new imageblit hook
    >
    > Some radeon chips have issues with color expansion of pixmaps that
    > aren't a multiple of 32 pixels wide. This works around it the same
    > way X does by requesting the right pitch alignment from fbcon and
    > then using the chip scissors to do clipping to the requested size.


    Unfortunately this does not fix the suspend regression on PowerBook6,7.
    Instead I have to use the workaround in
    .

    Andreas.

    --
    Andreas Schwab, SuSE Labs, schwab@suse.de
    SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
    PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
    "And now for something completely different."
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

    On Mon, 2008-11-10 at 21:39 +0100, Andreas Schwab wrote:
    > Benjamin Herrenschmidt writes:
    >
    > > radeonfb: Fix accel problems with new imageblit hook
    > >
    > > Some radeon chips have issues with color expansion of pixmaps that
    > > aren't a multiple of 32 pixels wide. This works around it the same
    > > way X does by requesting the right pitch alignment from fbcon and
    > > then using the chip scissors to do clipping to the requested size.

    >
    > Unfortunately this does not fix the suspend regression on PowerBook6,7.
    > Instead I have to use the workaround in
    > .


    Strange. The suspend problem happens also when X hasn't been launched at all ?

    Ben.


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: [Bug #11989] Suspend failure on NForce4-based boards due to chanes in stop_machine

    On Monday, 10 of November 2008, Rafael J. Wysocki wrote:
    > On Monday, 10 of November 2008, Heiko Carstens wrote:
    > > On Sun, Nov 09, 2008 at 06:59:16PM +0100, Rafael J. Wysocki wrote:
    > > > This message has been generated automatically as a part of a report
    > > > of recent regressions.
    > > >
    > > > The following bug entry is on the current list of known regressions
    > > > from 2.6.27. Please verify if it still should be listed and let me know
    > > > (either way).
    > > >
    > > >
    > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11989
    > > > Subject : Suspend failure on NForce4-based boards due to chanes in stop_machine
    > > > Submitter : Rafael J. Wysocki
    > > > Date : 2008-11-03 0:28 (7 days old)
    > > > First-Bad-Commit: http://git.kernel.org/?p=linux/kerne...3c0bde6c50d9cc
    > > > References : http://marc.info/?l=linux-kernel&m=122567187604356&w=4

    > >
    > > Hi Rafael,

    >
    > Hi,
    >
    > > could you provide more informations for this, please?
    > >
    > > What is your kernel configuration?

    >
    > Available at: http://www.sisk.pl/kernel/debug/main...3/kitty-config
    >
    > > Do you have any binary only modules (nvidia?) loaded?

    >
    > No, I don't.
    >
    > > Is it possible to recreate the bug by e.g. just doing something like
    > >
    > > echo 0 > /sys/devices/system/cpu/cpu1/online

    >
    > I haven't checked (yet), I'll do that later today and let you know.
    >
    > > (or any other online cpu)? Or does it trigger any lockdep warnings?


    It cannot be reproduced with offlining CPU1 and it doesn't trigger any
    warnings from lockdep.

    However, it is reproducible by doing

    # echo core > /sys/power/pm_test

    and repeating

    # echo disk > /sys/power/state

    for a couple of times, in which case the last two lines printed to the console
    before a (solid) hang are:

    SMP alternatives: switching to SMP code
    Booting processor 1 APIC 0x1 ip 0x6000

    So, it evidently fails while re-enabling the non-boot CPU and not during
    disabling it as I thought before.

    With commit c9583e55fa2b08a230c549bd1e3c0bde6c50d9cc reverted the issue is
    not reproducible any more.

    Thanks,
    Rafael
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

    Benjamin Herrenschmidt writes:

    > On Mon, 2008-11-10 at 21:39 +0100, Andreas Schwab wrote:
    >> Benjamin Herrenschmidt writes:
    >>
    >> > radeonfb: Fix accel problems with new imageblit hook
    >> >
    >> > Some radeon chips have issues with color expansion of pixmaps that
    >> > aren't a multiple of 32 pixels wide. This works around it the same
    >> > way X does by requesting the right pitch alignment from fbcon and
    >> > then using the chip scissors to do clipping to the requested size.

    >>
    >> Unfortunately this does not fix the suspend regression on PowerBook6,7.
    >> Instead I have to use the workaround in
    >> .

    >
    > Strange. The suspend problem happens also when X hasn't been launched at all ?


    There seems to be some race involved here. I cannot reproduce the
    problem ATM.

    Andreas.

    --
    Andreas Schwab, SuSE Labs, schwab@suse.de
    SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
    PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
    "And now for something completely different."
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)


    > There seems to be some race involved here. I cannot reproduce the
    > problem ATM.


    I wonder if it's related to the new acceleration at all then.

    I've tried various suspend/resume cycles in straight console mode using
    directly snooze -f (kernel ioctl) and from X using ubuntu intrepid and
    gnome power manager and it worked fine on a 5,6 which should be fairly
    similar to your 6,7 I think.

    It's possible that there's yet another X related race though. I've seen
    cases of X whacking the chip -after- it has religuished the console back
    to the kernel (back to KD_TEXT) in the past which is very wrong, though
    I didn't spot that during my testing, there could be some race lurking
    there.

    Can you describe your problem more precisely ? I didn't see (or forgot)
    your initial report. Did it crash on suspend or wakeup ? what symptoms ?

    Note also that on PowerBooks, there's a platform hook that allows
    radeonfb to wake up the video chip _very_ early, thus allowing easier
    debugging of the boot process, so even races like that on wakeup would
    surprise me since we do wakup up the chip before we even get a chance to
    schedule userspace again (in fact before we even bring back the L2
    cache !)

    Cheers,
    Ben.


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

    Benjamin Herrenschmidt writes:

    > Can you describe your problem more precisely ?


    It crashes during suspend (after the console was switched away from X),
    but I can only see a frame buffer with apparently random contents when
    it happens. When suspend works then those random frame buffer contents
    are only briefly visible before the screen is cleared.

    Andreas.

    --
    Andreas Schwab, SuSE Labs, schwab@suse.de
    SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
    PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
    "And now for something completely different."
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)

    On Tue, 2008-11-11 at 00:54 +0100, Andreas Schwab wrote:
    >
    > > Can you describe your problem more precisely ?

    >
    > It crashes during suspend (after the console was switched away from X),
    > but I can only see a frame buffer with apparently random contents when
    > it happens. When suspend works then those random frame buffer contents
    > are only briefly visible before the screen is cleared.


    Does it actually switches away from X ?

    IE. You see the console before the crap on console or not ?

    I've seen what you describe happening when doing snooze -f (direct
    kernel ioctl) straight from within X. It seems to me that the problem
    was that for some reason it didn't switch the console, which would
    definitely make it crash. I need to double check what's up, it's
    possible that the kernel fails to switch it properly or fails to wait
    for X to ack the switch.

    In any case, I doesn't seem to be directly related to those radeonfb
    changes, though a clash with X like that is indeed more likely to
    actually happen if radeonfb relies more heavily on acceleration.

    I'll have a look later today at the console switch from X in the kernel
    see if it's been broken in a way or another.

    Note: I just did some tests using both echo "mem" >/sys/power/state and
    snooze -f and it worked fine. IE, the console switch away from X worked.
    So while I think I observed your problem once, I also cannot reproduce
    it now.

    I wonder if there's a race condition in the VT switch. It's possible
    that it could be yet another case of X whacking the chip after it has
    effectively relinguished control of the VT to the kernel, or it could be
    a kernel race.

    Cheers,
    Ben.


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: [Bug #11875] radeonfb lockup in .28-rc (bisected)



    On Tue, 11 Nov 2008, Benjamin Herrenschmidt wrote:
    >
    > In any case, I doesn't seem to be directly related to those radeonfb
    > changes, though a clash with X like that is indeed more likely to
    > actually happen if radeonfb relies more heavily on acceleration.


    Just a silly question, without actually looking at the code - since you
    now do acceleration in radeonfb, do you wait for everything to drain
    before you switch consoles?

    There could be races that depend on timing, where perhaps X is unhappy
    about being entered with the acceleration engine busy, or conversely the
    radeonfb code is unhappy about perhaps some still-in-progress X thing that
    hasn't been synchronously waited for..

    Before, radeonfb_imageblit() would always end up doing a
    "radeon_engine_idle()", so in practice, I think just about any fbcon
    access ended up idling the engine. Now, we can probably do a lot more
    without syncronizing - maybe there's insufficient synchronization at the
    switch-over from X to text-mode or vice versa?

    Linus
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 3 of 5 FirstFirst 1 2 3 4 5 LastLast