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 ; On Thu, 25 Sep 2008, Jesse Barnes wrote: > > Yes, I think that xorg/xorg i915 driver/libdrm/GEM/whatever are the > > biggest suspect currently, according to the data that has been > > gathered so far. > We have confirmation ...

+ Reply to Thread
Page 6 of 6 FirstFirst ... 4 5 6
Results 101 to 119 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

    On Thu, 25 Sep 2008, Jesse Barnes wrote:

    > > Yes, I think that xorg/xorg i915 driver/libdrm/GEM/whatever are the
    > > biggest suspect currently, according to the data that has been
    > > gathered so far.

    > We have confirmation that this isn't GEM related; according to the
    > Novell bug at https://bugzilla.novell.com/show_bug.cgi?id=425480 people
    > have hit the problem with kernels w/o GEM.


    But the xorg intel driver shipped with xorg 7.4 already has support for
    GEM, right? So there could still be some bug in the GEM-aware driver
    running on non-GEM kernel, can't it?

    > That doesn't rule out i915 (though I don't think any changes have gone
    > in since 2.6.26 that would have caused this) or xf86-video-intel. It's
    > possible that X is getting confused about BAR mappings somehow,
    > resulting in a clobbered e1000e NVRAM, but why would the kernel version
    > matter in that case? The only thing that comes to mind would be PAT...


    Yes, booting with 'nopat' is on my list to try immediately after we are
    able to recover the corrupted EEPROM.

    > Recent versions of the X drivers (using recent libpciaccess code) will
    > try to map the resourceN_wc file in sysfs. It's possible that the map
    > size we end up using is wrong, leading to the situation Dave described
    > earlier where we map too much MMIO space.


    This we could catch easily even with strace, right?

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

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

    Jiri Kosina writes:

    > Still, what confuses me a little bit -- the EEPROM of the card is set to
    > all 0xff, once the corruption happens. Isn't that a quite a coincidence,
    > that bytes representing "nothing" in this context are used?


    Perhaps the entire chip has been erased with the "ERAL" (erase all)
    command. Requires previously issued EWEN (erase/write enable).
    Each command seems to require several writes to the EEPROM control
    register.
    --
    Krzysztof Halasa
    --
    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 #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM

    On Thursday, September 25, 2008 1:22 pm Jiri Kosina wrote:
    > On Thu, 25 Sep 2008, Jesse Barnes wrote:
    > > > Yes, I think that xorg/xorg i915 driver/libdrm/GEM/whatever are the
    > > > biggest suspect currently, according to the data that has been
    > > > gathered so far.

    > >
    > > We have confirmation that this isn't GEM related; according to the
    > > Novell bug at https://bugzilla.novell.com/show_bug.cgi?id=425480 people
    > > have hit the problem with kernels w/o GEM.

    >
    > But the xorg intel driver shipped with xorg 7.4 already has support for
    > GEM, right? So there could still be some bug in the GEM-aware driver
    > running on non-GEM kernel, can't it?


    X.Org 7.4 came with xf86-video-intel 2.4.2 right? That doesn't have any GEM
    bits in it either.

    However, the "Factory" log at #425480 *does* indicate that a GEM aware 2D
    driver was loaded (the "[drm:i915_getparam] *ERROR* Unknown parameter 5"
    message indicates as much), but the kernel was definitely not GEM aware
    otherwise the call would have succeeded. So that rules out GEM proper, but
    it could still be a bug in one of the non-GEM paths in the experimental
    xf86-video-intel bits the various distros seem to be picking up.

    > > That doesn't rule out i915 (though I don't think any changes have gone
    > > in since 2.6.26 that would have caused this) or xf86-video-intel. It's
    > > possible that X is getting confused about BAR mappings somehow,
    > > resulting in a clobbered e1000e NVRAM, but why would the kernel version
    > > matter in that case? The only thing that comes to mind would be PAT...

    >
    > Yes, booting with 'nopat' is on my list to try immediately after we are
    > able to recover the corrupted EEPROM.
    >
    > > Recent versions of the X drivers (using recent libpciaccess code) will
    > > try to map the resourceN_wc file in sysfs. It's possible that the map
    > > size we end up using is wrong, leading to the situation Dave described
    > > earlier where we map too much MMIO space.

    >
    > This we could catch easily even with strace, right?


    Yep, that one's easy to catch.

    --
    Jesse Barnes, Intel Open Source Technology Center
    --
    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 Thu, 25 Sep 2008, Jesse Barnes wrote:

    > However, the "Factory" log at #425480 *does* indicate that a GEM aware
    > 2D driver was loaded (the "[drm:i915_getparam] *ERROR* Unknown parameter
    > 5" message indicates as much), but the kernel was definitely not GEM
    > aware otherwise the call would have succeeded. So that rules out GEM
    > proper, but it could still be a bug in one of the non-GEM paths in the
    > experimental xf86-video-intel bits the various distros seem to be
    > picking up.


    That was exactly the point I was trying to make, that these error paths
    will probably also need auditing, once we rule out the possibility of
    NVRAM being overwritten from kernelspace.

    Thanks,

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

    On Tue, 23 Sep 2008, David Miller wrote:
    > I did some snooping around, and while doing so I noticed that the PCI
    > mmap code for x86 doesn't do one bit of range checking on the size, or
    > any other aspect of the request, wrt. the MMIO regions actually mapped
    > in the BARs of the PCI device.


    Here's a patch that adds range checking to the sysfs mappings at least. This
    patch should catch the case where X (or some other process) tries to map
    beyond the specific BAR it's (supposedly) trying to access, making things
    safer in general. FWIW both my F9 and development versions of X start up
    fine with this patch applied.

    DaveM, will this work for you on sparc? It looked like your code was allowing
    bridge window mappings, but that behavior should be preserved as long as your
    bridge devices reflect their window sizes correctly in their pdev->resources?

    If we add similar code to the procfs stuff we wouldn't need to do any checking
    in the arches.

    diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
    index 9c71858..f4e8b4e 100644
    --- a/drivers/pci/pci-sysfs.c
    +++ b/drivers/pci/pci-sysfs.c
    @@ -502,6 +502,8 @@ pci_mmap_resource(struct kobject *kobj, struct
    bin_attribute *attr,
    struct resource *res = (struct resource *)attr->private;
    enum pci_mmap_state mmap_type;
    resource_size_t start, end;
    + unsigned long map_len = vma->vm_end - vma->vm_start;
    + unsigned long map_offset = vma->vm_pgoff << PAGE_SHIFT;
    int i;

    for (i = 0; i < PCI_ROM_RESOURCE; i++)
    @@ -510,6 +512,13 @@ pci_mmap_resource(struct kobject *kobj, struct
    bin_attribute *attr,
    if (i >= PCI_ROM_RESOURCE)
    return -ENODEV;

    + /*
    + * Make sure the range the user is trying to map falls within
    + * the resource
    + */
    + if (map_offset + map_len > pci_resource_len(pdev, i))
    + return -EINVAL;
    +
    /* pci_mmap_page_range() expects the same kind of entry as coming
    * from /proc/bus/pci/ which is a "user visible" value. If this is
    * different from the resource itself, arch will do necessary fixup.
    --
    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 Thu, 25 Sep 2008, Jesse Barnes wrote:

    > Here's a patch that adds range checking to the sysfs mappings at least.
    > This patch should catch the case where X (or some other process) tries
    > to map beyond the specific BAR it's (supposedly) trying to access,
    > making things safer in general. FWIW both my F9 and development
    > versions of X start up fine with this patch applied.


    Good. We will use this on affected machines after we start some real
    debugging of this.

    > + /*
    > + * Make sure the range the user is trying to map falls within
    > + * the resource
    > + */
    > + if (map_offset + map_len > pci_resource_len(pdev, i))
    > + return -EINVAL;
    > +


    At least for debugging purposes I'd propose to put a printk() there with
    process name, and the range it tries to map.

    Thanks,

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

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

    From: Jiri Kosina
    Date: Thu, 25 Sep 2008 19:24:57 +0200 (CEST)

    > If being set to 0 (it's so easy to call memset(0) on a bogus pointer,
    > there are usually lots of them in the code) or to random garbage, it would
    > seem to be much more understandable, than 0xff.


    Setting framebuffer bytes to 0xff is pretty common, for example
    for color keys and anti-aliasing pixel values.
    --
    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 #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM

    Jiri Kosina wrote:
    > On Wed, 24 Sep 2008, Kyle McMartin wrote:
    >
    >> I've been working on a patch to detect (using a timer and checking at
    >> up/down) whether or not the flash has been corrupted, and, if it is
    >> rewrite it with the saved good copy (which obviously only helps if
    >> it's the same boot.)

    >
    > Thanks, looks interesting e1000e hack that might possibly be of some help.
    >
    > BUT! please have a look at
    >
    > http://lkml.org/lkml/2008/9/24/133
    >
    > Looks like this device got a lot of 0xff written somewhere in its config
    > space, right? But it isn't Intel card at all.


    I asked that person and he said reverting to an older kernel made it work again,
    also there is a fix out as romieu pointed out as well, so this seems to be a
    different bug for now.

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

    On Fri, Sep 26, 2008 at 6:35 AM, Jiri Kosina wrote:
    > On Thu, 25 Sep 2008, Jesse Barnes wrote:
    >
    >> However, the "Factory" log at #425480 *does* indicate that a GEM aware
    >> 2D driver was loaded (the "[drm:i915_getparam] *ERROR* Unknown parameter
    >> 5" message indicates as much), but the kernel was definitely not GEM
    >> aware otherwise the call would have succeeded. So that rules out GEM
    >> proper, but it could still be a bug in one of the non-GEM paths in the
    >> experimental xf86-video-intel bits the various distros seem to be
    >> picking up.

    >
    > That was exactly the point I was trying to make, that these error paths
    > will probably also need auditing, once we rule out the possibility of
    > NVRAM being overwritten from kernelspace.
    >


    Well the non-GEM paths are really the old codepaths we used in the
    older drivers..

    So unless we do something really dumb...

    I'd target three areas PAT, pciaccess and e1000e itself.

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

    On Thu, Sep 25, 2008 at 2:06 PM, Dave Airlie wrote:
    > I'd target three areas PAT, pciaccess and e1000e itself.


    ubuntu has CONFIG_X86_PAT disabled for at least i386 arch, maybe that
    is relevant.
    --
    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 Fri, 26 Sep 2008, Dave Airlie wrote:

    > >> I'd target three areas PAT, pciaccess and e1000e itself.

    > > ubuntu has CONFIG_X86_PAT disabled for at least i386 arch, maybe that
    > > is relevant.

    > It rules out PAT I suppose, they have seen the issue as well.


    I wasn't able to rule out PAT from the suse bugreports POV, as we have PAT
    enabled both for 32bit and 64bit x86.

    If Ubuntu has it disabled also for 64bit x86 (where do these guys have
    ..config files to check?), I think we can definitely rule out PAT, as there
    has been at least one report from Ubuntu user on this very issue.

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

    On Fri, Sep 26, 2008 at 7:42 AM, Jesse Brandeburg
    wrote:
    > On Thu, Sep 25, 2008 at 2:06 PM, Dave Airlie wrote:
    >> I'd target three areas PAT, pciaccess and e1000e itself.

    >
    > ubuntu has CONFIG_X86_PAT disabled for at least i386 arch, maybe that
    > is relevant.
    >


    It rules out PAT I suppose, they have seen the issue as well.

    Dave.
    --
    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

    Jiri Kosina wrote:
    > On Thu, 25 Sep 2008, Jesse Barnes wrote:
    >
    >> However, the "Factory" log at #425480 *does* indicate that a GEM aware
    >> 2D driver was loaded (the "[drm:i915_getparam] *ERROR* Unknown parameter
    >> 5" message indicates as much), but the kernel was definitely not GEM
    >> aware otherwise the call would have succeeded. So that rules out GEM
    >> proper, but it could still be a bug in one of the non-GEM paths in the
    >> experimental xf86-video-intel bits the various distros seem to be
    >> picking up.

    >
    > That was exactly the point I was trying to make, that these error paths
    > will probably also need auditing, once we rule out the possibility of
    > NVRAM being overwritten from kernelspace.
    >


    Okay, I just had a scary and hopefully stupid thought.

    Especially Intel often has backchannels between the chipset and the
    Ethernet controller for management functions -- anything from WoL to
    IPMI -- generally over some kind of low-speed serial bus.

    We're not in a situation where the EEPROM can be touched from the
    chipset via the SMBus or some other non-CPU channel?

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

    On Fr, 2008-09-26 at 00:45 +0200, Jiri Kosina wrote:
    > On Fri, 26 Sep 2008, Dave Airlie wrote:
    >
    > > >> I'd target three areas PAT, pciaccess and e1000e itself.
    > > > ubuntu has CONFIG_X86_PAT disabled for at least i386 arch, maybe that
    > > > is relevant.

    > > It rules out PAT I suppose, they have seen the issue as well.

    >
    > I wasn't able to rule out PAT from the suse bugreports POV, as we have PAT
    > enabled both for 32bit and 64bit x86.
    >
    > If Ubuntu has it disabled also for 64bit x86 (where do these guys have
    > .config files to check?), I think we can definitely rule out PAT, as there
    > has been at least one report from Ubuntu user on this very issue.
    >


    I'm testing ubuntu intrepid also "afected system" but not affected card
    and use e1000e driver. (i945g+ich7)
    as i can see ubuntu at least now do not use pat on 32bit system.

    config is attached.


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

    "H. Peter Anvin" writes:

    > Okay, I just had a scary and hopefully stupid thought.
    >
    > Especially Intel often has backchannels between the chipset and the
    > Ethernet controller for management functions -- anything from WoL to
    > IPMI -- generally over some kind of low-speed serial bus.
    >
    > We're not in a situation where the EEPROM can be touched from the
    > chipset via the SMBus or some other non-CPU channel?


    I know next to nothing about SMBus and especially those other
    backchannels, but the 82566 product brief :-) lists support for:
    - Intel Active Management Technology (AMT) with "System Defence"
    (whatever that means)
    - ASF 2.0
    I think ASF (Alert Standard Format) is somehow related to IPMI and
    uses I^2C or something similar (SMBus).

    8254x manual says that the EEPROM is divided into 4 parts: one for
    E1000 hw initialization, one for ASF (Ethernet in ASF mode?), one for
    external BMC (TCO) (loaded by external BMC from the SMBus) and one for
    software only (not used by hardware). Some chips only support #1 (and
    #4 of course).

    I understand the driver reads the EEPROM using EERD register (which,
    according to the manual, requires no additional locking) or drives the
    EEPROM directly, with a lock/unlock protocol (using EECD register).
    Now some devices lack the lock/unlock bits, but they lack ASF/BMC as
    well.

    I imagine chips other than 8254x may be different here.

    Do we have some "master" bugzilla entry or something like that for
    these problems?
    --
    Krzysztof Halasa
    --
    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

    > external BMC (TCO) (loaded by external BMC from the SMBus) and one for
    > software only (not used by hardware). Some chips only support #1 (and
    > #4 of course).


    We have had historic problems where a very non standard EEPROM setup on
    some ancient thinkpads ended up with bad stuff happening due to smbus
    probing and the like. You would then however expect to see the bug occur
    without loading the e1000* drivers (unless you needed an interaction
    between the two)

    --
    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 #11516] severe performance degradation on x86_64 going from 2.6.26-rc9 -&gt; 2.6.27-rc5

    On Tue, 23 Sep 2008, Jason Vas Dias wrote:

    > CPU Frequency switching is completely disabled both when
    > powernow-k8 (the correct cpufreq module for my x86_64 AMD TL-64x2
    > 2.2GHz CPU) is installed as a module or is built-in , and the CPU
    > frequency remains at its lowest setting; attempts to modify
    > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq and
    > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed are not
    > honored, even though /sys/devices/system/cpu/cpu0/cpufreq/governor
    > is "userspace" and scaling_min_freq < scaling_setspeed >
    > scaling_max_freq .
    >
    > I see no messages from powernow-k8 indicating that it is aware it
    > was unable to set the speed, though I do see a message if I attempt
    > to set an invalid speed (eg 600000) .
    >
    > With 2.6.26-rc9, I get a default CPU clock frequency of 2200000 ;
    > with 2.6.27-rc6, it becomes 800000 and is not switchable. For some
    > reason, powernow-k8 does not autoload with UDEV; but I don't really
    > need it if the speed is already set to its highest level.
    >
    > On 2.6.27-rc6. after it manages to boot, any low-latency drivers
    > time out (eg. USB, Terminal, Keyboard, Network) and the machine does
    > not get through the boot-up sequence without becoming overloaded by
    > the kernel's debugging log messages - neither the network , the
    > terminal or the keyboard work usably.
    >
    > Building a kernel with USB completely disabled and turning off
    > debug log messages allows the machine to boot (after @ 15 minutes)
    > but the speed is still at its lowest setting and cannot be changed.


    I have to admit that I'm confused.

    The dmesg output
    [ 0.000000] Linux version 2.6.27-rc6.jvd ...
    .....
    [ 26.204477] hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0000

    says 26 seconds up to the point where user space should start. Also
    USB is active in that log and I dont see timeout messages at all.

    I have a hard time to connect this to your problem description
    (timeouts, USB off, 15 minutes)

    Can you please shed some light on this ?

    > Also, 2.6.27-rc6 is unable to reboot the machine: it can put the
    > machine into the "HALT" state, with nothing displayed on the screen,
    > but the machine does not power-off until manual reset with the
    > power-button. Then, after the machine has powered-down, it cannot be
    > powered up until the power-on button is depressed for at least two
    > sections an released TWICE in a row.


    Len, any opinon on this:

    [ 0.000000] ACPI Error (tbfadt-0453): 32/64X address mismatch in "Pm2ControlBlock":
    [00008800] [0000000000008100], using 64X [20080609]

    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/

  18. Re: [Bug #11516] severe performance degradation on x86_64 going from 2.6.26-rc9 -&gt; 2.6.27-rc5

    On Sun, 28 Sep 2008, Jason Vas Dias wrote:
    > The problem is not "slow booting" - indeed, as noted in the bug, boot time up to the point
    > where user space should start is very similar to the non-problematic 2.6.26 kernels.
    >
    > The USB problem is that @ 10 messages per second are emitted to the log:
    > Sep 28 00:41:51 localhost kernel: [ 11.985257] hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0002
    > Sep 28 00:41:51 localhost kernel: [ 12.789240] hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0004
    > Sep 28 00:41:51 localhost kernel: [ 12.937169] hub 4-0:1.0: state 7 ports 2 chg 0000 evt 0000
    > Sep 28 00:41:51 localhost kernel: [ 12.937188] hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0002
    > Sep 28 00:41:51 localhost kernel: [ 13.041167] hub 5-0:1.0: state 7 ports 2 chg 0000 evt 0000
    > Sep 28 00:41:51 localhost kernel: [ 13.041186] hub 6-0:1.0: state 7 ports 10 chg 0000 evt 0000
    > Sep 28 00:41:51 localhost kernel: [ 13.453734] hub 6-0:1.0: state 7 ports 10 chg 0000 evt 0020
    > Sep 28 00:41:51 localhost kernel: [ 13.453748] hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0004
    > Sep 28 00:41:51 localhost kernel: [ 13.846512] hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0002
    > Sep 28 00:41:51 localhost kernel: [ 14.220994] hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0002
    >
    > Why should USB be emitting state change messages when no state has changed ?


    That's a separate question.

    > I think this is because the core PM-timer (clocksource is acpi-pm) is kaput ,
    > and every driver that depends on high-resolution timers gets confused .


    No, if the pmtimer would be defect your machine would not even reach
    user space.

    I analysed the proc/acpi data of .25 and .27 and the machine is set to
    throttling state T7 (12%) which would explain that behaviour halfways.

    Can you please verify if that state is always T7 on your machine with
    ..27 ?

    Also please add "acpi.debug_level=0x11" to the kernel command line so
    we can get some more information out of the ACPI code.

    > Displaying text on the terminal is @ 140 times slower under 2.6.27
    > kernels than under 2.6.26 kernels . Downloads over the network take
    > @ 1000 times longer under 2.6.27 than under 2.6.26. Disk I/O is @
    > 100 times slower.


    That's indeed insane.

    > There are numerous log messages about "interrupt during system call"
    > (EINTR) from user-space processes.


    Separate problem as well.

    Please let us concentrate on the throttling aspect and not mix
    USB/EINTR stuff into it for now.

    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/

  19. Re: [Bug #11220] Screen stays black after resume

    On Sun 2008-09-21 20:54:09, 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=11220
    > Subject : Screen stays black after resume
    > Submitter : Nico Schottelius
    > Date : 2008-07-31 21:05 (53 days old)
    > References : http://marc.info/?l=linux-kernel&m=121753882422899&w=4


    This is actually three problems in one :-(.

    If you try to suspend with minimum config, will resume still take 30
    seconds?

    Is the problem still there in 2.6.27-rc7?

    Is there chance to bisect it?
    Pavel
    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/blog.html
    --
    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 6 of 6 FirstFirst ... 4 5 6