2.6.27-rc6-git6: Reported regressions from 2.6.26 - Kernel

This is a discussion on 2.6.27-rc6-git6: Reported regressions from 2.6.26 - Kernel ; From: "Dave Airlie" Date: Mon, 22 Sep 2008 16:59:51 +1000 > I've reconstructed my boot timeline from message logs > > Sep 3rd, I booted rawhide kernel 2.6.27-0.290.rc5.fc10.i686 What upstream SHA1 is this based upon? > I suspended/resume a few ...

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

Thread: 2.6.27-rc6-git6: Reported regressions from 2.6.26

  1. Re: [Bug #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM

    From: "Dave Airlie"
    Date: Mon, 22 Sep 2008 16:59:51 +1000

    > I've reconstructed my boot timeline from message logs
    >
    > Sep 3rd, I booted rawhide kernel 2.6.27-0.290.rc5.fc10.i686


    What upstream SHA1 is this based upon?

    > I suspended/resume a few times in between with no issues.
    >
    > Sep 8th I booted my own 2.6.27-rc5 kernel based from
    > ec0c15afb41fd9ad45b53468b60db50170e22346
    >
    > This got a corrupted e1000e checksum and every kernel since has.


    Ok.
    --
    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 #11552] Disabling IRQ #23

    On Sun, 21 Sep 2008, Justin Mattock wrote:

    > From over here, I did a bad install
    > of isight-firmware-tools, causing hal and udev
    > to clash. After making sure the package was either
    > using hal or udev, there is no message of disable irq #23.
    > If its not too much trouble is there a way to verify that this was
    > the case, i.g. if udev creates a dev, then hal creates the same device
    > will this cause ehci_hcd to have messages of this kind? If so
    > then thats what happened, if not then theres something else causing this.


    You didn't read what I wrote earlier, did you? The "HC died" message
    should NEVER occur! It doesn't matter what games you play with hal and
    udev -- it should NEVER occur. Not ever.

    And since the "HC died" is what causes IRQ #23 to be disabled, that
    shouldn't happen either.

    Alan Stern

    --
    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 #11552] Disabling IRQ #23

    On Mon, Sep 22, 2008 at 3:53 AM, Alan Stern wrote:
    > On Sun, 21 Sep 2008, Justin Mattock wrote:
    >
    >> From over here, I did a bad install
    >> of isight-firmware-tools, causing hal and udev
    >> to clash. After making sure the package was either
    >> using hal or udev, there is no message of disable irq #23.
    >> If its not too much trouble is there a way to verify that this was
    >> the case, i.g. if udev creates a dev, then hal creates the same device
    >> will this cause ehci_hcd to have messages of this kind? If so
    >> then thats what happened, if not then theres something else causing this.

    >
    > You didn't read what I wrote earlier, did you? The "HC died" message
    > should NEVER occur! It doesn't matter what games you play with hal and
    > udev -- it should NEVER occur. Not ever.
    >
    > And since the "HC died" is what causes IRQ #23 to be disabled, that
    > shouldn't happen either.
    >
    > Alan Stern
    >
    >


    appologize for not fully understanidng,
    I'm just getting confused with why and what is causing this
    to occur. The only reason for playing with hal and udev
    is to have this message appear, if I leave them out of the picture
    the system runs fine.
    Anyways, I'm up to trying anything at this point, and again
    appologize for causing any heat.

    --
    Justin P. Mattock
    --
    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 #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM

    On Mon, 22 Sep 2008, Dave Airlie wrote:

    > Sep 8th I booted my own 2.6.27-rc5 kernel based from
    > ec0c15afb41fd9ad45b53468b60db50170e22346
    > This got a corrupted e1000e checksum and every kernel since has.


    Have you restored the EEPROM contents after it got corrupted for the first
    time?

    Once the EEPROM contents get corrupted, the card will then be broken
    forever even on kernel that gets this fixed one day.

    This is pretty serious bug in fact, as it renders hardware of poor users
    unusable, and just patching kernel is then not enough to put things back
    to shape.

    --
    Jiri Kosina
    SUSE Labs

    --
    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/

  5. Re: [Bug #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM

    From: Jiri Kosina
    Date: Tue, 23 Sep 2008 00:15:08 +0200 (CEST)

    > On Mon, 22 Sep 2008, Dave Airlie wrote:
    >
    > > Sep 8th I booted my own 2.6.27-rc5 kernel based from
    > > ec0c15afb41fd9ad45b53468b60db50170e22346
    > > This got a corrupted e1000e checksum and every kernel since has.

    >
    > Have you restored the EEPROM contents after it got corrupted for the first
    > time?
    >
    > Once the EEPROM contents get corrupted, the card will then be broken
    > forever even on kernel that gets this fixed one day.
    >
    > This is pretty serious bug in fact, as it renders hardware of poor users
    > unusable, and just patching kernel is then not enough to put things back
    > to shape.


    The top priority is to root cause this, so that we can stop the
    problem from happening as fast as possible, and I'm still waiting for
    the SHA1 ID that was used for the last kernel Dave booted before the
    problem occurred which is pretty damn critical for making forward
    progress here.

    It could even be some PCI or x86 layer change that caused the corruption,
    we don't even know yet.
    --
    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 #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM

    On Tue, Sep 23, 2008 at 8:28 AM, David Miller wrote:
    > From: Jiri Kosina
    > Date: Tue, 23 Sep 2008 00:15:08 +0200 (CEST)
    >
    >> On Mon, 22 Sep 2008, Dave Airlie wrote:
    >>
    >> > Sep 8th I booted my own 2.6.27-rc5 kernel based from
    >> > ec0c15afb41fd9ad45b53468b60db50170e22346
    >> > This got a corrupted e1000e checksum and every kernel since has.

    >>
    >> Have you restored the EEPROM contents after it got corrupted for the first
    >> time?
    >>
    >> Once the EEPROM contents get corrupted, the card will then be broken
    >> forever even on kernel that gets this fixed one day.
    >>
    >> This is pretty serious bug in fact, as it renders hardware of poor users
    >> unusable, and just patching kernel is then not enough to put things back
    >> to shape.

    >
    > The top priority is to root cause this, so that we can stop the
    > problem from happening as fast as possible, and I'm still waiting for
    > the SHA1 ID that was used for the last kernel Dave booted before the
    > problem occurred which is pretty damn critical for making forward
    > progress here.


    It was exactly 2.6.27-rc5 + Fedora at the time but we rarely touch
    these areas, most of the extra code is in other places, and since
    people are seeing it on !Fedora
    also I would assume it wasn't these.

    I think people have seen it on earlier kernels maybe but not sure.

    really Intel needs to get a fix of some sort out so we can repair the
    hw so we can root cause the probem.

    Dave.

    >
    > It could even be some PCI or x86 layer change that caused the corruption,
    > we don't even know yet.
    >

    --
    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 #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM

    From: "Dave Airlie"
    Date: Tue, 23 Sep 2008 11:26:52 +1000

    > On Tue, Sep 23, 2008 at 8:28 AM, David Miller wrote:
    > > From: Jiri Kosina
    > > Date: Tue, 23 Sep 2008 00:15:08 +0200 (CEST)
    > >
    > >> On Mon, 22 Sep 2008, Dave Airlie wrote:
    > >>
    > >> > Sep 8th I booted my own 2.6.27-rc5 kernel based from
    > >> > ec0c15afb41fd9ad45b53468b60db50170e22346
    > >> > This got a corrupted e1000e checksum and every kernel since has.

    ...
    > It was exactly 2.6.27-rc5 + Fedora at the time but we rarely touch
    > these areas, most of the extra code is in other places, and since
    > people are seeing it on !Fedora
    > also I would assume it wasn't these.
    >
    > I think people have seen it on earlier kernels maybe but not sure.


    So I went through the changes from 2.6.27-rc5 until the SHA1
    ID ec0c15afb41fd9ad45b53468b60db50170e22346 and there were
    definitely no E1000 or E1000E changes during that time.

    Included in there is the HPET revert and other similarly themed
    changes.

    commit b4609472116bb806a95e98d04767189406c74c70
    Author: Linus Torvalds
    Date: Fri Aug 29 14:38:03 2008 -0700

    Revert "x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3"

    This reverts commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd.

    Some power management related changes stand out slightly:

    commit 9d3593574702ae1899e23a1535da1ac71f928042
    Author: John Kacur
    Date: Tue Sep 2 14:36:13 2008 -0700

    pm_qos_requirement might sleep

    and

    commit 74c4633da7994eddcfcd2762a448c6889cc2b5bd
    Author: Rafael J. Wysocki
    Date: Tue Sep 2 14:36:11 2008 -0700

    rtc-cmos: wake again from S5

    The rest of the changes in that range look completely benign.
    --
    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 #11568] spontaneous reboot on resume with 2.6.27

    On Sun, Sep 21, 2008 at 08:54:21PM +0200, 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.26. Please verify if it still should be listed and let me know
    > (either way).
    >
    >
    > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11568
    > Subject : spontaneous reboot on resume with 2.6.27
    > Submitter : Andy Wettstein
    > Date : 2008-09-14 20:00 (8 days old)


    Just verified it is still a problem with 2.6.27-rc7.

    --
    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 #11543] kernel panic: softlockup in tick_periodic() ???

    On Sun, 21 Sep 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.26. Please verify if it still should be listed and let me know
    > (either way).
    >
    >
    > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11543
    > Subject : kernel panic: softlockup in tick_periodic() ???


    The softlockup issue itself is fixed, but there are issues with
    nmi_watchdog. I think we should remove the regression and keep the bug
    alive to chase the other issues.

    Thanks,

    tglx

    --
    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 #11543] kernel panic: softlockup in tick_periodic() ???

    On Tuesday, 23 of September 2008, Thomas Gleixner wrote:
    > On Sun, 21 Sep 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.26. Please verify if it still should be listed and let me know
    > > (either way).
    > >
    > >
    > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11543
    > > Subject : kernel panic: softlockup in tick_periodic() ???

    >
    > The softlockup issue itself is fixed, but there are issues with
    > nmi_watchdog. I think we should remove the regression and keep the bug
    > alive to chase the other issues.


    Well, for the sake of documentation I'd prefer to close this bug and create a
    new non-regression one for the other issues if that's not a problem.

    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 #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM

    On Mon, 22 Sep 2008, David Miller wrote:

    > So I went through the changes from 2.6.27-rc5 until the SHA1
    > ID ec0c15afb41fd9ad45b53468b60db50170e22346 and there were
    > definitely no E1000 or E1000E changes during that time.


    Some recent comments on [1] seem to indicate that this is somehow coupled
    into prior problems/panics with Intel graphics.

    David, was this also your case, or did the EEPROM got garbled out of a
    sudden?

    [1] https://bugzilla.novell.com/show_bug.cgi?id=425480

    --
    Jiri Kosina
    SUSE Labs
    --
    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/

  12. Re: [Bug #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM

    Jiri Kosina wrote:
    > Some recent comments on [1] seem to indicate that this is somehow coupled
    > into prior problems/panics with Intel graphics.
    >
    > David, was this also your case, or did the EEPROM got garbled out of a
    > sudden?
    > [1] https://bugzilla.novell.com/show_bug.cgi?id=425480


    And...





    Best regards,
    Renato
    --
    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 #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM

    On Wed, Sep 24, 2008 at 12:29 AM, Jiri Kosina wrote:
    > On Mon, 22 Sep 2008, David Miller wrote:
    >
    >> So I went through the changes from 2.6.27-rc5 until the SHA1
    >> ID ec0c15afb41fd9ad45b53468b60db50170e22346 and there were
    >> definitely no E1000 or E1000E changes during that time.

    >
    > Some recent comments on [1] seem to indicate that this is somehow coupled
    > into prior problems/panics with Intel graphics.
    >
    > David, was this also your case, or did the EEPROM got garbled out of a
    > sudden?


    I have no evidence in my logs of a graphics panic, but I do do a lot
    of graphics devel,
    so it might be a possiblity but I'd hate to handwave it away at that.

    Dave.

    >
    > [1] https://bugzilla.novell.com/show_bug.cgi?id=425480
    >
    > --
    > Jiri Kosina
    > SUSE Labs
    >

    --
    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 #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM

    From: Jiri Kosina
    Date: Tue, 23 Sep 2008 16:29:16 +0200 (CEST)

    > On Mon, 22 Sep 2008, David Miller wrote:
    >
    > > So I went through the changes from 2.6.27-rc5 until the SHA1
    > > ID ec0c15afb41fd9ad45b53468b60db50170e22346 and there were
    > > definitely no E1000 or E1000E changes during that time.

    >
    > Some recent comments on [1] seem to indicate that this is somehow coupled
    > into prior problems/panics with Intel graphics.


    My current suspicion in all of this is either the GEM kernel patches
    or recent X server.

    However, the eeprom/nvram programming sequence seems non-trivial on
    the e1000e. You have to execute a set of precise register writes
    and register polls to successfully write things out to the nvram.

    This makes something like a random scribble out to MMIO space less
    likely to cause this problem.

    Is there some linear mapping of the nvram that could be written to
    on these cards?
    --
    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 #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM

    On Wed, Sep 24, 2008 at 7:05 AM, David Miller wrote:
    > From: Jiri Kosina
    > Date: Tue, 23 Sep 2008 16:29:16 +0200 (CEST)
    >
    >> On Mon, 22 Sep 2008, David Miller wrote:
    >>
    >> > So I went through the changes from 2.6.27-rc5 until the SHA1
    >> > ID ec0c15afb41fd9ad45b53468b60db50170e22346 and there were
    >> > definitely no E1000 or E1000E changes during that time.

    >>
    >> Some recent comments on [1] seem to indicate that this is somehow coupled
    >> into prior problems/panics with Intel graphics.

    >
    > My current suspicion in all of this is either the GEM kernel patches
    > or recent X server.
    >


    I don't think OpenSUSE was shipping any of the GEM bits.

    Dave.

    > However, the eeprom/nvram programming sequence seems non-trivial on
    > the e1000e. You have to execute a set of precise register writes
    > and register polls to successfully write things out to the nvram.
    >
    > This makes something like a random scribble out to MMIO space less
    > likely to cause this problem.
    >
    > Is there some linear mapping of the nvram that could be written to
    > on these cards?
    >

    --
    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 #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM

    From: "Dave Airlie"
    Date: Wed, 24 Sep 2008 07:09:09 +1000

    > On Wed, Sep 24, 2008 at 7:05 AM, David Miller wrote:
    > > From: Jiri Kosina
    > > Date: Tue, 23 Sep 2008 16:29:16 +0200 (CEST)
    > >
    > >> On Mon, 22 Sep 2008, David Miller wrote:
    > >>
    > >> > So I went through the changes from 2.6.27-rc5 until the SHA1
    > >> > ID ec0c15afb41fd9ad45b53468b60db50170e22346 and there were
    > >> > definitely no E1000 or E1000E changes during that time.
    > >>
    > >> Some recent comments on [1] seem to indicate that this is somehow coupled
    > >> into prior problems/panics with Intel graphics.

    > >
    > > My current suspicion in all of this is either the GEM kernel patches
    > > or recent X server.
    > >

    >
    > I don't think OpenSUSE was shipping any of the GEM bits.


    Good data point, can someone confirm this? Also, what X server version
    is the effected OpenSUSE shipping?
    --
    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 #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM

    From: "Dave Airlie"
    Date: Wed, 24 Sep 2008 07:03:53 +1000

    > I have no evidence in my logs of a graphics panic, but I do do a lot
    > of graphics devel,
    > so it might be a possiblity but I'd hate to handwave it away at that.


    Let's not handwave, but rather try to figure out if that is part of
    the pattern.

    Right now we don't have any real leads, so data acquisition is really
    important at this phase.
    --
    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 #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM

    On Tue, 23 Sep 2008, Jeff Kirsher wrote:

    > >> I don't think OpenSUSE was shipping any of the GEM bits.

    > > Good data point, can someone confirm this? Also, what X server version
    > > is the effected OpenSUSE shipping?

    > OpenSuSE 11 ships x server version 7.3.


    Opensuse 11 is fine.

    The problem can be reproduced [not only] on opensuse 11.1 beta1, which has

    xorg-x11-7.4-1.6.x86_64.rpm

    --
    Jiri Kosina
    --
    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 #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM

    On Tue, Sep 23, 2008 at 3:07 PM, David Miller wrote:
    > From: "Dave Airlie"
    > Date: Wed, 24 Sep 2008 07:09:09 +1000
    >
    >> On Wed, Sep 24, 2008 at 7:05 AM, David Miller wrote:
    >> > From: Jiri Kosina
    >> > Date: Tue, 23 Sep 2008 16:29:16 +0200 (CEST)
    >> >
    >> >> On Mon, 22 Sep 2008, David Miller wrote:
    >> >>
    >> >> > So I went through the changes from 2.6.27-rc5 until the SHA1
    >> >> > ID ec0c15afb41fd9ad45b53468b60db50170e22346 and there were
    >> >> > definitely no E1000 or E1000E changes during that time.
    >> >>
    >> >> Some recent comments on [1] seem to indicate that this is somehow coupled
    >> >> into prior problems/panics with Intel graphics.
    >> >
    >> > My current suspicion in all of this is either the GEM kernel patches
    >> > or recent X server.
    >> >

    >>
    >> I don't think OpenSUSE was shipping any of the GEM bits.

    >
    > Good data point, can someone confirm this? Also, what X server version
    > is the effected OpenSUSE shipping?
    > --



    OpenSuSE 11 ships x server version 7.3.

    --
    Cheers,
    Jeff
    --
    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 #11548] kernel BUG at drivers/pci/intel-iommu.c:1373!

    On Sun, 2008-09-21 at 20:54 +0200, 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.26. Please verify if it still should be listed and let me know
    > (either way).
    >


    I'm unable to reproduce this on 2.6.27-rc7. I don't think it has been
    fixed, but I'm having a hard time finding a reliable way to trigger it
    on newer kernels.

    -chris


    --
    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 6 FirstFirst 1 2 3 4 5 ... LastLast