Linux 2.6.28-rc2 - Kernel

This is a discussion on Linux 2.6.28-rc2 - Kernel ; It's not been a week yet, but we had a few annoying brown-paper-bugs in -rc1 that made it hard for many people to test without applying patches. So rather than wait out the week, I'll just make an -rc2 early, ...

+ Reply to Thread
Results 1 to 16 of 16

Thread: Linux 2.6.28-rc2

  1. Linux 2.6.28-rc2


    It's not been a week yet, but we had a few annoying brown-paper-bugs in
    -rc1 that made it hard for many people to test without applying patches.
    So rather than wait out the week, I'll just make an -rc2 early, with the
    fixes for the problems that kept people from testing it.

    And hey, maybe we can even _continue_ the nice model of "just small fixes
    after -rc1". I know, it sounds insane, but it's a real pleasure to do an
    -rc2 with just a handful of fixes for real problems that real people see.
    What a concept!

    Anyway, as a result, the shortlog and diffstats are both tiny, and easily
    appended. There's a few hwmon fixes and some pretty trivial ones, but the
    noticeable ones are:

    - the non-NCQ libata breakage thing that broke lots of peoples setups

    - the workqueue init bug that caused various random problems if you had
    a SMP machine and did not enable HOTPLUG_CPU. Symptoms included boot
    hangs, or hung applications (eg sound from firefox) or lack of USB
    activity (eg "no keyboard reaction")

    - some broken apps seemed to be unhappy that we checked the 'struct
    timeval' timeout to select for sanity, since they initialized it with
    insane multi-second microsecond fields. Oh, well.

    - ext3/ext4 had introduced a bug where the same directory entry might get
    returned twice under some circumstances, which didn't faze most
    programs, but caused problems for at least "rm -r" and "git clean"

    There's other stuff in there too, but not much, and most of it is pretty
    trivial (eg odd config issues, or the explanation for why you should
    enable the regulatory option for wireless) or much harder to trigger (the
    eventpoll oops fix). Or small fixes to random drivers (hwmon and the r8169
    fix).

    Linus

    ---
    Al Viro (2):
    fix allmodconfig breakage
    arm ide breakage

    Alistair John Strachan (2):
    hwmon: (abituguru3) Cosmetic whitespace fixes
    hwmon: (abituguru3) enable DMI probing feature on AW9D-MAX

    Arjan van de Ven (2):
    wireless: fix regression caused by regulatory config option
    select: deal with math overflow from borderline valid userland data

    Davide Libenzi (1):
    epoll: avoid double-inserts in case of EFAULT

    Francois Romieu (1):
    r8169: revert "read MAC address from EEPROM on init"

    Geert Uytterhoeven (2):
    hwmon: (w83781d) Fix linking when built-in
    m68k: Disable Amiga serial console support if modular

    Jean Delvare (4):
    hwmon-vid: Add support for AMD family 10h CPUs
    hwmon: (lm90) Fix handling of hysteresis value
    hwmon: (lm90) Add support for the LM99 16 degree offset
    hwmon: (adt7473) Fix voltage conversion routines

    Jens Axboe (1):
    libata: fix bug with non-ncq devices

    Linus Torvalds (2):
    Revert "Call init_workqueues before pre smp initcalls."
    Linux 2.6.28-rc2

    Stephen Rothwell (1):
    cgroup: remove unused variable

    Theodore Ts'o (2):
    ext3: Fix duplicate entries returned from getdents() system call
    ext4: Fix duplicate entries returned from getdents() system call

    ---
    Documentation/hwmon/lm90 | 2 +-
    Makefile | 2 +-
    drivers/ata/libata-scsi.c | 6 ++-
    drivers/char/amiserial.c | 6 ++-
    drivers/hwmon/abituguru3.c | 30 +++++++-------
    drivers/hwmon/adt7473.c | 29 ++++----------
    drivers/hwmon/hwmon-vid.c | 1 +
    drivers/hwmon/lm90.c | 52 ++++++++++++++++++++++---
    drivers/hwmon/w83781d.c | 4 +-
    drivers/ide/icside.c | 4 +-
    drivers/ide/rapide.c | 4 +-
    drivers/net/r8169.c | 88 --------------------------------------------
    fs/compat.c | 5 +-
    fs/eventpoll.c | 11 ++++-
    fs/ext3/dir.c | 20 ++++------
    fs/ext4/dir.c | 20 ++++------
    fs/select.c | 5 +-
    init/main.c | 3 +-
    kernel/cgroup.c | 2 +-
    kernel/stop_machine.c | 2 +-
    net/wireless/Kconfig | 11 ++---
    scripts/kconfig/confdata.c | 3 +-
    22 files changed, 127 insertions(+), 183 deletions(-)
    --
    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: [2.6.28-rc2] EeePC ACPI errors & exceptions

    On Mon, 2008-10-27 at 15:52 -0700, Darren Salt wrote:
    Will you please attach the output of acpidump?
    Of course you can file a bug report at
    http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
    and attach the output of acpidump, dmesg.

    It will be better if you can add the boot option of "printk.time=1".
    thanks.

    > EeePC 901, BIOS revision 1603, current Debian lenny; running on AC.
    >
    > I've noticed the following errors & exceptions, apparently coinciding with
    > the startup of xfce4-sensors-plugin:
    >
    > ACPI: EC: missing confirmations, switch off interrupt mode.
    > ACPI Exception (evregion-0419): AE_TIME, Returned by Handler for [EmbeddedControl] [20080926]
    > ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.SBRG.EC0_.BST2] (Node f7030d38), AE_TIME
    > ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.CBST] (Node f70336f8), AE_TIME
    > ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.BAT0._BST] (Node f7031c48), AE_TIME
    > ACPI Exception (battery-0360): AE_TIME, Evaluating _BST [20080926]
    >
    > Also, this (which, unlike the above, is also present with 2.6.27.*):
    >
    > ACPI: I/O resource 0000:00:1f.3 [0x400-0x41f] conflicts with ACPI region SMRG [0x400-0x40f]
    > ACPI: Device needs an ACPI driver
    >
    > Full dmesg & config are attached.
    >
    > (The Elantech touchpad patch from http://arjan.opmeer.net/elantech/ is
    > applied to this kernel.)
    >


    --
    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: [2.6.28-rc2] EeePC ACPI errors & exceptions

    On Mon, 2008-10-27 at 15:52 -0700, Darren Salt wrote:
    > EeePC 901, BIOS revision 1603, current Debian lenny; running on AC.
    >
    > I've noticed the following errors & exceptions, apparently coinciding with
    > the startup of xfce4-sensors-plugin:

    Will you please confirm whether the same issue exists on the previous
    kernel? For example: 2.6.27 or 2.6.27-rc6

    After the following commit is merged, it seems that on the EEEPC laptop
    the EC will switch off EC GPE interrupt mode when there is no EC GPE
    interrupt confirm for some EC transactions. Then AE_TIME is returned by
    the function of ec_poll, which causes that the _BST object of battery
    can't be evaluated.
    >commit 7c6db4e050601f359081fde418ca6dc4fc2d0011
    >Author: Alexey Starikovskiy
    >Date: Thu Sep 25 21:00:31 2008 +0400
    >ACPI: EC: do transaction from interrupt context


    When there is no EC GPE interrupt confirm in some EC transaction, the
    EC will switch off the EC GPE interrupt mode in the function of
    acpi_ec_wait.

    But why is AE_TIME returned by the function of ec_poll?
    >static int ec_poll(struct acpi_ec *ec)

    {
    unsigned long delay = jiffies + msecs_to_jiffies(ACPI_EC_DELAY);
    msleep(1);
    // Maybe the current jiffies is already after the predefined jiffies
    after msleep(1). In such case the ETIME will be returned. Of course the
    EC transaction can't be finished. If so, IMO this is not reasonable as
    this is caused by that OS has no opportunity to issue the following EC
    command sequence.
    while (time_before(jiffies, delay)) {
    gpe_transaction(ec, acpi_ec_read_status(ec));
    msleep(1);
    if (ec_transaction_done(ec))
    return 0;
    //Maybe there exists the following cases. EC transaction is not finished
    after msleep(1),but the current jiffies is already after predefined
    jiffies. So ETIME is returned. In such case, IMO this is also not
    reasonable.
    }
    return -ETIME;
    }
    At the same time msleep is realized by schedule_timeout. On linux
    although one process is waked up by some events, it won't be scheduled
    immediately. So maybe the current jiffies is already after the
    predefined timeout jiffies after msleep(1).

    Now some people suggest that msleep is replaced by udelay. Although
    the above two cases can be avoided by that msleep is replaced by udelay,
    maybe the above two cases still exist if the preempt schedule happens at
    the corresponding place.
    At the same time when msleep is replaced by udelay, CPU will do
    nothing but loop while executing udelay. If the 100 EC transactions are
    done in one second, the CPU will do nothing in about 100*2*100
    microseconds. IMO this is not reasonable.

    IMO the better solution is that the EC transaction is divided into
    the different phases. (Not do the EC transaction in one loop).
    For example:
    The EC read transaction can be done in the following sequence:
    a. Issue read command
    b. wait until the EC input buffer is empty and then write the EC
    internal read address
    c. wait until the EC output buffer is ready and read the data from
    EC the Data port. Of course it indicates that EC read transaction is
    finished.

    The EC write transaction can be done in the following sequence:
    a. issue the write command
    b. wait until the EC input buffer is empty and write the EC internal
    write address
    c. wait until the EC input buffer is empty and write the data to the
    EC Data port
    d. wait until the EC input buffer is empty. After it becomes empty,
    it indicates that the EC write transaction is finished.

    Welcome the comments.
    Thanks.


    > ACPI: EC: missing confirmations, switch off interrupt mode.
    > ACPI Exception (evregion-0419): AE_TIME, Returned by Handler for [EmbeddedControl] [20080926]
    > ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.SBRG.EC0_.BST2] (Node f7030d38), AE_TIME
    > ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.CBST] (Node f70336f8), AE_TIME
    > ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.BAT0._BST] (Node f7031c48), AE_TIME
    > ACPI Exception (battery-0360): AE_TIME, Evaluating _BST [20080926]
    >
    > Also, this (which, unlike the above, is also present with 2.6.27.*):
    >
    > ACPI: I/O resource 0000:00:1f.3 [0x400-0x41f] conflicts with ACPI region SMRG [0x400-0x40f]
    > ACPI: Device needs an ACPI driver
    >
    > Full dmesg & config are attached.
    >
    > (The Elantech touchpad patch from http://arjan.opmeer.net/elantech/ is
    > applied to this kernel.)
    >


    --
    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: [2.6.28-rc2] EeePC ACPI errors & exceptions

    On Mon, 2008-10-27 at 15:52 -0700, Darren Salt wrote:
    > EeePC 901, BIOS revision 1603, current Debian lenny; running on AC.
    >
    > I've noticed the following errors & exceptions, apparently coinciding with
    > the startup of xfce4-sensors-plugin:
    >
    > ACPI: EC: missing confirmations, switch off interrupt mode.
    > ACPI Exception (evregion-0419): AE_TIME, Returned by Handler for [EmbeddedControl] [20080926]
    > ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.SBRG.EC0_.BST2] (Node f7030d38), AE_TIME
    > ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.CBST] (Node f70336f8), AE_TIME
    > ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.BAT0._BST] (Node f7031c48), AE_TIME
    > ACPI Exception (battery-0360): AE_TIME, Evaluating _BST [20080926]

    Will you please try the attached patch on the 2.6.28-rc2 and see whether
    the issue still exists?
    After the test, please attach the output of dmesg.


    The following is included by the attached patch.
    a. EC transaction is divided into several phases.
    For example: EC write transaction
    a. issue EC write command
    b. wait until the input is empty and then write the internal
    address
    c. wait until the input is empty and write the data
    d. wait until the input is empty. If it is empty, it indicates
    that EC transaction is finished.
    At the same time EC driver will be started in EC GEP mode. And when
    there is no EC GPE confirmation for some EC transaction on some broken
    laptops,the EC driver will be switched to polling mode. But EC GPE is
    still enabled.

    b. Some delay is added in the EC GPE handler on some broken BIOS.
    The delay won't be added for most laptops.Only when more than five
    interrupts happen in the same jiffies and EC status are the same, OS
    will add some delay in the EC GPE handler. If the same issue still
    happens after adding delay,the delay time will be increased.But the max
    delay time is ten microseconds.

    Thanks.

    >
    > Also, this (which, unlike the above, is also present with 2.6.27.*):
    >
    > ACPI: I/O resource 0000:00:1f.3 [0x400-0x41f] conflicts with ACPI region SMRG [0x400-0x40f]
    > ACPI: Device needs an ACPI driver
    >
    > Full dmesg & config are attached.
    >
    > (The Elantech touchpad patch from http://arjan.opmeer.net/elantech/ is
    > applied to this kernel.)
    >



  5. Re: Linux 2.6.28-rc2 i/o error on /dev/ttyUSB0

    I have gps unit connected via USB-serial (pl2303).
    This does not work with 2.6.28-rc2

    udev creates devices as usual, but /dev/ttyUSB0 fail.
    cat /dev/ttyUSB0 gives i/o errors, for example.

    gpsd try several times, and then fall back on opening
    in read-only mode. This works, but gpsd doesn't actually
    get any data at all from the unit.

    The pc is a core2duo laptop, using a 64-bit smp kernel.

    2.6.27 is fine. I skipped 2.6.28-rc1 due to known breakage.
    I can test it if that might help.

    Helge Hafting
    --
    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: Linux 2.6.28-rc2 i/o error on /dev/ttyUSB0



    On Tue, 28 Oct 2008, Helge Hafting wrote:
    >
    > I have gps unit connected via USB-serial (pl2303).
    > This does not work with 2.6.28-rc2
    >
    > 2.6.27 is fine. I skipped 2.6.28-rc1 due to known breakage.
    > I can test it if that might help.


    Don't bother with -rc1, but bisecting it may be relevant. You might of
    course hit the breakage, but it's fairly unlikely.

    That said, the whole "error on USB serial device" sounds like it's
    squarely in the "oops, kref's are screwed up" corner, and you should talk
    to Alan about your particular USB dongle. I bet that bisection would just
    show you one of the kref commits (eg 4a90f09b "tty: usb-serial krefs" or
    maybe 7d7b93c14 "tty: kref the tty driver object").

    Alan, pls help.

    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/

  7. Re: Linux 2.6.28-rc2 i/o error on /dev/ttyUSB0

    > squarely in the "oops, kref's are screwed up" corner, and you should talk
    > to Alan about your particular USB dongle. I bet that bisection would just
    > show you one of the kref commits (eg 4a90f09b "tty: usb-serial krefs" or
    > maybe 7d7b93c14 "tty: kref the tty driver object").


    Doesn't sound like krefs but does sound like the tty layer changes
    somewhere.

    Helge - can you get me an strace of this
    --
    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: [2.6.28-rc2] EeePC ACPI errors & exceptions

    Hi Darren,

    Please check if the patch
    http://marc.info/?l=linux-acpi&m=122516784917952&w=4
    helps.

    Thanks,
    Alex.


    --
    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: [2.6.28-rc2] EeePC ACPI errors & exceptions

    On Tue, 2008-10-28 at 13:46 -0700, Alexey Starikovskiy wrote:
    > Hi Darren,
    >
    > Please check if the patch
    > http://marc.info/?l=linux-acpi&m=122516784917952&w=4
    > helps.

    In the attached patch the msleep is replaced by udelay gain.
    In the following commit the udelay is replaced by msleep.
    >commit 1b7fc5aae8867046f8d3d45808309d5b7f2e036a
    >Author: Alexey Starikovskiy
    >Date: Fri Jun 6 11:49:33 2008 -0400
    >ACPI: EC: Use msleep instead of udelay while waiting for event


    After the problem happens again, the udelay is restored again before
    getting the root cause.
    Maybe we should find the root cause of the problem and change the
    working flowchart about the EC driver. It is inappropriate that we make
    some changes and it is reverted again when the problem happens.

    At the same time after mlseep is replaced by the udelay, the CPU will
    do thing but loop while doing EC transaction on some laptops (In the
    function of ec_poll). If 100 EC transactions are done, the CPU will do
    nothing but loop at least for 100*2*100 microseconds. In such case maybe
    the performance will be affected.

    After the following commit is merged, the EC transaction will be
    executed in EC GPE interrupt context on most laptops.Maybe it is easier.
    But for the some laptops it can't be done in EC GPE interrupt context.
    So it falls back to the EC polling mode. (This is realized by the
    function of ec_poll).
    >commit 7c6db4e050601f359081fde418ca6dc4fc2d0011
    >Author: Alexey Starikovskiy
    >Date: Thu Sep 25 21:00:31 2008 +0400
    >ACPI: EC: do transaction from interrupt context


    Why is AE_TIME sometimes returned by the function of ec_poll?
    >static int ec_poll(struct acpi_ec *ec)

    {
    unsigned long delay = jiffies + msecs_to_jiffies(ACPI_EC_DELAY);
    msleep(1);
    // Maybe the current jiffies is already after the predefined jiffies
    after msleep(1). In such case the ETIME will be returned. Of course the
    EC transaction can't be finished. If so, IMO this is not reasonable as
    this is caused by that OS has no opportunity to issue the following EC
    command sequence.
    while (time_before(jiffies, delay)) {
    gpe_transaction(ec, acpi_ec_read_status(ec));
    msleep(1);
    if (ec_transaction_done(ec))
    return 0;
    //Maybe there exists the following cases. EC transaction is not finished
    after msleep(1),but the current jiffies is already after predefined
    jiffies. So ETIME is returned. In such case, IMO this is also not
    reasonable.
    }
    return -ETIME;
    }
    At the same time msleep is realized by schedule_timeout. On linux
    although one process is waked up by some events, it won't be scheduled
    immediately. So maybe the current jiffies is already after the
    predefined timeout jiffies after msleep(1).
    Although the possibility of this issue can be reduced by that msleep
    is replaced by udelay,maybe the issue still exists if the preempt
    schedule happens at the corresponding place.

    In the above case the ETIME will be returned by ec_poll. But the
    reason is not that EC controller can't update its status in time.
    Instead it is caused by that host has no opportunity to issue the
    sequence operation in the current work flowchart. In current EC work
    flowchart the EC transaction is done in a big loop.

    Maybe the better solution is that the EC transaction is explicitly
    divided into several different phases.

    Maybe my analysis is not correct. If so, please correct me.
    Welcome the comments.

    thanks.



    > Thanks,
    > Alex.
    >
    >


    --
    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: [2.6.28-rc2] EeePC ACPI errors & exceptions

    Not a problem, just find the root cause. Or shut up.


    Zhao Yakui wrote:
    > On Tue, 2008-10-28 at 13:46 -0700, Alexey Starikovskiy wrote:
    >
    >> Hi Darren,
    >>
    >> Please check if the patch
    >> http://marc.info/?l=linux-acpi&m=122516784917952&w=4
    >> helps.
    >>

    > In the attached patch the msleep is replaced by udelay gain.
    > In the following commit the udelay is replaced by msleep.
    > >commit 1b7fc5aae8867046f8d3d45808309d5b7f2e036a
    > >Author: Alexey Starikovskiy
    > >Date: Fri Jun 6 11:49:33 2008 -0400
    > >ACPI: EC: Use msleep instead of udelay while waiting for event

    >
    > After the problem happens again, the udelay is restored again before
    > getting the root cause.
    > Maybe we should find the root cause of the problem and change the
    > working flowchart about the EC driver. It is inappropriate that we make
    > some changes and it is reverted again when the problem happens.
    >
    > At the same time after mlseep is replaced by the udelay, the CPU will
    > do thing but loop while doing EC transaction on some laptops (In the
    > function of ec_poll). If 100 EC transactions are done, the CPU will do
    > nothing but loop at least for 100*2*100 microseconds. In such case maybe
    > the performance will be affected.
    >
    > After the following commit is merged, the EC transaction will be
    > executed in EC GPE interrupt context on most laptops.Maybe it is easier.
    > But for the some laptops it can't be done in EC GPE interrupt context.
    > So it falls back to the EC polling mode. (This is realized by the
    > function of ec_poll).
    > >commit 7c6db4e050601f359081fde418ca6dc4fc2d0011
    > >Author: Alexey Starikovskiy
    > >Date: Thu Sep 25 21:00:31 2008 +0400
    > >ACPI: EC: do transaction from interrupt context

    >
    > Why is AE_TIME sometimes returned by the function of ec_poll?
    >
    >> static int ec_poll(struct acpi_ec *ec)
    >>

    > {
    > unsigned long delay = jiffies + msecs_to_jiffies(ACPI_EC_DELAY);
    > msleep(1);
    > // Maybe the current jiffies is already after the predefined jiffies
    > after msleep(1). In such case the ETIME will be returned. Of course the
    > EC transaction can't be finished. If so, IMO this is not reasonable as
    > this is caused by that OS has no opportunity to issue the following EC
    > command sequence.
    > while (time_before(jiffies, delay)) {
    > gpe_transaction(ec, acpi_ec_read_status(ec));
    > msleep(1);
    > if (ec_transaction_done(ec))
    > return 0;
    > //Maybe there exists the following cases. EC transaction is not finished
    > after msleep(1),but the current jiffies is already after predefined
    > jiffies. So ETIME is returned. In such case, IMO this is also not
    > reasonable.
    > }
    > return -ETIME;
    > }
    > At the same time msleep is realized by schedule_timeout. On linux
    > although one process is waked up by some events, it won't be scheduled
    > immediately. So maybe the current jiffies is already after the
    > predefined timeout jiffies after msleep(1).
    > Although the possibility of this issue can be reduced by that msleep
    > is replaced by udelay,maybe the issue still exists if the preempt
    > schedule happens at the corresponding place.
    >
    > In the above case the ETIME will be returned by ec_poll. But the
    > reason is not that EC controller can't update its status in time.
    > Instead it is caused by that host has no opportunity to issue the
    > sequence operation in the current work flowchart. In current EC work
    > flowchart the EC transaction is done in a big loop.
    >
    > Maybe the better solution is that the EC transaction is explicitly
    > divided into several different phases.
    >
    > Maybe my analysis is not correct. If so, please correct me.
    > Welcome the comments.
    >
    > thanks.
    >
    >
    >
    >
    >> Thanks,
    >> Alex.
    >>
    >>
    >>

    >
    >


    --
    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: [2.6.28-rc2] EeePC ACPI errors & exceptions

    On Wed, 2008-10-29 at 17:29 +0800, Alexey Starikovskiy wrote:
    > Not a problem, just find the root cause. Or shut up.

    Maybe you don't read the explanation I have written.
    >
    > Zhao Yakui wrote:
    > > On Tue, 2008-10-28 at 13:46 -0700, Alexey Starikovskiy wrote:
    > >
    > >> Hi Darren,
    > >>
    > >> Please check if the patch
    > >> http://marc.info/?l=linux-acpi&m=122516784917952&w=4
    > >> helps.
    > >>

    > > In the attached patch the msleep is replaced by udelay gain.
    > > In the following commit the udelay is replaced by msleep.
    > > >commit 1b7fc5aae8867046f8d3d45808309d5b7f2e036a
    > > >Author: Alexey Starikovskiy
    > > >Date: Fri Jun 6 11:49:33 2008 -0400
    > > >ACPI: EC: Use msleep instead of udelay while waiting for event

    > >
    > > After the problem happens again, the udelay is restored again before
    > > getting the root cause.
    > > Maybe we should find the root cause of the problem and change the
    > > working flowchart about the EC driver. It is inappropriate that we make
    > > some changes and it is reverted again when the problem happens.
    > >
    > > At the same time after mlseep is replaced by the udelay, the CPU will
    > > do thing but loop while doing EC transaction on some laptops (In the
    > > function of ec_poll). If 100 EC transactions are done, the CPU will do
    > > nothing but loop at least for 100*2*100 microseconds. In such case maybe
    > > the performance will be affected.
    > >
    > > After the following commit is merged, the EC transaction will be
    > > executed in EC GPE interrupt context on most laptops.Maybe it is easier.
    > > But for the some laptops it can't be done in EC GPE interrupt context.
    > > So it falls back to the EC polling mode. (This is realized by the
    > > function of ec_poll).
    > > >commit 7c6db4e050601f359081fde418ca6dc4fc2d0011
    > > >Author: Alexey Starikovskiy
    > > >Date: Thu Sep 25 21:00:31 2008 +0400
    > > >ACPI: EC: do transaction from interrupt context

    > >

    The following is the detailed explanation why this issue happens. In
    fact after you sent your patch, I raise the issue about it. But it is
    ignored. (Maybe the AE_TIME will be returned by EC driver. But the
    reason is not caused by that EC controller can't update its status in
    time. Instead it is caused by that host has no opportunity to issue the
    sequence EC command.)
    >
    > > Why is AE_TIME sometimes returned by the function of ec_poll?
    > >
    > >> static int ec_poll(struct acpi_ec *ec)
    > >>

    > > {
    > > unsigned long delay = jiffies + msecs_to_jiffies(ACPI_EC_DELAY);
    > > msleep(1);
    > > // Maybe the current jiffies is already after the predefined jiffies
    > > after msleep(1). In such case the ETIME will be returned. Of course the
    > > EC transaction can't be finished. If so, IMO this is not reasonable as
    > > this is caused by that OS has no opportunity to issue the following EC
    > > command sequence.
    > > while (time_before(jiffies, delay)) {
    > > gpe_transaction(ec, acpi_ec_read_status(ec));
    > > msleep(1);
    > > if (ec_transaction_done(ec))
    > > return 0;
    > > //Maybe there exists the following cases. EC transaction is not finished
    > > after msleep(1),but the current jiffies is already after predefined
    > > jiffies. So ETIME is returned. In such case, IMO this is also not
    > > reasonable.
    > > }
    > > return -ETIME;
    > > }
    > > At the same time msleep is realized by schedule_timeout. On linux
    > > although one process is waked up by some events, it won't be scheduled
    > > immediately. So maybe the current jiffies is already after the
    > > predefined timeout jiffies after msleep(1).
    > > Although the possibility of this issue can be reduced by that msleep
    > > is replaced by udelay,maybe the issue still exists if the preempt
    > > schedule happens at the corresponding place.
    > >
    > > In the above case the ETIME will be returned by ec_poll. But the
    > > reason is not that EC controller can't update its status in time.
    > > Instead it is caused by that host has no opportunity to issue the
    > > sequence operation in the current work flowchart. In current EC work
    > > flowchart the EC transaction is done in a big loop.
    > >
    > > Maybe the better solution is that the EC transaction is explicitly
    > > divided into several different phases.
    > >
    > > Maybe my analysis is not correct. If so, please correct me.
    > > Welcome the comments.
    > >
    > > thanks.
    > >
    > >
    > >
    > >
    > >> Thanks,
    > >> Alex.
    > >>
    > >>
    > >>

    > >
    > >

    >


    --
    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: [2.6.28-rc2] EeePC ACPI errors & exceptions

    Zhao Yakui wrote:
    > On Wed, 2008-10-29 at 17:29 +0800, Alexey Starikovskiy wrote:
    >
    >> Not a problem, just find the root cause. Or shut up.
    >>

    > Maybe you don't read the explanation I have written.
    >

    Found root cause should not have "maybe" before it.

    --
    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: Linux 2.6.28-rc2 lost IDE disk on old laptop

    Hi,

    On Thu, Oct 30, 2008 at 2:50 PM, Wolfgang Erig wrote:
    > Hi,
    >
    > the kernel 2.6.28-rc2 does not boot on my old laptop.
    > Panic ... cannot access (301) ... aka /dev/hda1
    > The previously used version 2.6.27-rc8 runs fine.
    >
    > During 'make oldconfig' I saw questions about IDE (or ATA)
    > but I see no obvious problem with my .config
    >
    > Wolfgang
    >
    >
    > $ lspci
    > 00:00.0 Host bridge: Intel Corporation 430TX - 82439TX MTXC (rev 01)
    > 00:01.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 01)
    > 00:01.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)


    Have you tried compiling your kernel with CONFIG_BLK_DEV_PIIX enabled and
    CONFIG_IDE_GENERIC disabled?

    > 00:01.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01)
    > 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
    > 00:06.0 VGA compatible controller: Chips and Technologies F65554 (rev c2)
    > 00:14.0 CardBus bridge: Cirrus Logic PD 6832 PCMCIA/CardBus Ctrlr (rev c1)
    > 00:14.1 CardBus bridge: Cirrus Logic PD 6832 PCMCIA/CardBus Ctrlr (rev c1)
    >
    > $ egrep -i 'ide|ata' .config
    > # CONFIG_X86_MCE_NONFATAL is not set
    > # CONFIG_ATALK is not set
    > CONFIG_HAVE_IDE=y
    > CONFIG_IDE=y
    > # Please see Documentation/ide/ide.txt for help/info on IDE drives
    > # CONFIG_BLK_DEV_IDE_SATA is not set
    > CONFIG_IDE_GD=y
    > CONFIG_IDE_GD_ATA=y
    > # CONFIG_IDE_GD_ATAPI is not set
    > # CONFIG_BLK_DEV_IDECS is not set
    > CONFIG_BLK_DEV_IDECD=y
    > CONFIG_BLK_DEV_IDECD_VERBOSE_ERRORS=y
    > # CONFIG_BLK_DEV_IDETAPE is not set
    > # CONFIG_BLK_DEV_IDESCSI is not set
    > # CONFIG_IDE_TASK_IOCTL is not set
    > # CONFIG_IDE_PROC_FS is not set
    > # IDE chipset support/bugfixes
    > CONFIG_IDE_GENERIC=y
    > # CONFIG_BLK_DEV_IDEPNP is not set
    > # PCI IDE chipsets support
    > # Other IDE chipsets support
    > # CONFIG_BLK_DEV_IDEDMA is not set
    > # CONFIG_ATA is not set
    > # CONFIG_VIDEO_DEV is not set
    > # CONFIG_VIDEO_MEDIA is not set
    > CONFIG_VIDEO_OUTPUT_CONTROL=m
    > # CONFIG_USB_STORAGE_DATAFAB is not set
    > # CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
    > # CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
    > # Authenticated Encryption with Associated Data
    >


    --
    Regards/Gruss,
    Boris
    --
    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: Linux 2.6.28-rc2 i/o error on /dev/ttyUSB0

    On Wed, 29 Oct 2008 13:28:42 +0100
    Helge Hafting wrote:

    > Alan Cox wrote:
    > >> squarely in the "oops, kref's are screwed up" corner, and you should talk
    > >> to Alan about your particular USB dongle. I bet that bisection would just
    > >> show you one of the kref commits (eg 4a90f09b "tty: usb-serial krefs" or
    > >> maybe 7d7b93c14 "tty: kref the tty driver object").


    Please try:

    tty: Fix USB kref leak

    From: Alan Cox

    When we close we must clear the extra reference we got when we read
    port->tty. Setting the port tty NULL will clear the kref held by the driver
    but not the one we obtained ourselves while doing the lookup.

    Signed-off-by: Alan Cox
    ---

    drivers/usb/serial/usb-serial.c | 1 +
    1 files changed, 1 insertions(+), 0 deletions(-)


    diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
    index 8be3f39..794b5ff 100644
    --- a/drivers/usb/serial/usb-serial.c
    +++ b/drivers/usb/serial/usb-serial.c
    @@ -281,6 +281,7 @@ static void serial_close(struct tty_struct *tty, struct file *filp)
    if (tty->driver_data)
    tty->driver_data = NULL;
    tty_port_tty_set(&port->port, NULL);
    + tty_kref_put(tty);
    }
    }

    --
    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: Linux 2.6.28-rc2 i/o error on /dev/ttyUSB0

    > It looks partially fixed.
    > No more I/O errors, and the gps unit works fine.
    >
    > But look at the attached dmesg file - there are WARNINGs still.


    Thats an unrelated and long long standing bug - the USB serial close paths
    are all racy versus the received URB handlers. The only reason you now
    will occasionally get a warning message is that we bother to actually trap
    the case rather than praying silently it doesn't blow up.

    What actually occurs is that you enter usb-serial:usb_serial_close which
    then drops port->port.count and calls type->close. Somewhere in there new
    data arrives and the ldisc path gets to run. The n_tty path tries to echo
    back bytes to the (closed) port and the WARN triggers.

    Changing the order to clear the port->tty first requires auditing each and
    every USB serial driver close method so isn't planned for this release -
    but its not caused major disasters in the past few years the race has been
    there.

    I can push patches this release for it if Linus particularly wants
    however.

    Alan
    --
    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: Linux 2.6.28-rc2 lost IDE disk on old laptop fixed

    On Thu, Oct 30, 2008 at 03:33:38PM +0100, Borislav Petkov wrote:
    > Hi,
    >
    > On Thu, Oct 30, 2008 at 2:50 PM, Wolfgang Erig wrote:
    > > Hi,
    > >
    > > the kernel 2.6.28-rc2 does not boot on my old laptop.
    > > Panic ... cannot access (301) ... aka /dev/hda1
    > > The previously used version 2.6.27-rc8 runs fine.
    > >
    > > During 'make oldconfig' I saw questions about IDE (or ATA)
    > > but I see no obvious problem with my .config
    > >
    > > Wolfgang
    > >
    > >
    > > $ lspci
    > > 00:00.0 Host bridge: Intel Corporation 430TX - 82439TX MTXC (rev 01)
    > > 00:01.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 01)
    > > 00:01.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)

    >
    > Have you tried compiling your kernel with CONFIG_BLK_DEV_PIIX enabled and
    > CONFIG_IDE_GENERIC disabled?


    tried it with success.
    Thanks Borislav and all for keeping this old laptop running with the
    latest greatest kernel.

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