Linux 2.6.21-rc7

Linux 2.6.21-rc7

[Linus Torvalds]

Since we're still waiting for resolution for some regressions that people 
weren't able to work on last week, there's a new -rc kernel out there. 
Hopefully we'll get them all and I can do 2.6.21-final next weekend or 
so..

The changes from 2.6.21-rc6 are pretty small, and I'm including both the 
shortlog and the diffstat here since they both fit comfortably under the 
kernel mailing list size limits even when combined.

I really don't know what to say that would be more readable and 
informative than the shortlog. The HPET failsafe thing will hopefully 
resolve a few more bootup/resume issues.

Mostly driver fixes, some networking and NFS. Go wild!

		Linus

---
Adam Kropelin (1):
      HID: Do not discard truncated input reports

Alan Stern (1):
      EHCI: fix remote wakeup regression in 2.6.21-rc

Andrew Morton (3):
      x86_64 early quirks: fix early_qrk[] section tag
      i386: irqbalance_disable() section fix
      [PKTGEN]: Add try_to_freeze()

Bjorn Helgaas (1):
      cciss: unregister from SCSI before tearing down device resources

Brice Goglin (3):
      myri10ge: fix management of the firmware 4KB boundary crossing restriction
      myri10ge: more Intel chipsets providing aligned PCIe completions
      myri10ge: update driver version to 1.3.0-1.233

Cliff Brake (1):
      Input: ucb1400 - set up driver's name to show in sysfs

Daniel Drake (2):
      zd1211rw: Reject AL2230S devices
      zd1211rw: Fix E2P_PHY_REG patching

Danny Kukawka (1):
      ide: add "optical" to sysfs "media" attribute

David Brownell (2):
      omap_cf: oops-on-suspend fix
      doc: gpio.txt describes open-drain emulation

David Howells (1):
      FRV: Update the FRV arch MAINTAINER record to get a hit on "grep -i frv"

David S. Miller (7):
      [IPV6]: Revert recent change to rt6_check_dev().
      [TCP]: slow_start_after_idle should influence cwnd validation too
      [SPARC64]: Fix SBUS IOMMU allocation code.
      [SUNRPC]: Make sure on-stack cmsg buffer is properly aligned.
      [SPARC64]: Fix arg passing to compat_sys_ipc().
      [NETFILTER] arp_tables: Fix unaligned accesses.
      [SCSI] QLOGICPTI: Do not unmap DMA unless we actually mapped something.

Divy Le Ray (3):
      cxgb3 - avoid deadlock with mac watchdog
      cxgb3 - MAC watchdog update
      cxgb3 - missing CPL hanler and register setting.

Dmitry Torokhov (1):
      PM: use kobject_name() to access kobject names

Domen Puncer (1):
      [POWERPC] mpc52xx_pic: fix main interrupt masking

Emil Larsson (1):
      USB: Nikon D80 unusual device patch

Erez Zilber (1):
      IB/iser: Don't defer connection failure notification to workqueue

Herbert Xu (1):
      [SC92031]: Fix priv->lock context

Ingo Molnar (2):
      high-res timers: resume fix
      sched: get rid of p->children use in show_task()

Ishimatsu Yasuaki (1):
      [IA64] Fix wrong assumption about irq and vector in msi_ia64.c

James Bottomley (1):
      [SCSI] 3w-xxxx: fix oops caused by incorrect REQUEST_SENSE handling

Jaroslav Kysela (1):
      [NETFILTER]: ipt_CLUSTERIP: fix oops in checkentry function

Jeff Mahoney (1):
      autofs4: fix race in unhashed dentry code

Jerome Borsboom (1):
      [VLAN]: Allow VLAN interface on top of bridge interface

Joy Latten (1):
      [IPSEC] XFRM_USER: kernel panic when large security contexts in ACQUIRE

Larry Finger (2):
      bcm43xx: Fix 802.11b/g scan limits to match regulatory reqs
      bcm43xx: Fix PPC machine checks and match loopback gain specs

Linus Torvalds (2):
      sched.c: Remove unused variable 'relative'
      Linux 2.6.21-rc7

Michael Chan (1):
      [TG3]: Fix crash during tg3_init_one().

Michael S. Tsirkin (1):
      IPoIB/cm: Fix DMA direction typo

Mike Habeck (1):
      [IA64] SGI Altix : fix pcibr_dmamap_ate32() bug

Neil Brown (1):
      md: fix calculation for size of filemap_attr array in md/bitmap

Olaf Kirch (1):
      DVB: dvb-usb-remote - fix oops when changing keymap

Patrick McHardy (6):
      [XFRM]: beet: fix IP option encapsulation
      [XFRM]: beet: use IPOPT_NOP for option padding
      [XFRM]: beet: fix beet mode decapsulation
      [XFRM]: beet: fix IP option decapsulation
      [NET_SCHED]: cls_tcindex: fix compatibility breakage
      [NETFILTER]: ipt_ULOG: use put_unaligned

Randy Dunlap (1):
      fix kernel oops with badly formatted module option

Ravikiran G Thirumalai (1):
      failsafe mechanism to HPET clock calibration

Robert Reif (1):
      [SPARC]: Fix section mismatch warnings in pci.c and pcic.c

Roland McGrath (1):
      [SPARC]: avoid CHILD_MAX and OPEN_MAX constants

Russ Anderson (1):
      [IA64] BTE error timer fix

Stefan Richter (1):
      ieee1394: change deprecation status of dv1394

Stephen Hemminger (5):
      skge: turn carrier off when down
      sky2: turn carrier off when down
      sky2: turn on clocks when doing resume
      sky2: phy workarounds for Yukon EC-U A1
      skge: fix wake on lan

Steve Wise (1):
      RDMA/cxgb3: Add set_tcb_rpl_handler

Stuart Hayes (1):
      ide: ugly messages trying to open CD drive with no media present

Suleiman Souhlal (1):
      ide: correctly prevent IDE timer expiry function to run if request was already handled

Tejun Heo (1):
      irq-devres: fix failure path of devm_request_irq()

Timo Savola (1):
      fuse: validate rootmode mount option

Tom "spot" Callaway (1):
      [SPARC64]: Fix inline directive in pci_iommu.c

Trond Myklebust (4):
      NFS: Fix an Oops in nfs_setattr()
      NFS: Fix two bugs in the O_DIRECT write code
      NFS: Ensure PG_writeback is cleared when writeback fails
      NFS: Fix a list corruption problem

Venki Pallipadi (1):
      [IA64] Fix CPU freq displayed in /proc/cpuinfo

Vitaly Bordug (3):
      [PPC] MPC8272 ADS compile fixed, defconfig refreshed.
      [PPC] Fix compilation and linking errors of mpc885ads build.
      [PPC] Fix compilation and linking errors of mpc86xads build.

Vladimir Saveliev (1):
      reiserfs: fix key decrementing

Wang Zhenyu (2):
      [AGPGART] intel_agp: PCI id update for Intel 965GM
      [AGPGART] intel_agp: fix G965 GTT size detect

Wu, Bryan (1):
      nommu: fix bug ip_conntrack does not work on nommu

YOSHIFUJI Hideaki (1):
      [IPV6] SNMP: Fix {In,Out}NoRoutes statistics.

Zachary Amsden (2):
      Proper fix for highmem kmap_atomic functions for VMI for 2.6.21
      Fix VMI relocation processing logic error

---
 Documentation/ABI/obsolete/dv1394            |    9 +
 Documentation/feature-removal-schedule.txt   |   11 -
 Documentation/gpio.txt                       |   31 ++-
 MAINTAINERS                                  |    2 +-
 Makefile                                     |    2 +-
 arch/i386/kernel/io_apic.c                   |    2 +-
 arch/i386/kernel/vmi.c                       |   32 ++-
 arch/i386/mm/highmem.c                       |    2 +
 arch/ia64/kernel/msi_ia64.c                  |    4 +-
 arch/ia64/kernel/setup.c                     |    2 +-
 arch/ia64/sn/kernel/bte_error.c              |    6 +-
 arch/ia64/sn/pci/pcibr/pcibr_dma.c           |    8 +-
 arch/powerpc/platforms/52xx/mpc52xx_pic.c    |    4 +-
 arch/ppc/8xx_io/commproc.c                   |   26 ++
 arch/ppc/configs/ads8272_defconfig           |  592 ++++++++++++++++++++------
 arch/ppc/platforms/mpc8272ads_setup.c        |   17 +-
 arch/ppc/platforms/mpc866ads_setup.c         |   17 +-
 arch/ppc/platforms/mpc885ads_setup.c         |   20 +-
 arch/sparc/kernel/pcic.c                     |    4 +-
 arch/sparc/kernel/sys_sunos.c                |    4 +-
 arch/sparc64/kernel/pci.c                    |    4 +-
 arch/sparc64/kernel/pci_iommu.c              |    2 +-
 arch/sparc64/kernel/sbus.c                   |  560 ++++++++++--------------
 arch/sparc64/kernel/sys32.S                  |    1 -
 arch/sparc64/kernel/sys_sunos32.c            |    4 +-
 arch/sparc64/kernel/systbls.S                |    2 +-
 arch/sparc64/solaris/misc.c                  |    6 +-
 arch/x86_64/kernel/early-quirks.c            |    2 +-
 arch/x86_64/kernel/hpet.c                    |    9 +-
 drivers/base/power/main.c                    |    6 +-
 drivers/block/cciss.c                        |   35 +-
 drivers/char/agp/intel-agp.c                 |   17 +-
 drivers/hid/hid-core.c                       |    2 +-
 drivers/ide/ide-cd.c                         |    9 +
 drivers/ide/ide-io.c                         |    6 +-
 drivers/ide/ide-iops.c                       |    2 +
 drivers/ide/ide.c                            |    2 +
 drivers/ieee1394/Kconfig                     |    6 +-
 drivers/ieee1394/dv1394.c                    |    4 +-
 drivers/infiniband/hw/cxgb3/iwch_cm.c        |   12 +
 drivers/infiniband/ulp/ipoib/ipoib_cm.c      |    2 +-
 drivers/infiniband/ulp/iser/iscsi_iser.h     |    1 -
 drivers/infiniband/ulp/iser/iser_verbs.c     |   40 +-
 drivers/input/touchscreen/ucb1400_ts.c       |    1 +
 drivers/md/bitmap.c                          |    4 +-
 drivers/media/dvb/dvb-usb/dvb-usb-remote.c   |    2 -
 drivers/net/cxgb3/common.h                   |    7 +-
 drivers/net/cxgb3/cxgb3_main.c               |   16 +-
 drivers/net/cxgb3/cxgb3_offload.c            |   14 +-
 drivers/net/cxgb3/regs.h                     |    6 +
 drivers/net/cxgb3/xgmac.c                    |  107 ++++--
 drivers/net/myri10ge/myri10ge.c              |   37 ++-
 drivers/net/sc92031.c                        |   20 +-
 drivers/net/skge.c                           |   93 +++--
 drivers/net/sky2.c                           |   12 +-
 drivers/net/tg3.c                            |    6 +-
 drivers/net/wireless/bcm43xx/bcm43xx_main.c  |   20 +-
 drivers/net/wireless/bcm43xx/bcm43xx_phy.c   |   57 ++--
 drivers/net/wireless/zd1211rw/zd_chip.c      |   12 +-
 drivers/net/wireless/zd1211rw/zd_chip.h      |    4 +-
 drivers/net/wireless/zd1211rw/zd_rf_al2230.c |    6 +
 drivers/pcmcia/omap_cf.c                     |   41 ++-
 drivers/scsi/3w-xxxx.c                       |   11 +-
 drivers/scsi/qlogicpti.c                     |    2 +-
 drivers/usb/host/ehci-hcd.c                  |    1 +
 drivers/usb/storage/unusual_devs.h           |    7 +
 fs/autofs4/root.c                            |    6 +-
 fs/fuse/dir.c                                |    5 +-
 fs/fuse/fuse_i.h                             |    5 +
 fs/fuse/inode.c                              |    2 +
 fs/nfs/dir.c                                 |    3 +-
 fs/nfs/direct.c                              |   11 +-
 fs/nfs/inode.c                               |    6 +-
 fs/nfs/write.c                               |   22 +-
 fs/reiserfs/item_ops.c                       |    2 +-
 include/asm-generic/pgtable.h                |    2 +
 include/asm-i386/paravirt.h                  |    3 +
 include/asm-ia64/sn/pcibr_provider.h         |    5 +-
 include/linux/hrtimer.h                      |    3 +
 include/linux/ide.h                          |    2 +
 include/linux/nfs_page.h                     |    1 -
 kernel/hrtimer.c                             |   12 +
 kernel/irq/devres.c                          |    2 +-
 kernel/params.c                              |    4 +
 kernel/sched.c                               |   36 +--
 kernel/timer.c                               |    2 +-
 mm/nommu.c                                   |    1 +
 net/8021q/vlan_dev.c                         |    3 +
 net/core/pktgen.c                            |    3 +
 net/ipv4/netfilter/arp_tables.c              |   10 +-
 net/ipv4/netfilter/ipt_CLUSTERIP.c           |    2 -
 net/ipv4/netfilter/ipt_ULOG.c                |    7 +-
 net/ipv4/tcp_output.c                        |    3 +-
 net/ipv4/xfrm4_mode_beet.c                   |   26 +-
 net/ipv6/route.c                             |   48 +-
 net/sched/cls_tcindex.c                      |    4 +-
 net/sunrpc/svcsock.c                         |   16 +-
 net/xfrm/xfrm_user.c                         |    7 +-
 98 files changed, 1415 insertions(+), 864 deletions(-)
 create mode 100644 Documentation/ABI/obsolete/dv1394

[1/2] 2.6.21-rc7: known regressions

[Adrian Bunk]

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : snd_hda_intel doesn't work with ASUS M2V mainboard
References : http://bugzilla.kernel.org/show_bug.cgi?id=8273
Submitter  : Hans-Georg Rist <hg.rist@web.de>
Status     : unknown


Subject    : snd_intel8x0: divide error: 0000
References : http://lkml.org/lkml/2007/3/5/252
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Status     : unknown


Subject    : ali_pata: boot from CD fails
References : http://lkml.org/lkml/2007/3/31/160
Submitter  : Stephen Clark <Stephen.Clark@seclark.us>
Status     : unknown


Subject    : kernels fail to boot with drives on ATIIXP controller
             (ACPI/IRQ related)
References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621
             http://lkml.org/lkml/2007/3/4/257
Submitter  : Michal Jaegermann <michal@ellpspace.math.ualberta.ca>
Status     : unknown


Subject    : boot failure: rtl8139: exception in interrupt routine
References : http://lkml.org/lkml/2007/3/31/160
Submitter  : Stephen Clark <Stephen.Clark@seclark.us>
Status     : unknown


Subject    : laptops with e1000: lockups
References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603
Submitter  : Dave Jones <davej@redhat.com>
Handled-By : Jesse Brandeburg <jesse.brandeburg@intel.com>
Status     : problem is being debugged


Subject    : forcedeth: interface hangs under load
References : http://lkml.org/lkml/2007/4/3/39
             http://www.spinics.net/lists/netdev/msg28981.html
Submitter  : Ingo Molnar <mingo@elte.hu>
Handled-By : Ingo Molnar <mingo@elte.hu>
             Ayaz Abdulla <aabdulla@nvidia.com>
             David Miller <davem@davemloft.net>
Status     : problem is being debugged


Subject    : hal daemon crashes after pulling a USB serial device
References : http://www.opensubscriber.com/message/linux-usb-devel@lists.sourceforge.net/6369800.html
Submitter  : Andi Kleen <ak@suse.de>
Handled-By : Oliver Neukum <oneukum@suse.de>
Status     : problem is being debugged


Subject    : Oops when changing USB DVB-T adapter
References : http://lkml.org/lkml/2007/3/9/212
             http://lkml.org/lkml/2007/4/5/154
Submitter  : CIJOML <cijoml@volny.cz>
Handled-By : Markus Rechberger <markus.rechberger@amd.com>
Status     : patches available

Re: [1/2] 2.6.21-rc7: known regressions

[Michal Jaegermann]

On Mon, Apr 16, 2007 at 02:37:14AM +0200, Adrian Bunk wrote:
> 
> Subject    : kernels fail to boot with drives on ATIIXP controller
>              (ACPI/IRQ related)
> References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621
c              http://lkml.org/lkml/2007/3/4/257
> Submitter  : Michal Jaegermann <michal@ellpspace.math.ualberta.ca>
> Status     : unknown

Sigh!  Again!  AFAICT the current "rc" kernels should boot
using 'pata_atiixp' driver _provided_ I will use 'acpi=off'.
At least on the hardware in question.  More details at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621#c10

OTOH I mentioned few times that another machine, which want
to use 'pata_via' fails to read _anything_ from a disk.  See
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234650
Mentioned there 2.6.20-1.3054.fc7 really corresponds to
2.6.21-rc6-git1 (AFAICT).

   Michal

Re: [1/2] 2.6.21-rc7: known regressions

[Chuck Ebbert]

Adrian Bunk wrote:

> This email lists some known regressions in Linus' tree compared to 2.6.20.
> 
> Subject    : snd_intel8x0: divide error: 0000
> References : http://lkml.org/lkml/2007/3/5/252
> Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
> Status     : unknown
> 

Oops is in sound/pci/intel8x0.c::snd_intel8x0_update(), part of
the interrupt handler:

Line 751:

        ichdev->position += step * ichdev->fragsize1;
        if (! chip->in_measurement)
                ichdev->position %= ichdev->size;

ichdev->size is 0. Interrupt happened upon request_irq().

Does chip->in_measurement need to be reset because this is a
crashdump kernel?

Re: [1/2] 2.6.21-rc7: known regressions

[Takashi Iwai]

At Mon, 16 Apr 2007 17:44:57 -0400,
Chuck Ebbert wrote:
> 
> Adrian Bunk wrote:
> 
> > This email lists some known regressions in Linus' tree compared to 2.6.20.
> > 
> > Subject    : snd_intel8x0: divide error: 0000
> > References : http://lkml.org/lkml/2007/3/5/252
> > Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
> > Status     : unknown
> > 
> 
> Oops is in sound/pci/intel8x0.c::snd_intel8x0_update(), part of
> the interrupt handler:
> 
> Line 751:
> 
>         ichdev->position += step * ichdev->fragsize1;
>         if (! chip->in_measurement)
>                 ichdev->position %= ichdev->size;
> 
> ichdev->size is 0. Interrupt happened upon request_irq().
> 
> Does chip->in_measurement need to be reset because this is a
> crashdump kernel?

No, the problem seems to be the timing of request_irq() and the
initialization of hardware.  The irq handler shouldn't get called
there at all.

How about the patch below?


Takashi

diff -r 4b6ed4ef4820 sound/pci/intel8x0.c
--- a/sound/pci/intel8x0.c	Mon Apr 16 19:20:17 2007 +0200
+++ b/sound/pci/intel8x0.c	Tue Apr 17 11:02:49 2007 +0200
@@ -2493,6 +2493,7 @@ static int intel8x0_resume(struct pci_de
 		return -EIO;
 	}
 	pci_set_master(pci);
+	snd_intel8x0_chip_init(chip, 0);
 	if (request_irq(pci->irq, snd_intel8x0_interrupt,
 			IRQF_SHARED, card->shortname, chip)) {
 		printk(KERN_ERR "intel8x0: unable to grab IRQ %d, "
@@ -2502,7 +2503,6 @@ static int intel8x0_resume(struct pci_de
 	}
 	chip->irq = pci->irq;
 	synchronize_irq(chip->irq);
-	snd_intel8x0_chip_init(chip, 0);
 
 	/* re-initialize mixer stuff */
 	if (chip->device_type == DEVICE_INTEL_ICH4 && !spdif_aclink) {
@@ -2862,16 +2862,7 @@ static int __devinit snd_intel8x0_create
 		ICH_REG_ALI_INTERRUPTSR : ICH_REG_GLOB_STA;
 	chip->int_sta_mask = int_sta_masks;
 
-	/* request irq after initializaing int_sta_mask, etc */
-	if (request_irq(pci->irq, snd_intel8x0_interrupt,
-			IRQF_SHARED, card->shortname, chip)) {
-		snd_printk(KERN_ERR "unable to grab IRQ %d\n", pci->irq);
-		snd_intel8x0_free(chip);
-		return -EBUSY;
-	}
-	chip->irq = pci->irq;
 	pci_set_master(pci);
-	synchronize_irq(chip->irq);
 
 	switch(chip->device_type) {
 	case DEVICE_INTEL_ICH4:
@@ -2900,6 +2891,15 @@ static int __devinit snd_intel8x0_create
 		snd_intel8x0_free(chip);
 		return err;
 	}
+
+	/* request irq after initializaing int_sta_mask, etc */
+	if (request_irq(pci->irq, snd_intel8x0_interrupt,
+			IRQF_SHARED, card->shortname, chip)) {
+		snd_printk(KERN_ERR "unable to grab IRQ %d\n", pci->irq);
+		snd_intel8x0_free(chip);
+		return -EBUSY;
+	}
+	chip->irq = pci->irq;
 
 	if ((err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, &ops)) < 0) {
 		snd_intel8x0_free(chip);

Re: [1/2] 2.6.21-rc7: known regressions

[Michal Piotrowski]

Hi Takashi,

Takashi Iwai napisał(a):
> At Mon, 16 Apr 2007 17:44:57 -0400,
> Chuck Ebbert wrote:
>> Adrian Bunk wrote:
>>
>>> This email lists some known regressions in Linus' tree compared to 2.6.20.
>>>
>>> Subject    : snd_intel8x0: divide error: 0000
>>> References : http://lkml.org/lkml/2007/3/5/252
>>> Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
>>> Status     : unknown
>>>
>> Oops is in sound/pci/intel8x0.c::snd_intel8x0_update(), part of
>> the interrupt handler:
>>
>> Line 751:
>>
>>         ichdev->position += step * ichdev->fragsize1;
>>         if (! chip->in_measurement)
>>                 ichdev->position %= ichdev->size;
>>
>> ichdev->size is 0. Interrupt happened upon request_irq().
>>
>> Does chip->in_measurement need to be reset because this is a
>> crashdump kernel?
> 
> No, the problem seems to be the timing of request_irq() and the
> initialization of hardware.  The irq handler shouldn't get called
> there at all.
> 
> How about the patch below?
> 
> 
> Takashi
> 
> diff -r 4b6ed4ef4820 sound/pci/intel8x0.c
> --- a/sound/pci/intel8x0.c	Mon Apr 16 19:20:17 2007 +0200
> +++ b/sound/pci/intel8x0.c	Tue Apr 17 11:02:49 2007 +0200
> @@ -2493,6 +2493,7 @@ static int intel8x0_resume(struct pci_de
>  		return -EIO;
>  	}
>  	pci_set_master(pci);
> +	snd_intel8x0_chip_init(chip, 0);
>  	if (request_irq(pci->irq, snd_intel8x0_interrupt,
>  			IRQF_SHARED, card->shortname, chip)) {
>  		printk(KERN_ERR "intel8x0: unable to grab IRQ %d, "
> @@ -2502,7 +2503,6 @@ static int intel8x0_resume(struct pci_de
>  	}
>  	chip->irq = pci->irq;
>  	synchronize_irq(chip->irq);
> -	snd_intel8x0_chip_init(chip, 0);
>  
>  	/* re-initialize mixer stuff */
>  	if (chip->device_type == DEVICE_INTEL_ICH4 && !spdif_aclink) {
> @@ -2862,16 +2862,7 @@ static int __devinit snd_intel8x0_create
>  		ICH_REG_ALI_INTERRUPTSR : ICH_REG_GLOB_STA;
>  	chip->int_sta_mask = int_sta_masks;
>  
> -	/* request irq after initializaing int_sta_mask, etc */
> -	if (request_irq(pci->irq, snd_intel8x0_interrupt,
> -			IRQF_SHARED, card->shortname, chip)) {
> -		snd_printk(KERN_ERR "unable to grab IRQ %d\n", pci->irq);
> -		snd_intel8x0_free(chip);
> -		return -EBUSY;
> -	}
> -	chip->irq = pci->irq;
>  	pci_set_master(pci);
> -	synchronize_irq(chip->irq);
>  
>  	switch(chip->device_type) {
>  	case DEVICE_INTEL_ICH4:
> @@ -2900,6 +2891,15 @@ static int __devinit snd_intel8x0_create
>  		snd_intel8x0_free(chip);
>  		return err;
>  	}
> +
> +	/* request irq after initializaing int_sta_mask, etc */
> +	if (request_irq(pci->irq, snd_intel8x0_interrupt,
> +			IRQF_SHARED, card->shortname, chip)) {
> +		snd_printk(KERN_ERR "unable to grab IRQ %d\n", pci->irq);
> +		snd_intel8x0_free(chip);
> +		return -EBUSY;
> +	}
> +	chip->irq = pci->irq;
>  
>  	if ((err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, &ops)) < 0) {
>  		snd_intel8x0_free(chip);
> 

This patch solves the problem for me. Thanks!

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)

Re: [1/2] 2.6.21-rc7: known regressions

[Takashi Iwai]

At Thu, 19 Apr 2007 22:03:16 +0200,
Michal Piotrowski wrote:
> 
> Hi Takashi,
> 
> Takashi Iwai napisał(a):
> > At Mon, 16 Apr 2007 17:44:57 -0400,
> > Chuck Ebbert wrote:
> >> Adrian Bunk wrote:
> >>
> >>> This email lists some known regressions in Linus' tree compared to 2.6.20.
> >>>
> >>> Subject    : snd_intel8x0: divide error: 0000
> >>> References : http://lkml.org/lkml/2007/3/5/252
> >>> Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
> >>> Status     : unknown
> >>>
> >> Oops is in sound/pci/intel8x0.c::snd_intel8x0_update(), part of
> >> the interrupt handler:
> >>
> >> Line 751:
> >>
> >>         ichdev->position += step * ichdev->fragsize1;
> >>         if (! chip->in_measurement)
> >>                 ichdev->position %= ichdev->size;
> >>
> >> ichdev->size is 0. Interrupt happened upon request_irq().
> >>
> >> Does chip->in_measurement need to be reset because this is a
> >> crashdump kernel?
> > 
> > No, the problem seems to be the timing of request_irq() and the
> > initialization of hardware.  The irq handler shouldn't get called
> > there at all.
> > 
> > How about the patch below?
(snip)
> 
> This patch solves the problem for me. Thanks!

Good to hear!  I forgot the patch description and sign-off, so here it
is again:


[PATCH] ALSA: intel8x0 - Fix Oops in crash kernel

When intel8x0 driver is loaded in the crash kernel, it gets Oops
occasionally.  This is because the irq handler gets called before
the proper hardware initialization.  Now defer it after
snd_intel8x0_chip_init().

(reference: http://lkml.org/lkml/2007/3/5/252)

Signed-off-by: Takashi Iwai <tiwai@suse.de>

---
 sound/pci/intel8x0.c |   20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff -r 202af90f8e68 -r a3f021fd290c sound/pci/intel8x0.c
--- a/sound/pci/intel8x0.c	Thu Apr 19 15:22:56 2007 +0200
+++ b/sound/pci/intel8x0.c	Fri Apr 20 12:30:28 2007 +0200
@@ -2493,6 +2493,7 @@ static int intel8x0_resume(struct pci_de
 		return -EIO;
 	}
 	pci_set_master(pci);
+	snd_intel8x0_chip_init(chip, 0);
 	if (request_irq(pci->irq, snd_intel8x0_interrupt,
 			IRQF_SHARED, card->shortname, chip)) {
 		printk(KERN_ERR "intel8x0: unable to grab IRQ %d, "
@@ -2502,7 +2503,6 @@ static int intel8x0_resume(struct pci_de
 	}
 	chip->irq = pci->irq;
 	synchronize_irq(chip->irq);
-	snd_intel8x0_chip_init(chip, 0);
 
 	/* re-initialize mixer stuff */
 	if (chip->device_type == DEVICE_INTEL_ICH4 && !spdif_aclink) {
@@ -2862,16 +2862,7 @@ static int __devinit snd_intel8x0_create
 		ICH_REG_ALI_INTERRUPTSR : ICH_REG_GLOB_STA;
 	chip->int_sta_mask = int_sta_masks;
 
-	/* request irq after initializaing int_sta_mask, etc */
-	if (request_irq(pci->irq, snd_intel8x0_interrupt,
-			IRQF_SHARED, card->shortname, chip)) {
-		snd_printk(KERN_ERR "unable to grab IRQ %d\n", pci->irq);
-		snd_intel8x0_free(chip);
-		return -EBUSY;
-	}
-	chip->irq = pci->irq;
 	pci_set_master(pci);
-	synchronize_irq(chip->irq);
 
 	switch(chip->device_type) {
 	case DEVICE_INTEL_ICH4:
@@ -2900,6 +2891,15 @@ static int __devinit snd_intel8x0_create
 		snd_intel8x0_free(chip);
 		return err;
 	}
+
+	/* request irq after initializaing int_sta_mask, etc */
+	if (request_irq(pci->irq, snd_intel8x0_interrupt,
+			IRQF_SHARED, card->shortname, chip)) {
+		snd_printk(KERN_ERR "unable to grab IRQ %d\n", pci->irq);
+		snd_intel8x0_free(chip);
+		return -EBUSY;
+	}
+	chip->irq = pci->irq;
 
 	if ((err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, &ops)) < 0) {
 		snd_intel8x0_free(chip);

Re: [1/2] 2.6.21-rc7: known regressions

[Andrew Morton]

On Fri, 20 Apr 2007 12:34:18 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> Good to hear!  I forgot the patch description and sign-off, so here it
> is again:
> 
> 
> [PATCH] ALSA: intel8x0 - Fix Oops in crash kernel
> 
> When intel8x0 driver is loaded in the crash kernel, it gets Oops
> occasionally.  This is because the irq handler gets called before
> the proper hardware initialization.  Now defer it after
> snd_intel8x0_chip_init().

Neat, thanks.

Do we think this is safe enough and important enough for 2.6.21?
And if so, do you want me to merge it?

Re: [1/2] 2.6.21-rc7: known regressions

[Takashi Iwai]

At Fri, 20 Apr 2007 11:18:07 -0700,
Andrew Morton wrote:
> 
> On Fri, 20 Apr 2007 12:34:18 +0200
> Takashi Iwai <tiwai@suse.de> wrote:
> 
> > Good to hear!  I forgot the patch description and sign-off, so here it
> > is again:
> > 
> > 
> > [PATCH] ALSA: intel8x0 - Fix Oops in crash kernel
> > 
> > When intel8x0 driver is loaded in the crash kernel, it gets Oops
> > occasionally.  This is because the irq handler gets called before
> > the proper hardware initialization.  Now defer it after
> > snd_intel8x0_chip_init().
> 
> Neat, thanks.
> 
> Do we think this is safe enough and important enough for 2.6.21?
> And if so, do you want me to merge it?

It should be safe (as I already merged ALSA tree for 2.6.22), but I'd
like to test the following before merging 2.6.21:
- suspend/resume works
- no severe problem even if request_irq() fails
I'll check this in this weekend, so let's hold on.


Takashi

Re: [1/2] 2.6.21-rc7: known regressions

[Takashi Iwai]

At Fri, 20 Apr 2007 20:26:10 +0200,
I wrote:
> 
> At Fri, 20 Apr 2007 11:18:07 -0700,
> Andrew Morton wrote:
> > 
> > On Fri, 20 Apr 2007 12:34:18 +0200
> > Takashi Iwai <tiwai@suse.de> wrote:
> > 
> > > Good to hear!  I forgot the patch description and sign-off, so here it
> > > is again:
> > > 
> > > 
> > > [PATCH] ALSA: intel8x0 - Fix Oops in crash kernel
> > > 
> > > When intel8x0 driver is loaded in the crash kernel, it gets Oops
> > > occasionally.  This is because the irq handler gets called before
> > > the proper hardware initialization.  Now defer it after
> > > snd_intel8x0_chip_init().
> > 
> > Neat, thanks.
> > 
> > Do we think this is safe enough and important enough for 2.6.21?
> > And if so, do you want me to merge it?
> 
> It should be safe (as I already merged ALSA tree for 2.6.22), but I'd
> like to test the following before merging 2.6.21:
> - suspend/resume works
> - no severe problem even if request_irq() fails
> I'll check this in this weekend, so let's hold on.

Both seem OK as far as I tested.

So, feel free to push it to 2.6.21 if it's still allowed.
Otherwise I'll queue it up to stable tree later.


Thanks,

Takashi

RE: [1/2] 2.6.21-rc7: known regressions

[Brandeburg, Jesse]

Adrian Bunk wrote:
> Subject    : laptops with e1000: lockups
> References :
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 
> Submitter  : Dave Jones <davej@redhat.com>
> Handled-By : Jesse Brandeburg <jesse.brandeburg@intel.com>
> Status     : problem is being debugged

this is being actively debugged, here is what we have so far:
o v2.6.20: crashes during boot, unless noacpi and nousb bootparams used
o v2.6.21-rc6: some userspace issue, crashes just after root mount
without init=/bin/bash
o v2.6.2X: serial console in docking station spews goo at all speeds
with console=ttyS0,bbbbn8 . work continues on this, as we don't know if
there are kernel panic messages during the hard lock.
o fedora 7 test kernel 2948: boots okay, have been using this as only
truly working kernel on this machine.

one reproduction of the problem was had with scp -l 5000 <file> <remote>
when linked at 100Mb/Full.  Tried probably 20 other times same test with
no repro, ugh.

Otherwise, slogging through continues.  We are actively working on this
in case it *is* an e1000 issue.  Right now the repro is so unlikely we
could hardly tell if we fixed it.

Jesse

PS .config available on request

Re: [1/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Mon, Apr 16, 2007 at 05:14:40PM -0700, Brandeburg, Jesse wrote:
 > Adrian Bunk wrote:
 > > Subject    : laptops with e1000: lockups
 > > References :
 > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 
 > > Submitter  : Dave Jones <davej@redhat.com>
 > > Handled-By : Jesse Brandeburg <jesse.brandeburg@intel.com>
 > > Status     : problem is being debugged
 > 
 > this is being actively debugged, here is what we have so far:
 > o v2.6.20: crashes during boot, unless noacpi and nousb bootparams used
 > o v2.6.21-rc6: some userspace issue, crashes just after root mount
 > without init=/bin/bash
 > o v2.6.2X: serial console in docking station spews goo at all speeds
 > with console=ttyS0,bbbbn8 . work continues on this, as we don't know if
 > there are kernel panic messages during the hard lock.
 > o fedora 7 test kernel 2948: boots okay, have been using this as only
 > truly working kernel on this machine.
 > 
 > one reproduction of the problem was had with scp -l 5000 <file> <remote>
 > when linked at 100Mb/Full.  Tried probably 20 other times same test with
 > no repro, ugh.
 > 
 > Otherwise, slogging through continues.  We are actively working on this
 > in case it *is* an e1000 issue.  Right now the repro is so unlikely we
 > could hardly tell if we fixed it.

FWIW, I can reproduce this pretty much ondemand, on 100M through
the ethernet port on a netgear wireless AP.
A number of our Fedora7 testers are also able to easily reproduce this.
To isolate e1000, for tomorrows test build I've reverted e1000 to
the same code that was in 2.6.20.  If that works out without causing
hangs, I'll try and narrow down further which of the dozen csets
is responsible.

	Dave

-- 
http://www.codemonkey.org.uk

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: [1/2] 2.6.21-rc7: known regressions

[Jeff Garzik]

Dave Jones wrote:
> On Mon, Apr 16, 2007 at 05:14:40PM -0700, Brandeburg, Jesse wrote:
>  > Adrian Bunk wrote:
>  > > Subject    : laptops with e1000: lockups
>  > > References :
>  > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 
>  > > Submitter  : Dave Jones <davej@redhat.com>
>  > > Handled-By : Jesse Brandeburg <jesse.brandeburg@intel.com>
>  > > Status     : problem is being debugged
>  > 
>  > this is being actively debugged, here is what we have so far:
>  > o v2.6.20: crashes during boot, unless noacpi and nousb bootparams used
>  > o v2.6.21-rc6: some userspace issue, crashes just after root mount
>  > without init=/bin/bash
>  > o v2.6.2X: serial console in docking station spews goo at all speeds
>  > with console=ttyS0,bbbbn8 . work continues on this, as we don't know if
>  > there are kernel panic messages during the hard lock.
>  > o fedora 7 test kernel 2948: boots okay, have been using this as only
>  > truly working kernel on this machine.
>  > 
>  > one reproduction of the problem was had with scp -l 5000 <file> <remote>
>  > when linked at 100Mb/Full.  Tried probably 20 other times same test with
>  > no repro, ugh.
>  > 
>  > Otherwise, slogging through continues.  We are actively working on this
>  > in case it *is* an e1000 issue.  Right now the repro is so unlikely we
>  > could hardly tell if we fixed it.
> 
> FWIW, I can reproduce this pretty much ondemand, on 100M through
> the ethernet port on a netgear wireless AP.
> A number of our Fedora7 testers are also able to easily reproduce this.
> To isolate e1000, for tomorrows test build I've reverted e1000 to
> the same code that was in 2.6.20.  If that works out without causing
> hangs, I'll try and narrow down further which of the dozen csets
> is responsible.

Also, there are e1000 fixes in -mm.  At the time (rc2? rc3?) I felt it 
was best to get that into -mm for testing, rather than fast-tracking it 
to 2.6.21.

But hey, see if they help.

It's the netdev-2.6.git#e1000-fixes branch, if you are git-ified.  I was 
going to push them first thing 2.6.22.

	Jeff

[2/2] 2.6.21-rc7: known regressions

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
Status     : unknown


Subject    : ThinkPad X60: resume no longer works  (PCI related?)
             workaround: booting with "hpet=disable"
References : http://lkml.org/lkml/2007/3/13/3
Submitter  : Dave Jones <davej@redhat.com>
             Jeremy Fitzhardinge <jeremy@goop.org>
Caused-By  : PCI merge
             commit 78149df6d565c36675463352d0bfe0000b02b7a7
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
             Rafael J. Wysocki <rjw@sisk.pl>
Status     : unknown


Subject    : suspend to disk works only once
References : http://lkml.org/lkml/2007/4/13/240
Submitter  : Tobias Diedrich <ranma+kernel@tdiedrich.de>
Caused-By  : Rafael J. Wysocki <rjw@sisk.pl>
             commit ed746e3b18f4df18afa3763155972c5835f284c5
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
             Dmitry Torokhov <dtor@insightbb.com>
             David Brownell <david-b@pacbell.net>
Status     : problem is being debugged


Subject    : resume from RAM corrupts vesafb console
References : http://lkml.org/lkml/2007/3/26/76
             http://lkml.org/lkml/2007/4/13/313
Submitter  : Marcus Better <marcus@better.se>
Handled-By : Pavel Machek <pavel@ucw.cz>
             Antonino A. Daplas <adaplas@gmail.com>
Status     : problem is being debugged

[2/2] 2.6.21-rc7: known regressions

[Adrian Bunk]

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
Status     : unknown


Subject    : ThinkPad X60: resume no longer works  (PCI related?)
             workaround: booting with "hpet=disable"
References : http://lkml.org/lkml/2007/3/13/3
Submitter  : Dave Jones <davej@redhat.com>
             Jeremy Fitzhardinge <jeremy@goop.org>
Caused-By  : PCI merge
             commit 78149df6d565c36675463352d0bfe0000b02b7a7
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
             Rafael J. Wysocki <rjw@sisk.pl>
Status     : unknown


Subject    : suspend to disk works only once
References : http://lkml.org/lkml/2007/4/13/240
Submitter  : Tobias Diedrich <ranma+kernel@tdiedrich.de>
Caused-By  : Rafael J. Wysocki <rjw@sisk.pl>
             commit ed746e3b18f4df18afa3763155972c5835f284c5
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
             Dmitry Torokhov <dtor@insightbb.com>
             David Brownell <david-b@pacbell.net>
Status     : problem is being debugged


Subject    : resume from RAM corrupts vesafb console
References : http://lkml.org/lkml/2007/3/26/76
             http://lkml.org/lkml/2007/4/13/313
Submitter  : Marcus Better <marcus@better.se>
Handled-By : Pavel Machek <pavel@ucw.cz>
             Antonino A. Daplas <adaplas@gmail.com>
Status     : problem is being debugged

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Mon, Apr 16, 2007 at 02:37:23AM +0200, Adrian Bunk wrote:

 > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
 >              workaround: booting with "hpet=disable"
 > References : http://lkml.org/lkml/2007/3/13/3
 > Submitter  : Dave Jones <davej@redhat.com>
 >              Jeremy Fitzhardinge <jeremy@goop.org>
 > Caused-By  : PCI merge
 >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
 > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
 >              Rafael J. Wysocki <rjw@sisk.pl>
 > Status     : unknown

note that this workaround doesn't seem to work in all cases.
Mine may a slightly different model (I have the tablet version)
but disabling hpet shows the same regression.
I've been fighting Eric's USB debug cable code in the hope
of getting _something_ useful out of it other than a black screen,
but I've been getting nowhere with it.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Mon, Apr 16, 2007 at 02:37:23AM +0200, Adrian Bunk wrote:

 > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
 >              workaround: booting with "hpet=disable"
 > References : http://lkml.org/lkml/2007/3/13/3
 > Submitter  : Dave Jones <davej@redhat.com>
 >              Jeremy Fitzhardinge <jeremy@goop.org>
 > Caused-By  : PCI merge
 >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
 > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
 >              Rafael J. Wysocki <rjw@sisk.pl>
 > Status     : unknown

note that this workaround doesn't seem to work in all cases.
Mine may a slightly different model (I have the tablet version)
but disabling hpet shows the same regression.
I've been fighting Eric's USB debug cable code in the hope
of getting _something_ useful out of it other than a black screen,
but I've been getting nowhere with it.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Adrian Bunk]

On Sun, Apr 15, 2007 at 08:54:46PM -0400, Dave Jones wrote:
> On Mon, Apr 16, 2007 at 02:37:23AM +0200, Adrian Bunk wrote:
> 
>  > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
>  >              workaround: booting with "hpet=disable"
>  > References : http://lkml.org/lkml/2007/3/13/3
>  > Submitter  : Dave Jones <davej@redhat.com>
>  >              Jeremy Fitzhardinge <jeremy@goop.org>
>  > Caused-By  : PCI merge
>  >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
>  > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
>  >              Rafael J. Wysocki <rjw@sisk.pl>
>  > Status     : unknown
> 
> note that this workaround doesn't seem to work in all cases.
> Mine may a slightly different model (I have the tablet version)
> but disabling hpet shows the same regression.
> I've been fighting Eric's USB debug cable code in the hope
> of getting _something_ useful out of it other than a black screen,
> but I've been getting nowhere with it.

I'm not sure why I thought you two ran into the same regression.

So "hpet=disable" worked for Jeremy but not for you, IOW: you two were 
running into different regressions?

@Jeremy:
If this is true, is your HPET related related regression still present 
in -rc7?

> 	Dave

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2/2] 2.6.21-rc7: known regressions

[Jeremy Fitzhardinge]

Adrian Bunk wrote:
> I'm not sure why I thought you two ran into the same regression.
>
> So "hpet=disable" worked for Jeremy but not for you, IOW: you two were 
> running into different regressions?
>
> @Jeremy:
> If this is true, is your HPET related related regression still present 
> in -rc7?

I need to recheck, but when I tried -rc6, I was still having resume
problems but hpet=disabled didn't help.  So I definitely think there are
multiple bugs with the same symtoms.  I haven't tried -rc7 yet.

    J

Re: [2/2] 2.6.21-rc7: known regressions

[Jeremy Fitzhardinge]

Adrian Bunk wrote:
> I'm not sure why I thought you two ran into the same regression.
>
> So "hpet=disable" worked for Jeremy but not for you, IOW: you two were 
> running into different regressions?
>
> @Jeremy:
> If this is true, is your HPET related related regression still present 
> in -rc7?

I need to recheck, but when I tried -rc6, I was still having resume
problems but hpet=disabled didn't help.  So I definitely think there are
multiple bugs with the same symtoms.  I haven't tried -rc7 yet.

    J

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Mon, Apr 16, 2007 at 03:16:37AM +0200, Adrian Bunk wrote:
 > On Sun, Apr 15, 2007 at 08:54:46PM -0400, Dave Jones wrote:
 > > On Mon, Apr 16, 2007 at 02:37:23AM +0200, Adrian Bunk wrote:
 > > 
 > >  > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
 > >  >              workaround: booting with "hpet=disable"
 > >  > References : http://lkml.org/lkml/2007/3/13/3
 > >  > Submitter  : Dave Jones <davej@redhat.com>
 > >  >              Jeremy Fitzhardinge <jeremy@goop.org>
 > >  > Caused-By  : PCI merge
 > >  >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
 > >  > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
 > >  >              Rafael J. Wysocki <rjw@sisk.pl>
 > >  > Status     : unknown
 > > 
 > > note that this workaround doesn't seem to work in all cases.
 > > Mine may a slightly different model (I have the tablet version)
 > > but disabling hpet shows the same regression.
 > > I've been fighting Eric's USB debug cable code in the hope
 > > of getting _something_ useful out of it other than a black screen,
 > > but I've been getting nowhere with it.
 > 
 > I'm not sure why I thought you two ran into the same regression.

I'm not sure why I never hit the same bug that Jeremy did
(again, maybe subtle hardware differences between our models),
but I finally got somewhere.   -rc7 with the same config I've
been testing exhibited exactly the same bug.   Disabling
the FB_BACKLIGHT option (and all the FB drivers that 'select' it),
I get a working display on resume again.

This makes a lot of sense. As before, when I resumed, the backlight
wasn't coming back on, but I knew the machine was alive, as
capslock was working.  (Amusingly, I never noticed the backlight
wasn't coming back on until tonight, when I started debugging this
with the lights off.  Late-night debugging ftw).

I'll try and narrow down exactly where it's failing in the
backlight code next, but it's getting late here, so I may
leave this until tomorrow for further investigation.
Some other clues for anyone playing along at home:
This X60 has Intel graphics.  ie, I'm not using any of
the drivers that 'select FB_BACKLIGHT', so somewhere in
the common fb code is code that I'm guessing is dependant
upon the framebuffer driver doing something or other
if FB_BACKLIGHT is set.

(Adding Richard to Cc: as he seems to be responsible for
 the FB backlight code from what I can tell.)

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Antonino A. Daplas]

On Mon, 2007-04-16 at 02:29 -0400, Dave Jones wrote:
> On Mon, Apr 16, 2007 at 03:16:37AM +0200, Adrian Bunk wrote:
>  > On Sun, Apr 15, 2007 at 08:54:46PM -0400, Dave Jones wrote:
>  > > On Mon, Apr 16, 2007 at 02:37:23AM +0200, Adrian Bunk wrote:
>  > > 
>  > >  > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
>  > >  >              workaround: booting with "hpet=disable"
>  > >  > References : http://lkml.org/lkml/2007/3/13/3
>  > >  > Submitter  : Dave Jones <davej@redhat.com>
>  > >  >              Jeremy Fitzhardinge <jeremy@goop.org>
>  > >  > Caused-By  : PCI merge
>  > >  >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
>  > >  > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
>  > >  >              Rafael J. Wysocki <rjw@sisk.pl>
>  > >  > Status     : unknown
>  > > 

<snip>

> I'll try and narrow down exactly where it's failing in the
> backlight code next, but it's getting late here, so I may
> leave this until tomorrow for further investigation.
> Some other clues for anyone playing along at home:
> This X60 has Intel graphics.  ie, I'm not using any of
> the drivers that 'select FB_BACKLIGHT',

CONFIG_ACPI_VIDEO depends on BACKLIGHT_CLASS_DEVICE, which, in turn is
enabled by FB_BACKLIGHT. So we can narrow it down further, can you try?

CONFIG_FB_BACKLIGHT=y
CONFIG_ACPI_VIDEO=n

Tony

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Mon, Apr 16, 2007 at 02:54:07PM +0800, Antonino A. Daplas wrote:
 
 > CONFIG_ACPI_VIDEO depends on BACKLIGHT_CLASS_DEVICE, which, in turn is
 > enabled by FB_BACKLIGHT. So we can narrow it down further, can you try?
 > 
 > CONFIG_FB_BACKLIGHT=y
 > CONFIG_ACPI_VIDEO=n

That also gets me a dead display. Backlight doesn't turn back on.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Antonino A. Daplas]

On Mon, 2007-04-16 at 03:23 -0400, Dave Jones wrote:
> On Mon, Apr 16, 2007 at 02:54:07PM +0800, Antonino A. Daplas wrote:
>  
>  > CONFIG_ACPI_VIDEO depends on BACKLIGHT_CLASS_DEVICE, which, in turn is
>  > enabled by FB_BACKLIGHT. So we can narrow it down further, can you try?
>  > 
>  > CONFIG_FB_BACKLIGHT=y
>  > CONFIG_ACPI_VIDEO=n
> 
> That also gets me a dead display. Backlight doesn't turn back on.

Anything under /sys/class/backlight?

Tony

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Mon, Apr 16, 2007 at 03:32:02PM +0800, Antonino A. Daplas wrote:
 > On Mon, 2007-04-16 at 03:23 -0400, Dave Jones wrote:
 > > On Mon, Apr 16, 2007 at 02:54:07PM +0800, Antonino A. Daplas wrote:
 > >  
 > >  > CONFIG_ACPI_VIDEO depends on BACKLIGHT_CLASS_DEVICE, which, in turn is
 > >  > enabled by FB_BACKLIGHT. So we can narrow it down further, can you try?
 > >  > 
 > >  > CONFIG_FB_BACKLIGHT=y
 > >  > CONFIG_ACPI_VIDEO=n
 > > 
 > > That also gets me a dead display. Backlight doesn't turn back on.
 > 
 > Anything under /sys/class/backlight?

Entries from ibm_acpi.  I rmmod'd that, leaving the dir empty,
and it still fails.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Richard Purdie]

On Mon, 2007-04-16 at 03:55 -0400, Dave Jones wrote: 
> On Mon, Apr 16, 2007 at 03:32:02PM +0800, Antonino A. Daplas wrote:
>  > On Mon, 2007-04-16 at 03:23 -0400, Dave Jones wrote:
>  > > On Mon, Apr 16, 2007 at 02:54:07PM +0800, Antonino A. Daplas wrote:
>  > >  
>  > >  > CONFIG_ACPI_VIDEO depends on BACKLIGHT_CLASS_DEVICE, which, in turn is
>  > >  > enabled by FB_BACKLIGHT. So we can narrow it down further, can you try?
>  > >  > 
>  > >  > CONFIG_FB_BACKLIGHT=y
>  > >  > CONFIG_ACPI_VIDEO=n
>  > > 
>  > > That also gets me a dead display. Backlight doesn't turn back on.
>  > 
>  > Anything under /sys/class/backlight?
> 
> Entries from ibm_acpi.  I rmmod'd that, leaving the dir empty,
> and it still fails.

What happens if you never load ibm-acpi?

I'm a bit puzzled as CONFIG_FB_BACKLIGHT doesn't do anything with the
intelfb driver. One thing it does do is set
CONFIG_BACKLIGHT_CLASS_DEVICE. When you disabled FB_BACKLIGHT and got a
working display on resume, was that set and was (or had) ibm-acpi been
loaded?

A variety of other options such as ACPI_IBM also set
CONFIG_BACKLIGHT_CLASS_DEVICE although without a backlight driver it
will do nothing hence the suspicion is on ibm-acpi, perhaps interacting
with the backlight class badly.

Does echoing numbers to /sys/class/backlight/ibm_acpi/brightness change
the backlight brightness as expected? If you can ssh into the machine
after its resumed with the display problem, it would be interesting to
know what the brightness was and if changing it helped too...

Regards,

Richard

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Mon, Apr 16, 2007 at 10:26:43AM +0100, Richard Purdie wrote:

 > >  > >  > CONFIG_FB_BACKLIGHT=y
 > >  > >  > CONFIG_ACPI_VIDEO=n
 > >  > > 
 > >  > > That also gets me a dead display. Backlight doesn't turn back on.
 > >  > 
 > >  > Anything under /sys/class/backlight?
 > > 
 > > Entries from ibm_acpi.  I rmmod'd that, leaving the dir empty,
 > > and it still fails.
 > 
 > What happens if you never load ibm-acpi?

Same thing. No backlight on resume.
I rm'd the .ko, so there's no chance it got loaded.

 > I'm a bit puzzled as CONFIG_FB_BACKLIGHT doesn't do anything with the
 > intelfb driver. One thing it does do is set
 > CONFIG_BACKLIGHT_CLASS_DEVICE. When you disabled FB_BACKLIGHT and got a
 > working display on resume, was that set and was (or had) ibm-acpi been
 > loaded?
 > 
 > A variety of other options such as ACPI_IBM also set
 > CONFIG_BACKLIGHT_CLASS_DEVICE although without a backlight driver it
 > will do nothing hence the suspicion is on ibm-acpi, perhaps interacting
 > with the backlight class badly.
 > 
 > Does echoing numbers to /sys/class/backlight/ibm_acpi/brightness change
 > the backlight brightness as expected?

/sys/class/backlight/ibm/brightness takes a value from 0 to 7.
Starts off with a default of 0. I tried all values in there, and
it made no visible difference.  But as the no-backlight thing happens
without this even loaded, I think this is a separate problem.

 > If you can ssh into the machine
 > after its resumed with the display problem, it would be interesting to
 > know what the brightness was and if changing it helped too...

When the backlight doesn't come on, for some reason, nothing else
runs.  Capslock works, so it's at least partially alive, but even
doing..

echo mem > /sys/power/state ; echo foo >/bar ; sync

results in no /bar being created.
Ethernet remains down when its in this state too.

It's the reason it's taken this long to get any debug info out of it at all.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Antonino A. Daplas]

On Mon, 2007-04-16 at 23:34 -0400, Dave Jones wrote:
> On Mon, Apr 16, 2007 at 10:26:43AM +0100, Richard Purdie wrote:
> 
>  > >  > >  > CONFIG_FB_BACKLIGHT=y
>  > >  > >  > CONFIG_ACPI_VIDEO=n
>  > >  > > 
>  > >  > > That also gets me a dead display. Backlight doesn't turn back on.
>  > >  > 
>  > >  > Anything under /sys/class/backlight?
>  > > 
>  > > Entries from ibm_acpi.  I rmmod'd that, leaving the dir empty,
>  > > and it still fails.
>  > 
>  > What happens if you never load ibm-acpi?
> 
> Same thing. No backlight on resume.
> I rm'd the .ko, so there's no chance it got loaded.
> 
>  > I'm a bit puzzled as CONFIG_FB_BACKLIGHT doesn't do anything with the
>  > intelfb driver. One thing it does do is set
>  > CONFIG_BACKLIGHT_CLASS_DEVICE. When you disabled FB_BACKLIGHT and got a
>  > working display on resume, was that set and was (or had) ibm-acpi been
>  > loaded?
>  > 
>  > A variety of other options such as ACPI_IBM also set
>  > CONFIG_BACKLIGHT_CLASS_DEVICE although without a backlight driver it
>  > will do nothing hence the suspicion is on ibm-acpi, perhaps interacting
>  > with the backlight class badly.
>  > 
>  > Does echoing numbers to /sys/class/backlight/ibm_acpi/brightness change
>  > the backlight brightness as expected?
> 
> /sys/class/backlight/ibm/brightness takes a value from 0 to 7.
> Starts off with a default of 0. I tried all values in there, and
> it made no visible difference.  But as the no-backlight thing happens
> without this even loaded, I think this is a separate problem.
> 
>  > If you can ssh into the machine
>  > after its resumed with the display problem, it would be interesting to
>  > know what the brightness was and if changing it helped too...
> 
> When the backlight doesn't come on, for some reason, nothing else
> runs.  Capslock works, so it's at least partially alive, but even
> doing..
> 
> echo mem > /sys/power/state ; echo foo >/bar ; sync
> 
> results in no /bar being created.
> Ethernet remains down when its in this state too.

Have you tried these boot options?

acpi_sleep=s3_mode; or
acpi_sleep=s3_bios,s3_mode

Tony

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Wed, Apr 18, 2007 at 07:48:55AM +0800, Antonino A. Daplas wrote:

 > > When the backlight doesn't come on, for some reason, nothing else
 > > runs.  Capslock works, so it's at least partially alive, but even
 > > doing..
 > > 
 > > echo mem > /sys/power/state ; echo foo >/bar ; sync
 > > 
 > > results in no /bar being created.
 > > Ethernet remains down when its in this state too.
 > 
 > Have you tried these boot options?
 > 
 > acpi_sleep=s3_mode; or
 > acpi_sleep=s3_bios,s3_mode

Yeah, did nothing. I also tried acpi_sleep=s3_bios on its own.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Rafael J. Wysocki]

On Monday, 16 April 2007 02:37, Adrian Bunk wrote:
> This email lists some known regressions in Linus' tree compared to 2.6.20.
> 
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way
> possibly involved with one or more of these issues.
> 
> Due to the huge amount of recipients, please trim the Cc when answering.
> 
[--snip--]
> 
> 
> Subject    : suspend to disk works only once
> References : http://lkml.org/lkml/2007/4/13/240
> Submitter  : Tobias Diedrich <ranma+kernel@tdiedrich.de>
> Caused-By  : Rafael J. Wysocki <rjw@sisk.pl>
>              commit ed746e3b18f4df18afa3763155972c5835f284c5
> Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
>              Dmitry Torokhov <dtor@insightbb.com>
>              David Brownell <david-b@pacbell.net>
> Status     : problem is being debugged

Workaround is possible: do "echo shutdown > /sys/power/disk" before the
suspend or, for s2disk, add "shutdown method = shutdown" to the configuration
file.

Greetings,
Rafael

Re: [2/2] 2.6.21-rc7: known regressions

[Jeremy Fitzhardinge]

Adrian Bunk wrote:
> Subject    : ThinkPad X60: resume no longer works  (PCI related?)
>              workaround: booting with "hpet=disable"
> References : http://lkml.org/lkml/2007/3/13/3
> Submitter  : Dave Jones <davej@redhat.com>
>              Jeremy Fitzhardinge <jeremy@goop.org>
> Caused-By  : PCI merge
>              commit 78149df6d565c36675463352d0bfe0000b02b7a7
> Handled-By : Eric W. Biederman <ebiederm@xmission.com>
>              Rafael J. Wysocki <rjw@sisk.pl>
> Status     : unknown
>   

OK. 2.6.21-rc7 suspend/resume works perfectly for me.  It's the first
kernel version in a long time.  I have no workarounds or special boot
options.  It's using hpet as the clocksource.

    J

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Thu, Apr 19, 2007 at 09:57:15PM -0700, Jeremy Fitzhardinge wrote:
 > Adrian Bunk wrote:
 > > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
 > >              workaround: booting with "hpet=disable"
 > > References : http://lkml.org/lkml/2007/3/13/3
 > > Submitter  : Dave Jones <davej@redhat.com>
 > >              Jeremy Fitzhardinge <jeremy@goop.org>
 > > Caused-By  : PCI merge
 > >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
 > > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
 > >              Rafael J. Wysocki <rjw@sisk.pl>
 > > Status     : unknown
 > >   
 > 
 > OK. 2.6.21-rc7 suspend/resume works perfectly for me.  It's the first
 > kernel version in a long time.  I have no workarounds or special boot
 > options.  It's using hpet as the clocksource.

Do you have the backlight code enabled ?
I'm guessing not.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Thu, Apr 19, 2007 at 09:57:15PM -0700, Jeremy Fitzhardinge wrote:
 > Adrian Bunk wrote:
 > > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
 > >              workaround: booting with "hpet=disable"
 > > References : http://lkml.org/lkml/2007/3/13/3
 > > Submitter  : Dave Jones <davej@redhat.com>
 > >              Jeremy Fitzhardinge <jeremy@goop.org>
 > > Caused-By  : PCI merge
 > >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
 > > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
 > >              Rafael J. Wysocki <rjw@sisk.pl>
 > > Status     : unknown
 > >   
 > 
 > OK. 2.6.21-rc7 suspend/resume works perfectly for me.  It's the first
 > kernel version in a long time.  I have no workarounds or special boot
 > options.  It's using hpet as the clocksource.

Do you have the backlight code enabled ?
I'm guessing not.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Jeremy Fitzhardinge]

Dave Jones wrote:
> Do you have the backlight code enabled ?
> I'm guessing not.
>   

Hm, think so.  backlight controls work, via both
/proc/acpi/ibm/backlight and /sys/class/backlight/*/brightness.

$ ls -l /sys/class/backlight/
total 0
drwxr-xr-x 2 root root 0 Apr 19 22:13 acpi_video0
drwxr-xr-x 2 root root 0 Apr 19 22:13 acpi_video1
drwxr-xr-x 2 root root 0 Apr 19 22:13 ibm


    J

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Thu, Apr 19, 2007 at 10:15:48PM -0700, Jeremy Fitzhardinge wrote:
 > Dave Jones wrote:
 > > Do you have the backlight code enabled ?
 > > I'm guessing not.
 > >   
 > 
 > Hm, think so.  backlight controls work, via both
 > /proc/acpi/ibm/backlight and /sys/class/backlight/*/brightness.
 > 
 > $ ls -l /sys/class/backlight/
 > total 0
 > drwxr-xr-x 2 root root 0 Apr 19 22:13 acpi_video0
 > drwxr-xr-x 2 root root 0 Apr 19 22:13 acpi_video1
 > drwxr-xr-x 2 root root 0 Apr 19 22:13 ibm

Hmm, given you hit the hpet problems and I didn't I think our X60's
aren't quite so similar.  Mine is the one with the swivelly touchscreen
tablet-pc mode. I understand they made a regular 'laptop' X60 too,
is that the one you have perhaps?

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Thu, Apr 19, 2007 at 10:15:48PM -0700, Jeremy Fitzhardinge wrote:
 > Dave Jones wrote:
 > > Do you have the backlight code enabled ?
 > > I'm guessing not.
 > >   
 > 
 > Hm, think so.  backlight controls work, via both
 > /proc/acpi/ibm/backlight and /sys/class/backlight/*/brightness.
 > 
 > $ ls -l /sys/class/backlight/
 > total 0
 > drwxr-xr-x 2 root root 0 Apr 19 22:13 acpi_video0
 > drwxr-xr-x 2 root root 0 Apr 19 22:13 acpi_video1
 > drwxr-xr-x 2 root root 0 Apr 19 22:13 ibm

Hmm, given you hit the hpet problems and I didn't I think our X60's
aren't quite so similar.  Mine is the one with the swivelly touchscreen
tablet-pc mode. I understand they made a regular 'laptop' X60 too,
is that the one you have perhaps?

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Jeremy Fitzhardinge]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

Dave Jones wrote:
> Hmm, given you hit the hpet problems and I didn't I think our X60's
> aren't quite so similar.  Mine is the one with the swivelly touchscreen
> tablet-pc mode. I understand they made a regular 'laptop' X60 too,
> is that the one you have perhaps?
>   

Yes, mine is a normal laptop X60.  Still, its hard to imagine how they
could be very different; same CPU, same chipset, same graphics.  The
main difference is that your's has a Wacom tablet, presumably attached
to USB.

Details attached. How does it compare to your machine?

    J

[-- Attachment #2: config.txt.gz --]
[-- Type: application/x-gzip, Size: 4848 bytes --]

[-- Attachment #3: dmesg.txt.gz --]
[-- Type: application/x-gzip, Size: 12858 bytes --]

[-- Attachment #4: pci.txt.gz --]
[-- Type: application/x-gzip, Size: 1765 bytes --]

[-- Attachment #5: usb.txt.gz --]
[-- Type: application/x-gzip, Size: 1384 bytes --]

[-- Attachment #6: dmi.txt.gz --]
[-- Type: application/x-gzip, Size: 3274 bytes --]

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Thu, Apr 19, 2007 at 10:33:39PM -0700, Jeremy Fitzhardinge wrote:
 > Dave Jones wrote:
 > > Hmm, given you hit the hpet problems and I didn't I think our X60's
 > > aren't quite so similar.  Mine is the one with the swivelly touchscreen
 > > tablet-pc mode. I understand they made a regular 'laptop' X60 too,
 > > is that the one you have perhaps?
 > 
 > Yes, mine is a normal laptop X60.  Still, its hard to imagine how they
 > could be very different; same CPU, same chipset, same graphics.  The
 > main difference is that your's has a Wacom tablet, presumably attached
 > to USB.
 > 
 > Details attached. How does it compare to your machine?

-1142MB HIGHMEM available.
+118MB HIGHMEM available.

So you have more RAM than I do :)

-NX (Execute Disable) protection: active

You enabled PAE, I didn't..
(Though I have tried both, makes no difference)

 DMI present.
+Using APIC driver default

Hmm.

 ACPI: RSDP 000F67B0, 0024 (r2 LENOVO)
-ACPI: XSDT 7F6D1896, 008C (r1 LENOVO TP-7B        2060  LTP        0)
-ACPI: FACP 7F6D1A00, 00F4 (r3 LENOVO TP-7B        2060 LNVO        1)
+ACPI: XSDT 3F6D12F5, 008C (r1 LENOVO TP-7J        1050  LTP        0)
+ACPI: FACP 3F6D1400, 00F4 (r3 LENOVO TP-7J        1050 LNVO        1)

BIOS differences (lots of these)

-Allocating PCI resources starting at 88000000 (gap: 80000000:70000000)
+Allocating PCI resources starting at 50000000 (gap: 40000000:b0000000)

Probably due to the RAM differences shuffling the memmap.

-Kernel command line: ro root=LABEL=/ acpi_sleep=s3_bios combined_mode=libata
+Kernel command line: ro root=/dev/VolGroup00/LogVol00 profile=1

Hmm. I tried..
acpi_sleep=s3_bios
acpi_sleep=s3_mode
acpi_sleep=s3_bios,s3_mode
all did nothing for me.

-CPU: After all inits, caps: bfe9fbff 00100000 00000000 00002940 0000c1a9 00000000 00000000
+CPU: After all inits, caps: bfe9f3ff 00100000 00000000 00002940 0000c1a9 00000000 00000000

Probably PAE

-CPU0: Intel Genuine Intel(R) CPU           T2400  @ 1.83GHz stepping 08
+CPU0: Intel(R) Core(TM) Duo CPU      L2400  @ 1.66GHz stepping 0c

slightly different CPU, but probably not enough to make any difference.

-BUG: at arch/i386/kernel/sched-clock.c:170 init_sched_clock()
- [<c01091b5>] show_trace_log_lvl+0x1a/0x30
- [<c010980c>] show_trace+0x12/0x14
- [<c01098cb>] dump_stack+0x16/0x18
- [<c0468dbd>] init_sched_clock+0x58/0x9b
- [<c0461502>] init+0x14b/0x241
- [<c0108d97>] kernel_thread_helper+0x7/0x10
- =======================

heh, one for Ingo :)

-ACPI: ACPI Dock Station Driver 
-ACPI: \_SB_.PCI0.IDE0.PRIM.MSTR: found ejectable bay
-ACPI: \_SB_.PCI0.IDE0.PRIM.MSTR: Adding notify handler
-ACPI: Bay [\_SB_.PCI0.IDE0.PRIM.MSTR] Added

Hmm, I should try without the dock stuff built.

-PCI: Using MMCONFIG
+PCI: PCI BIOS revision 2.10 entry at 0xfd82b, last bus=24
+PCI: Using configuration type 1

Think I've tried with and without MMCONFIG

-pnp: PnP ACPI: found 11 devices
+pnp: PnP ACPI: found 13 devices

My Wacom tablet is one of them. There's also a mysterious 13th device :)

 ibm_acpi: IBM ThinkPad ACPI Extras v0.13
 ibm_acpi: http://ibm-acpi.sf.net/
-ibm_acpi: ThinkPad EC firmware 7BHT37WW-1.10
+ibm_acpi: ThinkPad EC firmware 7JHT12WW-1.03

possibly just because of the touchscreen.

So most of the differences seem to be BIOS/firmware rather than hardware. 
The PCI bus layout is identical for eg.

Looking at your .config, I notice that you don't have CONFIG_FB_BACKLIGHT set
(because you don't have any framebuffer drivers that use it enabled).
Can you enable say.. CONFIG_FB_RADEON=m and CONFIG_FB_RADEON_BACKLIGHT=y
(which should turn on CONFIG_FB_BACKLIGHT=y by dependancy), and see if
it stops working for you? (You don't even need to load radeonfb.ko, just
have it compiled).

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Thu, Apr 19, 2007 at 10:33:39PM -0700, Jeremy Fitzhardinge wrote:
 > Dave Jones wrote:
 > > Hmm, given you hit the hpet problems and I didn't I think our X60's
 > > aren't quite so similar.  Mine is the one with the swivelly touchscreen
 > > tablet-pc mode. I understand they made a regular 'laptop' X60 too,
 > > is that the one you have perhaps?
 > 
 > Yes, mine is a normal laptop X60.  Still, its hard to imagine how they
 > could be very different; same CPU, same chipset, same graphics.  The
 > main difference is that your's has a Wacom tablet, presumably attached
 > to USB.
 > 
 > Details attached. How does it compare to your machine?

-1142MB HIGHMEM available.
+118MB HIGHMEM available.

So you have more RAM than I do :)

-NX (Execute Disable) protection: active

You enabled PAE, I didn't..
(Though I have tried both, makes no difference)

 DMI present.
+Using APIC driver default

Hmm.

 ACPI: RSDP 000F67B0, 0024 (r2 LENOVO)
-ACPI: XSDT 7F6D1896, 008C (r1 LENOVO TP-7B        2060  LTP        0)
-ACPI: FACP 7F6D1A00, 00F4 (r3 LENOVO TP-7B        2060 LNVO        1)
+ACPI: XSDT 3F6D12F5, 008C (r1 LENOVO TP-7J        1050  LTP        0)
+ACPI: FACP 3F6D1400, 00F4 (r3 LENOVO TP-7J        1050 LNVO        1)

BIOS differences (lots of these)

-Allocating PCI resources starting at 88000000 (gap: 80000000:70000000)
+Allocating PCI resources starting at 50000000 (gap: 40000000:b0000000)

Probably due to the RAM differences shuffling the memmap.

-Kernel command line: ro root=LABEL=/ acpi_sleep=s3_bios combined_mode=libata
+Kernel command line: ro root=/dev/VolGroup00/LogVol00 profile=1

Hmm. I tried..
acpi_sleep=s3_bios
acpi_sleep=s3_mode
acpi_sleep=s3_bios,s3_mode
all did nothing for me.

-CPU: After all inits, caps: bfe9fbff 00100000 00000000 00002940 0000c1a9 00000000 00000000
+CPU: After all inits, caps: bfe9f3ff 00100000 00000000 00002940 0000c1a9 00000000 00000000

Probably PAE

-CPU0: Intel Genuine Intel(R) CPU           T2400  @ 1.83GHz stepping 08
+CPU0: Intel(R) Core(TM) Duo CPU      L2400  @ 1.66GHz stepping 0c

slightly different CPU, but probably not enough to make any difference.

-BUG: at arch/i386/kernel/sched-clock.c:170 init_sched_clock()
- [<c01091b5>] show_trace_log_lvl+0x1a/0x30
- [<c010980c>] show_trace+0x12/0x14
- [<c01098cb>] dump_stack+0x16/0x18
- [<c0468dbd>] init_sched_clock+0x58/0x9b
- [<c0461502>] init+0x14b/0x241
- [<c0108d97>] kernel_thread_helper+0x7/0x10
- =======================

heh, one for Ingo :)

-ACPI: ACPI Dock Station Driver 
-ACPI: \_SB_.PCI0.IDE0.PRIM.MSTR: found ejectable bay
-ACPI: \_SB_.PCI0.IDE0.PRIM.MSTR: Adding notify handler
-ACPI: Bay [\_SB_.PCI0.IDE0.PRIM.MSTR] Added

Hmm, I should try without the dock stuff built.

-PCI: Using MMCONFIG
+PCI: PCI BIOS revision 2.10 entry at 0xfd82b, last bus=24
+PCI: Using configuration type 1

Think I've tried with and without MMCONFIG

-pnp: PnP ACPI: found 11 devices
+pnp: PnP ACPI: found 13 devices

My Wacom tablet is one of them. There's also a mysterious 13th device :)

 ibm_acpi: IBM ThinkPad ACPI Extras v0.13
 ibm_acpi: http://ibm-acpi.sf.net/
-ibm_acpi: ThinkPad EC firmware 7BHT37WW-1.10
+ibm_acpi: ThinkPad EC firmware 7JHT12WW-1.03

possibly just because of the touchscreen.

So most of the differences seem to be BIOS/firmware rather than hardware. 
The PCI bus layout is identical for eg.

Looking at your .config, I notice that you don't have CONFIG_FB_BACKLIGHT set
(because you don't have any framebuffer drivers that use it enabled).
Can you enable say.. CONFIG_FB_RADEON=m and CONFIG_FB_RADEON_BACKLIGHT=y
(which should turn on CONFIG_FB_BACKLIGHT=y by dependancy), and see if
it stops working for you? (You don't even need to load radeonfb.ko, just
have it compiled).

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Jeremy Fitzhardinge]

Dave Jones wrote:
> -BUG: at arch/i386/kernel/sched-clock.c:170 init_sched_clock()
> - [<c01091b5>] show_trace_log_lvl+0x1a/0x30
> - [<c010980c>] show_trace+0x12/0x14
> - [<c01098cb>] dump_stack+0x16/0x18
> - [<c0468dbd>] init_sched_clock+0x58/0x9b
> - [<c0461502>] init+0x14b/0x241
> - [<c0108d97>] kernel_thread_helper+0x7/0x10
> - =======================
>
> heh, one for Ingo :)
>   

Andi, I think.  I've got his firstfloor.org patches applied to this kernel.

> -ACPI: ACPI Dock Station Driver 
> -ACPI: \_SB_.PCI0.IDE0.PRIM.MSTR: found ejectable bay
> -ACPI: \_SB_.PCI0.IDE0.PRIM.MSTR: Adding notify handler
> -ACPI: Bay [\_SB_.PCI0.IDE0.PRIM.MSTR] Added
>
> Hmm, I should try without the dock stuff built.
>
> -PCI: Using MMCONFIG
> +PCI: PCI BIOS revision 2.10 entry at 0xfd82b, last bus=24
> +PCI: Using configuration type 1
>
> Think I've tried with and without MMCONFIG
>
> -pnp: PnP ACPI: found 11 devices
> +pnp: PnP ACPI: found 13 devices
>
> My Wacom tablet is one of them. There's also a mysterious 13th device :)
>
>  ibm_acpi: IBM ThinkPad ACPI Extras v0.13
>  ibm_acpi: http://ibm-acpi.sf.net/
> -ibm_acpi: ThinkPad EC firmware 7BHT37WW-1.10
> +ibm_acpi: ThinkPad EC firmware 7JHT12WW-1.03
>
> possibly just because of the touchscreen.
>   

I'm running a very recent BIOS in order to enable hardware
virtualization (VT/VMX).  The BIOS updates also update the EC firmware.

> So most of the differences seem to be BIOS/firmware rather than hardware. 
> The PCI bus layout is identical for eg.
>   

Do you have Intel wireless?  I realized one chance I'd made was to swap
the Atheros wireless with Intel, since it just seems to work better
overall.  I'd never had any major suspend/resume problems that I could
attribute to madwifi though (lots of minor wifi-related ones though).

> Looking at your .config, I notice that you don't have CONFIG_FB_BACKLIGHT set
> (because you don't have any framebuffer drivers that use it enabled).
> Can you enable say.. CONFIG_FB_RADEON=m and CONFIG_FB_RADEON_BACKLIGHT=y
> (which should turn on CONFIG_FB_BACKLIGHT=y by dependancy), and see if
> it stops working for you? (You don't even need to load radeonfb.ko, just
> have it compiled).

OK, I'll give it a spin.

    J

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Fri, Apr 20, 2007 at 08:28:10AM -0700, Jeremy Fitzhardinge wrote:
 > Dave Jones wrote:
 > > -BUG: at arch/i386/kernel/sched-clock.c:170 init_sched_clock()
 > > - [<c01091b5>] show_trace_log_lvl+0x1a/0x30
 > > - [<c010980c>] show_trace+0x12/0x14
 > > - [<c01098cb>] dump_stack+0x16/0x18
 > > - [<c0468dbd>] init_sched_clock+0x58/0x9b
 > > - [<c0461502>] init+0x14b/0x241
 > > - [<c0108d97>] kernel_thread_helper+0x7/0x10
 > > - =======================
 > >
 > > heh, one for Ingo :)
 > Andi, I think.  I've got his firstfloor.org patches applied to this kernel.

Ah, I saw you patched in CFS too, and thought it may be related.

 > > So most of the differences seem to be BIOS/firmware rather than hardware. 
 > > The PCI bus layout is identical for eg.
 > 
 > Do you have Intel wireless?  I realized one chance I'd made was to swap
 > the Atheros wireless with Intel, since it just seems to work better
 > overall.  I'd never had any major suspend/resume problems that I could
 > attribute to madwifi though (lots of minor wifi-related ones though).

yeah, the intel wireless.  Same as teh one in your pci.gz attachment..
03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
	Subsystem: Intel Corporation Unknown device 1010
	Flags: bus master, fast devsel, latency 0, IRQ 21

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Fri, Apr 20, 2007 at 08:28:10AM -0700, Jeremy Fitzhardinge wrote:
 > Dave Jones wrote:
 > > -BUG: at arch/i386/kernel/sched-clock.c:170 init_sched_clock()
 > > - [<c01091b5>] show_trace_log_lvl+0x1a/0x30
 > > - [<c010980c>] show_trace+0x12/0x14
 > > - [<c01098cb>] dump_stack+0x16/0x18
 > > - [<c0468dbd>] init_sched_clock+0x58/0x9b
 > > - [<c0461502>] init+0x14b/0x241
 > > - [<c0108d97>] kernel_thread_helper+0x7/0x10
 > > - =======================
 > >
 > > heh, one for Ingo :)
 > Andi, I think.  I've got his firstfloor.org patches applied to this kernel.

Ah, I saw you patched in CFS too, and thought it may be related.

 > > So most of the differences seem to be BIOS/firmware rather than hardware. 
 > > The PCI bus layout is identical for eg.
 > 
 > Do you have Intel wireless?  I realized one chance I'd made was to swap
 > the Atheros wireless with Intel, since it just seems to work better
 > overall.  I'd never had any major suspend/resume problems that I could
 > attribute to madwifi though (lots of minor wifi-related ones though).

yeah, the intel wireless.  Same as teh one in your pci.gz attachment..
03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
	Subsystem: Intel Corporation Unknown device 1010
	Flags: bus master, fast devsel, latency 0, IRQ 21

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Jeremy Fitzhardinge]

Dave Jones wrote:
>  > Andi, I think.  I've got his firstfloor.org patches applied to this kernel.
>
> Ah, I saw you patched in CFS too, and thought it may be related.
>   

Well, I have CONFIG_FB_BACKLIGHT enabled, and it still works.

Maybe there's something in Andi's queue which is making it work?

    J

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Fri, Apr 20, 2007 at 10:16:54AM -0700, Jeremy Fitzhardinge wrote:
 > Dave Jones wrote:
 > >  > Andi, I think.  I've got his firstfloor.org patches applied to this kernel.
 > >
 > > Ah, I saw you patched in CFS too, and thought it may be related.
 > >   
 > 
 > Well, I have CONFIG_FB_BACKLIGHT enabled, and it still works.
 > 
 > Maybe there's something in Andi's queue which is making it work?

Shrug, I'm out of ideas.  I'm hoping that it'll magically start working
when people start flushing their git trees for .22
Maybe that'll yield a clue for something that can be backported to .21.x
because right now, I'm completely puzzled.

I was testing on a vanilla 2.6.21-rc7-git3.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Fri, Apr 20, 2007 at 10:16:54AM -0700, Jeremy Fitzhardinge wrote:
 > Dave Jones wrote:
 > >  > Andi, I think.  I've got his firstfloor.org patches applied to this kernel.
 > >
 > > Ah, I saw you patched in CFS too, and thought it may be related.
 > >   
 > 
 > Well, I have CONFIG_FB_BACKLIGHT enabled, and it still works.
 > 
 > Maybe there's something in Andi's queue which is making it work?

Shrug, I'm out of ideas.  I'm hoping that it'll magically start working
when people start flushing their git trees for .22
Maybe that'll yield a clue for something that can be backported to .21.x
because right now, I'm completely puzzled.

I was testing on a vanilla 2.6.21-rc7-git3.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Jeremy Fitzhardinge]

Dave Jones wrote:
> On Fri, Apr 20, 2007 at 10:16:54AM -0700, Jeremy Fitzhardinge wrote:
>  > Dave Jones wrote:
>  > >  > Andi, I think.  I've got his firstfloor.org patches applied to this kernel.
>  > >
>  > > Ah, I saw you patched in CFS too, and thought it may be related.
>  > >   
>  > 
>  > Well, I have CONFIG_FB_BACKLIGHT enabled, and it still works.
>  > 
>  > Maybe there's something in Andi's queue which is making it work?
>
> Shrug, I'm out of ideas.  I'm hoping that it'll magically start working
> when people start flushing their git trees for .22
> Maybe that'll yield a clue for something that can be backported to .21.x
> because right now, I'm completely puzzled.

Well, it seemed reliable, but I just got a resume failure.  Different
from any previous symptom I've seen:

Intel machine check architecture supported
Intel machine check reporting enabled enabled on CPU#1
Back to C!
<hang>

    J

Re: [2/2] 2.6.21-rc7: known regressions

[Rafael J. Wysocki]

On Saturday, 21 April 2007 02:02, Jeremy Fitzhardinge wrote:
> Dave Jones wrote:
> > On Fri, Apr 20, 2007 at 10:16:54AM -0700, Jeremy Fitzhardinge wrote:
> >  > Dave Jones wrote:
> >  > >  > Andi, I think.  I've got his firstfloor.org patches applied to this kernel.
> >  > >
> >  > > Ah, I saw you patched in CFS too, and thought it may be related.
> >  > >   
> >  > 
> >  > Well, I have CONFIG_FB_BACKLIGHT enabled, and it still works.
> >  > 
> >  > Maybe there's something in Andi's queue which is making it work?
> >
> > Shrug, I'm out of ideas.  I'm hoping that it'll magically start working
> > when people start flushing their git trees for .22
> > Maybe that'll yield a clue for something that can be backported to .21.x
> > because right now, I'm completely puzzled.
> 
> Well, it seemed reliable, but I just got a resume failure.  Different
> from any previous symptom I've seen:
> 
> Intel machine check architecture supported
> Intel machine check reporting enabled enabled on CPU#1
> Back to C!
> <hang>

Hmm, looks like something in device_power_up() went awry.  Probably in
sysdev_resume().

Greetings,
Rafael

Re: Linux 2.6.21-rc7

[Chuck Ebbert]

Linus Torvalds wrote:
> Since we're still waiting for resolution for some regressions that people 
> weren't able to work on last week, there's a new -rc kernel out there. 
> Hopefully we'll get them all and I can do 2.6.21-final next weekend or 
> so..
> 

The patch to k8.c didn't make it in:

cache_k8_northbridges() is storing config values to incorrect locations
(in flush_words) and also its overflowing beyond the allocation, causing
slab verification failures.

Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>
---
 arch/x86_64/kernel/k8.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: linux-2.6.21-rc6/arch/x86_64/kernel/k8.c
===================================================================
--- linux-2.6.21-rc6.orig/arch/x86_64/kernel/k8.c	2007-04-05 19:36:56.000000000 -0700
+++ linux-2.6.21-rc6/arch/x86_64/kernel/k8.c	2007-04-13 07:51:57.000000000 -0700
@@ -61,8 +61,8 @@ int cache_k8_northbridges(void)
 	dev = NULL;
 	i = 0;
 	while ((dev = next_k8_northbridge(dev)) != NULL) {
-		k8_northbridges[i++] = dev;
-		pci_read_config_dword(dev, 0x9c, &flush_words[i]);
+		k8_northbridges[i] = dev;
+		pci_read_config_dword(dev, 0x9c, &flush_words[i++]);
 	}
 	k8_northbridges[i] = NULL;
 	return 0;

[1/3] 2.6.21-rc7: known regressions (v2)

[Adrian Bunk]

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : gammu no longer works
References : http://lkml.org/lkml/2007/4/20/84
Submitter  : Wolfgang Erig <Wolfgang.Erig@gmx.de>
Status     : unknown


Subject    : hal daemon crashes after pulling a USB serial device
References : http://www.opensubscriber.com/message/linux-usb-devel@lists.sourceforge.net/6369800.html
Submitter  : Andi Kleen <ak@suse.de>
Handled-By : Oliver Neukum <oneukum@suse.de>
Status     : problem is being debugged


Subject    : Oops when changing USB DVB-T adapter
References : http://lkml.org/lkml/2007/3/9/212
             http://lkml.org/lkml/2007/4/5/154
Submitter  : CIJOML <cijoml@volny.cz>
Handled-By : Markus Rechberger <markus.rechberger@amd.com>
Status     : patches available


Subject    : snd_hda_intel doesn't work with ASUS M2V mainboard
References : http://bugzilla.kernel.org/show_bug.cgi?id=8273
Submitter  : Hans-Georg Rist <hg.rist@web.de>
Status     : unknown


Subject    : snd_intel8x0: divide error: 0000
References : http://lkml.org/lkml/2007/3/5/252
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Handled-By : Takashi Iwai <tiwai@suse.de>
Patch      : http://lkml.org/lkml/2007/4/20/117
Status     : patch available

Re: [1/3] 2.6.21-rc7: known regressions (v2)

[Greg KH]

On Mon, Apr 23, 2007 at 11:48:47PM +0200, Adrian Bunk wrote:
> This email lists some known regressions in Linus' tree compared to 2.6.20.
> 
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way
> possibly involved with one or more of these issues.
> 
> Due to the huge amount of recipients, please trim the Cc when answering.
> 
> 
> Subject    : gammu no longer works
> References : http://lkml.org/lkml/2007/4/20/84
> Submitter  : Wolfgang Erig <Wolfgang.Erig@gmx.de>
> Status     : unknown

I've asked for more information about this, and so far am not sure it's
a real problem.

thanks,

greg k-h

Re: [1/3] 2.6.21-rc7: known regressions (v2)

[Wolfgang Erig]

On Mon, Apr 23, 2007 at 03:18:19PM -0700, Greg KH wrote:
> On Mon, Apr 23, 2007 at 11:48:47PM +0200, Adrian Bunk wrote:
> > This email lists some known regressions in Linus' tree compared to 2.6.20.
> > 
> > If you find your name in the Cc header, you are either submitter of one
> > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > of you caused a breakage or I'm considering you in any other way
> > possibly involved with one or more of these issues.
> > 
> > Due to the huge amount of recipients, please trim the Cc when answering.
> > 
> > 
> > Subject    : gammu no longer works
> > References : http://lkml.org/lkml/2007/4/20/84
> > Submitter  : Wolfgang Erig <Wolfgang.Erig@gmx.de>
> > Status     : unknown
> 
> I've asked for more information about this, and so far am not sure it's
> a real problem.

It is a real problem for me.
I tried this on 2 different boxes with the same behaviour.
No sync between my Nokia mobile and Linux with the latest kernel :(

Which additional information is useful for this problem?

Wolfgang


$ gammu textall --backup backup
Press Ctrl+C to break...
[Gammu            - 1.10.0 built 10:15:07 Mar 13 2007 in gcc 4.1]
[Connection       - "fbuspl2303"]
[Model type       - "3100"]
[Device           - "/dev/ttyUSB0"]
[Run on           - Linux, kernel 2.6.21-rc7-g80d74d51 (#9 SMP Wed Apr 18 21:41:41 CEST 2007)]
[Module           - "1100|1100a|1100b|2650|3100|3100b|3105|3108|3200|3200a|3205|3220|3300|3510|3510i|3530|3589i|3590|3595|5100|5140|5140i|6020|6021|6030|6100|6101|6103|6111|6125|6131|6170|6200|6220|6230|6230i|6233|6234|6270|6280|6310|6310i|6385|6510|6610|6610i|6800|6810|6820|6822|7200|7210|7250|7250i|7260|7270|7360|7370|7600|8310|8390|8910|8910i"]
Setting speed to 19200
I/O possible

Re: [1/3] 2.6.21-rc7: known regressions (v2)

[Greg KH]

On Tue, Apr 24, 2007 at 11:32:53AM +0200, Wolfgang Erig wrote:
> On Mon, Apr 23, 2007 at 03:18:19PM -0700, Greg KH wrote:
> > On Mon, Apr 23, 2007 at 11:48:47PM +0200, Adrian Bunk wrote:
> > > This email lists some known regressions in Linus' tree compared to 2.6.20.
> > > 
> > > If you find your name in the Cc header, you are either submitter of one
> > > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > > of you caused a breakage or I'm considering you in any other way
> > > possibly involved with one or more of these issues.
> > > 
> > > Due to the huge amount of recipients, please trim the Cc when answering.
> > > 
> > > 
> > > Subject    : gammu no longer works
> > > References : http://lkml.org/lkml/2007/4/20/84
> > > Submitter  : Wolfgang Erig <Wolfgang.Erig@gmx.de>
> > > Status     : unknown
> > 
> > I've asked for more information about this, and so far am not sure it's
> > a real problem.
> 
> It is a real problem for me.
> I tried this on 2 different boxes with the same behaviour.
> No sync between my Nokia mobile and Linux with the latest kernel :(

Sorry, I didn't see your response, have followed up on lkml now.

thanks,

greg k-h

Re: [1/3] 2.6.21-rc7: known regressions (v2)

[Adrian Bunk]

On Tue, Apr 24, 2007 at 05:14:28PM -0700, Greg KH wrote:
> On Tue, Apr 24, 2007 at 11:32:53AM +0200, Wolfgang Erig wrote:
> > On Mon, Apr 23, 2007 at 03:18:19PM -0700, Greg KH wrote:
> > > On Mon, Apr 23, 2007 at 11:48:47PM +0200, Adrian Bunk wrote:
> > > > This email lists some known regressions in Linus' tree compared to 2.6.20.
> > > > 
> > > > If you find your name in the Cc header, you are either submitter of one
> > > > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > > > of you caused a breakage or I'm considering you in any other way
> > > > possibly involved with one or more of these issues.
> > > > 
> > > > Due to the huge amount of recipients, please trim the Cc when answering.
> > > > 
> > > > 
> > > > Subject    : gammu no longer works
> > > > References : http://lkml.org/lkml/2007/4/20/84
> > > > Submitter  : Wolfgang Erig <Wolfgang.Erig@gmx.de>
> > > > Status     : unknown
> > > 
> > > I've asked for more information about this, and so far am not sure it's
> > > a real problem.
> > 
> > It is a real problem for me.
> > I tried this on 2 different boxes with the same behaviour.
> > No sync between my Nokia mobile and Linux with the latest kernel :(
> 
> Sorry, I didn't see your response, have followed up on lkml now.

It turned out this was actually a bug in Gammu that will be fixed in 
the next release of Gammu.

> thanks,
> 
> greg k-h

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [1/3] 2.6.21-rc7: known regressions (v2)

[Greg KH]

On Wed, Apr 25, 2007 at 02:29:58AM +0200, Adrian Bunk wrote:
> On Tue, Apr 24, 2007 at 05:14:28PM -0700, Greg KH wrote:
> > On Tue, Apr 24, 2007 at 11:32:53AM +0200, Wolfgang Erig wrote:
> > > On Mon, Apr 23, 2007 at 03:18:19PM -0700, Greg KH wrote:
> > > > On Mon, Apr 23, 2007 at 11:48:47PM +0200, Adrian Bunk wrote:
> > > > > This email lists some known regressions in Linus' tree compared to 2.6.20.
> > > > > 
> > > > > If you find your name in the Cc header, you are either submitter of one
> > > > > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > > > > of you caused a breakage or I'm considering you in any other way
> > > > > possibly involved with one or more of these issues.
> > > > > 
> > > > > Due to the huge amount of recipients, please trim the Cc when answering.
> > > > > 
> > > > > 
> > > > > Subject    : gammu no longer works
> > > > > References : http://lkml.org/lkml/2007/4/20/84
> > > > > Submitter  : Wolfgang Erig <Wolfgang.Erig@gmx.de>
> > > > > Status     : unknown
> > > > 
> > > > I've asked for more information about this, and so far am not sure it's
> > > > a real problem.
> > > 
> > > It is a real problem for me.
> > > I tried this on 2 different boxes with the same behaviour.
> > > No sync between my Nokia mobile and Linux with the latest kernel :(
> > 
> > Sorry, I didn't see your response, have followed up on lkml now.
> 
> It turned out this was actually a bug in Gammu that will be fixed in 
> the next release of Gammu.

Ah, ok, thanks for letting me know.

But how was the kernel version change triggering it?

greg k-h

Re: [1/3] 2.6.21-rc7: known regressions (v2)

[Adrian Bunk]

On Tue, Apr 24, 2007 at 05:51:11PM -0700, Greg KH wrote:
> On Wed, Apr 25, 2007 at 02:29:58AM +0200, Adrian Bunk wrote:
> > On Tue, Apr 24, 2007 at 05:14:28PM -0700, Greg KH wrote:
> > > On Tue, Apr 24, 2007 at 11:32:53AM +0200, Wolfgang Erig wrote:
> > > > On Mon, Apr 23, 2007 at 03:18:19PM -0700, Greg KH wrote:
> > > > > On Mon, Apr 23, 2007 at 11:48:47PM +0200, Adrian Bunk wrote:
> > > > > > This email lists some known regressions in Linus' tree compared to 2.6.20.
> > > > > > 
> > > > > > If you find your name in the Cc header, you are either submitter of one
> > > > > > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > > > > > of you caused a breakage or I'm considering you in any other way
> > > > > > possibly involved with one or more of these issues.
> > > > > > 
> > > > > > Due to the huge amount of recipients, please trim the Cc when answering.
> > > > > > 
> > > > > > 
> > > > > > Subject    : gammu no longer works
> > > > > > References : http://lkml.org/lkml/2007/4/20/84
> > > > > > Submitter  : Wolfgang Erig <Wolfgang.Erig@gmx.de>
> > > > > > Status     : unknown
> > > > > 
> > > > > I've asked for more information about this, and so far am not sure it's
> > > > > a real problem.
> > > > 
> > > > It is a real problem for me.
> > > > I tried this on 2 different boxes with the same behaviour.
> > > > No sync between my Nokia mobile and Linux with the latest kernel :(
> > > 
> > > Sorry, I didn't see your response, have followed up on lkml now.
> > 
> > It turned out this was actually a bug in Gammu that will be fixed in 
> > the next release of Gammu.
> 
> Ah, ok, thanks for letting me know.
> 
> But how was the kernel version change triggering it?

I don't know, perhaps a side effect of Eric's work in kernel/signal.c?

The bug in Gammu was:
- Gammu wrongly set FASYNC in a fcntl() call.
- The unhandled SIGIO terminated Gammu in 2.6.21-rc.

Gammu being terminated by the SIGIO seems to be expected and documented 
behavior, and the surprising thing is that it wasn't terminated with 
earlier kernels.

> greg k-h

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [1/3] 2.6.21-rc7: known regressions (v2)

[Eric W. Biederman]

Adrian Bunk <bunk@stusta.de> writes:

> On Tue, Apr 24, 2007 at 05:51:11PM -0700, Greg KH wrote:
>> On Wed, Apr 25, 2007 at 02:29:58AM +0200, Adrian Bunk wrote:
>> > On Tue, Apr 24, 2007 at 05:14:28PM -0700, Greg KH wrote:
>> > > On Tue, Apr 24, 2007 at 11:32:53AM +0200, Wolfgang Erig wrote:
>> > > > On Mon, Apr 23, 2007 at 03:18:19PM -0700, Greg KH wrote:
>> > > > > On Mon, Apr 23, 2007 at 11:48:47PM +0200, Adrian Bunk wrote:
>> > > > > > This email lists some known regressions in Linus' tree compared to
> 2.6.20.
>> > > > > > 
>> > > > > > If you find your name in the Cc header, you are either submitter of
> one
>> > > > > > of the bugs, maintainer of an affectected subsystem or driver, a
> patch
>> > > > > > of you caused a breakage or I'm considering you in any other way
>> > > > > > possibly involved with one or more of these issues.
>> > > > > > 
>> > > > > > Due to the huge amount of recipients, please trim the Cc when
> answering.
>> > > > > > 
>> > > > > > 
>> > > > > > Subject    : gammu no longer works
>> > > > > > References : http://lkml.org/lkml/2007/4/20/84
>> > > > > > Submitter  : Wolfgang Erig <Wolfgang.Erig@gmx.de>
>> > > > > > Status     : unknown
>> > > > > 
>> > > > > I've asked for more information about this, and so far am not sure
> it's
>> > > > > a real problem.
>> > > > 
>> > > > It is a real problem for me.
>> > > > I tried this on 2 different boxes with the same behaviour.
>> > > > No sync between my Nokia mobile and Linux with the latest kernel :(
>> > > 
>> > > Sorry, I didn't see your response, have followed up on lkml now.
>> > 
>> > It turned out this was actually a bug in Gammu that will be fixed in 
>> > the next release of Gammu.
>> 
>> Ah, ok, thanks for letting me know.
>> 
>> But how was the kernel version change triggering it?
>
> I don't know, perhaps a side effect of Eric's work in kernel/signal.c?

Perhaps there has been a bit of churn.  Most of what I have done has
been fixing corner cases like not sending a signal to the wrong task,
after our original target has exited.

Although in conjunction with Oleg and some others there has been things
like changing locking to rcu or making locks more local so the timing
may have changed.  Which is make some subtle timing thing my best
guess.  For timing changes just about anything could have triggered
something.

I took a quick glance at the code and I certainly touched some of
the helpers like send_sigio that seem to be called by fasync
processing but I haven't a clue what FASYNC really does.  So I'm
having trouble putting this all into perspective.

I guess it's possible I fixed something without realizing it.


Eric

Re: [1/3] 2.6.21-rc7: known regressions (v2)

[Wolfgang Erig]

On Wed, Apr 25, 2007 at 03:21:53AM +0200, Adrian Bunk wrote:
> On Tue, Apr 24, 2007 at 05:51:11PM -0700, Greg KH wrote:
> > On Wed, Apr 25, 2007 at 02:29:58AM +0200, Adrian Bunk wrote:
> > > On Tue, Apr 24, 2007 at 05:14:28PM -0700, Greg KH wrote:
> > > > On Tue, Apr 24, 2007 at 11:32:53AM +0200, Wolfgang Erig wrote:
> > > > > On Mon, Apr 23, 2007 at 03:18:19PM -0700, Greg KH wrote:
> > > > > > On Mon, Apr 23, 2007 at 11:48:47PM +0200, Adrian Bunk wrote:
> > > > > > > This email lists some known regressions in Linus' tree compared to 2.6.20.
> > > > > > > 
> > > > > > > If you find your name in the Cc header, you are either submitter of one
> > > > > > > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > > > > > > of you caused a breakage or I'm considering you in any other way
> > > > > > > possibly involved with one or more of these issues.
> > > > > > > 
> > > > > > > Due to the huge amount of recipients, please trim the Cc when answering.
> > > > > > > 
> > > > > > > 
> > > > > > > Subject    : gammu no longer works
> > > > > > > References : http://lkml.org/lkml/2007/4/20/84
> > > > > > > Submitter  : Wolfgang Erig <Wolfgang.Erig@gmx.de>
> > > > > > > Status     : unknown
> > > > > > 
> > > > > > I've asked for more information about this, and so far am not sure it's
> > > > > > a real problem.
> > > > > 
> > > > > It is a real problem for me.
> > > > > I tried this on 2 different boxes with the same behaviour.
> > > > > No sync between my Nokia mobile and Linux with the latest kernel :(
> > > > 
> > > > Sorry, I didn't see your response, have followed up on lkml now.
> > > 
> > > It turned out this was actually a bug in Gammu that will be fixed in 
> > > the next release of Gammu.
> > 
> > Ah, ok, thanks for letting me know.
> > 
> > But how was the kernel version change triggering it?
> 
> I don't know, perhaps a side effect of Eric's work in kernel/signal.c?
> 
> The bug in Gammu was:
> - Gammu wrongly set FASYNC in a fcntl() call.
> - The unhandled SIGIO terminated Gammu in 2.6.21-rc.

I tried it: get the source of gammu, remove FASYNC, ... etc.
It works.

Thankyou for the fun,
Wolfgang

[2/3] 2.6.21-rc7: known regressions (v2)

[Adrian Bunk]

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : ACPI: Crashes + hangs during modprobe processor
                   unless "processor.nocst"
References : http://bugzilla.kernel.org/show_bug.cgi?id=8346
Submitter  : Olaf Kirch <okir@lst.de>
Status     : unknown


Subject    : kernels fail to boot with drives on ATIIXP controller
             (ACPI/IRQ related)
References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621
             http://lkml.org/lkml/2007/3/4/257
Submitter  : Michal Jaegermann <michal@ellpspace.math.ualberta.ca>
Status     : unknown


Subject    : ali_pata: boot from CD fails
References : http://lkml.org/lkml/2007/3/31/160
Submitter  : Stephen Clark <Stephen.Clark@seclark.us>
Status     : unknown


Subject    : boot failure: rtl8139: exception in interrupt routine
References : http://lkml.org/lkml/2007/3/31/160
Submitter  : Stephen Clark <Stephen.Clark@seclark.us>
Status     : unknown


Subject    : qla2xxx driver no longer works
References : http://lkml.org/lkml/2007/4/16/49
             http://lkml.org/lkml/2007/4/20/224
Submitter  : David Miller <davem@davemloft.net>
             Robert Peterson <rpeterso@redhat.com>
Handled-By : David Miller <davem@davemloft.net>
Patch      : http://lkml.org/lkml/2007/4/16/234
Status     : patch was suggested

[3/3] 2.6.21-rc7: known regressions (v2)

[Adrian Bunk]

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : HPET enabled freeze my machine at boot
             workaround: clocksource=acpi_pm
References : http://lkml.org/lkml/2007/4/19/370
Submitter  : Guilherme Schroeder <guilherme@centralinf.com.br>
Caused-By  : Thomas Gleixner <tglx@linutronix.de>
             commit 5d8b34fdcb384161552d01ee8f34af5ff11f9684
Handled-By : John Stultz <johnstul@us.ibm.com>
Status     : problem is being debugged


Subject    : acpi_pm clocksource loses time on x86-64
References : http://lkml.org/lkml/2007/4/17/143
Submitter  : Mikael Pettersson <mikpe@it.uu.se>
Handled-By : John Stultz <johnstul@us.ibm.com>
Status     : problem is being debugged


Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
Status     : unknown


Subject    : ThinkPad X60: resume no longer works  (PCI related?)
             workaround: CONFIG_FB_BACKLIGHT=n
References : http://lkml.org/lkml/2007/3/13/3
Submitter  : Dave Jones <davej@redhat.com>
Caused-By  : PCI merge
             commit 78149df6d565c36675463352d0bfe0000b02b7a7
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
             Rafael J. Wysocki <rjw@sisk.pl>
             Antonino A. Daplas <adaplas@gmail.com>
Status     : unknown


Subject    : suspend to disk works only once
             workaround: "echo shutdown > /sys/power/disk"
References : http://lkml.org/lkml/2007/4/13/240
Submitter  : Tobias Diedrich <ranma+kernel@tdiedrich.de>
Caused-By  : Rafael J. Wysocki <rjw@sisk.pl>
             commit ed746e3b18f4df18afa3763155972c5835f284c5
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
             Dmitry Torokhov <dtor@insightbb.com>
Status     : problem is being debugged

[3/3] 2.6.21-rc7: known regressions (v2)

[Adrian Bunk]

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : HPET enabled freeze my machine at boot
             workaround: clocksource=acpi_pm
References : http://lkml.org/lkml/2007/4/19/370
Submitter  : Guilherme Schroeder <guilherme@centralinf.com.br>
Caused-By  : Thomas Gleixner <tglx@linutronix.de>
             commit 5d8b34fdcb384161552d01ee8f34af5ff11f9684
Handled-By : John Stultz <johnstul@us.ibm.com>
Status     : problem is being debugged


Subject    : acpi_pm clocksource loses time on x86-64
References : http://lkml.org/lkml/2007/4/17/143
Submitter  : Mikael Pettersson <mikpe@it.uu.se>
Handled-By : John Stultz <johnstul@us.ibm.com>
Status     : problem is being debugged


Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
Status     : unknown


Subject    : ThinkPad X60: resume no longer works  (PCI related?)
             workaround: CONFIG_FB_BACKLIGHT=n
References : http://lkml.org/lkml/2007/3/13/3
Submitter  : Dave Jones <davej@redhat.com>
Caused-By  : PCI merge
             commit 78149df6d565c36675463352d0bfe0000b02b7a7
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
             Rafael J. Wysocki <rjw@sisk.pl>
             Antonino A. Daplas <adaplas@gmail.com>
Status     : unknown


Subject    : suspend to disk works only once
             workaround: "echo shutdown > /sys/power/disk"
References : http://lkml.org/lkml/2007/4/13/240
Submitter  : Tobias Diedrich <ranma+kernel@tdiedrich.de>
Caused-By  : Rafael J. Wysocki <rjw@sisk.pl>
             commit ed746e3b18f4df18afa3763155972c5835f284c5
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
             Dmitry Torokhov <dtor@insightbb.com>
Status     : problem is being debugged

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Andrew Morton]

On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:

> This email lists some known regressions in Linus' tree compared to 2.6.20.
> 
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way
> possibly involved with one or more of these issues.
> 
> Due to the huge amount of recipients, please trim the Cc when answering.
> 
> 
> Subject    : HPET enabled freeze my machine at boot
>              workaround: clocksource=acpi_pm
> References : http://lkml.org/lkml/2007/4/19/370
> Submitter  : Guilherme Schroeder <guilherme@centralinf.com.br>
> Caused-By  : Thomas Gleixner <tglx@linutronix.de>
>              commit 5d8b34fdcb384161552d01ee8f34af5ff11f9684
> Handled-By : John Stultz <johnstul@us.ibm.com>
> Status     : problem is being debugged
> 
> 
> Subject    : acpi_pm clocksource loses time on x86-64
> References : http://lkml.org/lkml/2007/4/17/143
> Submitter  : Mikael Pettersson <mikpe@it.uu.se>
> Handled-By : John Stultz <johnstul@us.ibm.com>
> Status     : problem is being debugged
> 
> 
> Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> References : http://lkml.org/lkml/2007/3/25/217
> Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> Status     : unknown

That's still rather a lot of bustage from the timekeeping changes.  Is
anything really happening here or have we all given up?

> 
> Subject    : ThinkPad X60: resume no longer works  (PCI related?)
>              workaround: CONFIG_FB_BACKLIGHT=n
> References : http://lkml.org/lkml/2007/3/13/3
> Submitter  : Dave Jones <davej@redhat.com>
> Caused-By  : PCI merge
>              commit 78149df6d565c36675463352d0bfe0000b02b7a7
> Handled-By : Eric W. Biederman <ebiederm@xmission.com>
>              Rafael J. Wysocki <rjw@sisk.pl>
>              Antonino A. Daplas <adaplas@gmail.com>
> Status     : unknown
> 

Is this related to the problems Jeremy has been looking at?

> Subject    : suspend to disk works only once
>              workaround: "echo shutdown > /sys/power/disk"
> References : http://lkml.org/lkml/2007/4/13/240
> Submitter  : Tobias Diedrich <ranma+kernel@tdiedrich.de>
> Caused-By  : Rafael J. Wysocki <rjw@sisk.pl>
>              commit ed746e3b18f4df18afa3763155972c5835f284c5
> Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
>              Dmitry Torokhov <dtor@insightbb.com>
> Status     : problem is being debugged

That's been happening on my Vaio-of-death for several weeks now.  I spent a
bit of time with the ACPI guys on it but we didn't get far.  I need to
find an hour or two to work out what's gone wrong.

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Andrew Morton]

On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:

> This email lists some known regressions in Linus' tree compared to 2.6.20.
> 
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way
> possibly involved with one or more of these issues.
> 
> Due to the huge amount of recipients, please trim the Cc when answering.
> 
> 
> Subject    : HPET enabled freeze my machine at boot
>              workaround: clocksource=acpi_pm
> References : http://lkml.org/lkml/2007/4/19/370
> Submitter  : Guilherme Schroeder <guilherme@centralinf.com.br>
> Caused-By  : Thomas Gleixner <tglx@linutronix.de>
>              commit 5d8b34fdcb384161552d01ee8f34af5ff11f9684
> Handled-By : John Stultz <johnstul@us.ibm.com>
> Status     : problem is being debugged
> 
> 
> Subject    : acpi_pm clocksource loses time on x86-64
> References : http://lkml.org/lkml/2007/4/17/143
> Submitter  : Mikael Pettersson <mikpe@it.uu.se>
> Handled-By : John Stultz <johnstul@us.ibm.com>
> Status     : problem is being debugged
> 
> 
> Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> References : http://lkml.org/lkml/2007/3/25/217
> Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> Status     : unknown

That's still rather a lot of bustage from the timekeeping changes.  Is
anything really happening here or have we all given up?

> 
> Subject    : ThinkPad X60: resume no longer works  (PCI related?)
>              workaround: CONFIG_FB_BACKLIGHT=n
> References : http://lkml.org/lkml/2007/3/13/3
> Submitter  : Dave Jones <davej@redhat.com>
> Caused-By  : PCI merge
>              commit 78149df6d565c36675463352d0bfe0000b02b7a7
> Handled-By : Eric W. Biederman <ebiederm@xmission.com>
>              Rafael J. Wysocki <rjw@sisk.pl>
>              Antonino A. Daplas <adaplas@gmail.com>
> Status     : unknown
> 

Is this related to the problems Jeremy has been looking at?

> Subject    : suspend to disk works only once
>              workaround: "echo shutdown > /sys/power/disk"
> References : http://lkml.org/lkml/2007/4/13/240
> Submitter  : Tobias Diedrich <ranma+kernel@tdiedrich.de>
> Caused-By  : Rafael J. Wysocki <rjw@sisk.pl>
>              commit ed746e3b18f4df18afa3763155972c5835f284c5
> Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
>              Dmitry Torokhov <dtor@insightbb.com>
> Status     : problem is being debugged

That's been happening on my Vaio-of-death for several weeks now.  I spent a
bit of time with the ACPI guys on it but we didn't get far.  I need to
find an hour or two to work out what's gone wrong.

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Adrian Bunk]

On Wed, Apr 25, 2007 at 04:06:05AM -0700, Andrew Morton wrote:
> On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
>...
> > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
> >              workaround: CONFIG_FB_BACKLIGHT=n
> > References : http://lkml.org/lkml/2007/3/13/3
> > Submitter  : Dave Jones <davej@redhat.com>
> > Caused-By  : PCI merge
> >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
> > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
> >              Rafael J. Wysocki <rjw@sisk.pl>
> >              Antonino A. Daplas <adaplas@gmail.com>
> > Status     : unknown
> 
> Is this related to the problems Jeremy has been looking at?
>...

Dave and Jeremy hran into similar looking but most likely different 
problems.

For Jeremy -rc7 is working fine, but for Dave it doesn't.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Adrian Bunk]

On Wed, Apr 25, 2007 at 04:06:05AM -0700, Andrew Morton wrote:
> On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
>...
> > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
> >              workaround: CONFIG_FB_BACKLIGHT=n
> > References : http://lkml.org/lkml/2007/3/13/3
> > Submitter  : Dave Jones <davej@redhat.com>
> > Caused-By  : PCI merge
> >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
> > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
> >              Rafael J. Wysocki <rjw@sisk.pl>
> >              Antonino A. Daplas <adaplas@gmail.com>
> > Status     : unknown
> 
> Is this related to the problems Jeremy has been looking at?
>...

Dave and Jeremy hran into similar looking but most likely different 
problems.

For Jeremy -rc7 is working fine, but for Dave it doesn't.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Dave Jones]

On Wed, Apr 25, 2007 at 01:31:02PM +0200, Adrian Bunk wrote:
 > On Wed, Apr 25, 2007 at 04:06:05AM -0700, Andrew Morton wrote:
 > > On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
 > >...
 > > > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
 > > >              workaround: CONFIG_FB_BACKLIGHT=n
 > > > References : http://lkml.org/lkml/2007/3/13/3
 > > > Submitter  : Dave Jones <davej@redhat.com>
 > > > Caused-By  : PCI merge
 > > >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
 > > > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
 > > >              Rafael J. Wysocki <rjw@sisk.pl>
 > > >              Antonino A. Daplas <adaplas@gmail.com>
 > > > Status     : unknown
 > > 
 > > Is this related to the problems Jeremy has been looking at?
 > >...
 > 
 > Dave and Jeremy hran into similar looking but most likely different 
 > problems.
 > 
 > For Jeremy -rc7 is working fine, but for Dave it doesn't.

I think this was due to Jeremy not having CONFIG_FB_BACKLIGHT=y in his config.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Dave Jones]

On Wed, Apr 25, 2007 at 01:31:02PM +0200, Adrian Bunk wrote:
 > On Wed, Apr 25, 2007 at 04:06:05AM -0700, Andrew Morton wrote:
 > > On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
 > >...
 > > > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
 > > >              workaround: CONFIG_FB_BACKLIGHT=n
 > > > References : http://lkml.org/lkml/2007/3/13/3
 > > > Submitter  : Dave Jones <davej@redhat.com>
 > > > Caused-By  : PCI merge
 > > >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
 > > > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
 > > >              Rafael J. Wysocki <rjw@sisk.pl>
 > > >              Antonino A. Daplas <adaplas@gmail.com>
 > > > Status     : unknown
 > > 
 > > Is this related to the problems Jeremy has been looking at?
 > >...
 > 
 > Dave and Jeremy hran into similar looking but most likely different 
 > problems.
 > 
 > For Jeremy -rc7 is working fine, but for Dave it doesn't.

I think this was due to Jeremy not having CONFIG_FB_BACKLIGHT=y in his config.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Antonino A. Daplas]

On Wed, 2007-04-25 at 09:01 -0400, Dave Jones wrote:
> On Wed, Apr 25, 2007 at 01:31:02PM +0200, Adrian Bunk wrote:
>  > On Wed, Apr 25, 2007 at 04:06:05AM -0700, Andrew Morton wrote:
>  > > On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
>  > >...
>  > > > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
>  > > >              workaround: CONFIG_FB_BACKLIGHT=n
>  > > > References : http://lkml.org/lkml/2007/3/13/3
>  > > > Submitter  : Dave Jones <davej@redhat.com>
>  > > > Caused-By  : PCI merge
>  > > >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
>  > > > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
>  > > >              Rafael J. Wysocki <rjw@sisk.pl>
>  > > >              Antonino A. Daplas <adaplas@gmail.com>
>  > > > Status     : unknown
>  > > 
>  > > Is this related to the problems Jeremy has been looking at?
>  > >...
>  > 
>  > Dave and Jeremy hran into similar looking but most likely different 
>  > problems.
>  > 
>  > For Jeremy -rc7 is working fine, but for Dave it doesn't.
> 
> I think this was due to Jeremy not having CONFIG_FB_BACKLIGHT=y in his config.

This is really weird, as CONFIG_FB_BACKLIGHT just selects
BACKLIGHT_CLASS and LCD_CLASS, and adds an entry (bl_curve)
under /sys/class/backlight/*/. ACPI_IBM which is set (presumably) in
Dave's kconfig, also selects the BACKLIGHT_CLASS. And the only possible
framebuffer drivers in the thinkpad are vesafb and intelfb, none of
which has a backlight driver.

I'm still at a loss how this happens.  Dave, can you post your config?
And have you tried the following settings:

FB_BACKLIGHT=y
ACPI_IBM=n
ACPI_VIDEO=n

I'm also adding Richard Purdie to the CC list.

Tony 

PS: I also get a blank display on resume with a Toshiba laptop.  But
cycling through the Fn keys brings it back.  I don't know if this is a
regression, I will have to try older kernels.

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Antonino A. Daplas]

On Wed, 2007-04-25 at 09:01 -0400, Dave Jones wrote:
> On Wed, Apr 25, 2007 at 01:31:02PM +0200, Adrian Bunk wrote:
>  > On Wed, Apr 25, 2007 at 04:06:05AM -0700, Andrew Morton wrote:
>  > > On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
>  > >...
>  > > > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
>  > > >              workaround: CONFIG_FB_BACKLIGHT=n
>  > > > References : http://lkml.org/lkml/2007/3/13/3
>  > > > Submitter  : Dave Jones <davej@redhat.com>
>  > > > Caused-By  : PCI merge
>  > > >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
>  > > > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
>  > > >              Rafael J. Wysocki <rjw@sisk.pl>
>  > > >              Antonino A. Daplas <adaplas@gmail.com>
>  > > > Status     : unknown
>  > > 
>  > > Is this related to the problems Jeremy has been looking at?
>  > >...
>  > 
>  > Dave and Jeremy hran into similar looking but most likely different 
>  > problems.
>  > 
>  > For Jeremy -rc7 is working fine, but for Dave it doesn't.
> 
> I think this was due to Jeremy not having CONFIG_FB_BACKLIGHT=y in his config.

This is really weird, as CONFIG_FB_BACKLIGHT just selects
BACKLIGHT_CLASS and LCD_CLASS, and adds an entry (bl_curve)
under /sys/class/backlight/*/. ACPI_IBM which is set (presumably) in
Dave's kconfig, also selects the BACKLIGHT_CLASS. And the only possible
framebuffer drivers in the thinkpad are vesafb and intelfb, none of
which has a backlight driver.

I'm still at a loss how this happens.  Dave, can you post your config?
And have you tried the following settings:

FB_BACKLIGHT=y
ACPI_IBM=n
ACPI_VIDEO=n

I'm also adding Richard Purdie to the CC list.

Tony 

PS: I also get a blank display on resume with a Toshiba laptop.  But
cycling through the Fn keys brings it back.  I don't know if this is a
regression, I will have to try older kernels.

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Antonino A. Daplas]

Forgot to add Richard, sorry for the double post.

On Wed, 2007-04-25 at 21:50 +0800, Antonino A. Daplas wrote:
> On Wed, 2007-04-25 at 09:01 -0400, Dave Jones wrote:
> > On Wed, Apr 25, 2007 at 01:31:02PM +0200, Adrian Bunk wrote:
> >  > On Wed, Apr 25, 2007 at 04:06:05AM -0700, Andrew Morton wrote:
> >  > > On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
> >  > >...
> >  > > > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
> >  > > >              workaround: CONFIG_FB_BACKLIGHT=n
> >  > > > References : http://lkml.org/lkml/2007/3/13/3
> >  > > > Submitter  : Dave Jones <davej@redhat.com>
> >  > > > Caused-By  : PCI merge
> >  > > >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
> >  > > > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
> >  > > >              Rafael J. Wysocki <rjw@sisk.pl>
> >  > > >              Antonino A. Daplas <adaplas@gmail.com>
> >  > > > Status     : unknown
> >  > > 
> >  > > Is this related to the problems Jeremy has been looking at?
> >  > >...
> >  > 
> >  > Dave and Jeremy hran into similar looking but most likely different 
> >  > problems.
> >  > 
> >  > For Jeremy -rc7 is working fine, but for Dave it doesn't.
> > 
> > I think this was due to Jeremy not having CONFIG_FB_BACKLIGHT=y in his config.
> 
> This is really weird, as CONFIG_FB_BACKLIGHT just selects
> BACKLIGHT_CLASS and LCD_CLASS, and adds an entry (bl_curve)
> under /sys/class/backlight/*/. ACPI_IBM which is set (presumably) in
> Dave's kconfig, also selects the BACKLIGHT_CLASS. And the only possible
> framebuffer drivers in the thinkpad are vesafb and intelfb, none of
> which has a backlight driver.
> 
> I'm still at a loss how this happens.  Dave, can you post your config?
> And have you tried the following settings:
> 
> FB_BACKLIGHT=y
> ACPI_IBM=n
> ACPI_VIDEO=n
> 
> I'm also adding Richard Purdie to the CC list.
> 
> Tony 
> 
> PS: I also get a blank display on resume with a Toshiba laptop.  But
> cycling through the Fn keys brings it back.  I don't know if this is a
> regression, I will have to try older kernels.
> 

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Dave Jones]

On Wed, Apr 25, 2007 at 09:52:16PM +0800, Antonino A. Daplas wrote:
 > > This is really weird, as CONFIG_FB_BACKLIGHT just selects
 > > BACKLIGHT_CLASS and LCD_CLASS, and adds an entry (bl_curve)
 > > under /sys/class/backlight/*/.

Yeah, it's puzzling to me too.

 > > ACPI_IBM which is set (presumably) in
 > > Dave's kconfig, also selects the BACKLIGHT_CLASS. And the only possible
 > > framebuffer drivers in the thinkpad are vesafb and intelfb, none of
 > > which has a backlight driver.
 > > 
 > > I'm still at a loss how this happens.  Dave, can you post your config?

http://people.redhat.com/davej/config-x60

 > > And have you tried the following settings:
 > > FB_BACKLIGHT=y
 > > ACPI_IBM=n
 > > ACPI_VIDEO=n

I think I've tried that yes.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Dave Jones]

On Wed, Apr 25, 2007 at 09:52:16PM +0800, Antonino A. Daplas wrote:
 > > This is really weird, as CONFIG_FB_BACKLIGHT just selects
 > > BACKLIGHT_CLASS and LCD_CLASS, and adds an entry (bl_curve)
 > > under /sys/class/backlight/*/.

Yeah, it's puzzling to me too.

 > > ACPI_IBM which is set (presumably) in
 > > Dave's kconfig, also selects the BACKLIGHT_CLASS. And the only possible
 > > framebuffer drivers in the thinkpad are vesafb and intelfb, none of
 > > which has a backlight driver.
 > > 
 > > I'm still at a loss how this happens.  Dave, can you post your config?

http://people.redhat.com/davej/config-x60

 > > And have you tried the following settings:
 > > FB_BACKLIGHT=y
 > > ACPI_IBM=n
 > > ACPI_VIDEO=n

I think I've tried that yes.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Antonino A. Daplas]

On Wed, 2007-04-25 at 10:33 -0400, Dave Jones wrote:
> On Wed, Apr 25, 2007 at 09:52:16PM +0800, Antonino A. Daplas wrote:
>  > > And have you tried the following settings:
>  > > FB_BACKLIGHT=y
>  > > ACPI_IBM=n
>  > > ACPI_VIDEO=n
> 

BTW, there was one report where resume from RAM resulted in a screen
full of garbage.  It seems that the option acpi_sleep= (or s2ram -a3)
did not work for him anymore.  But it worked with s2ram and other
options. So if you have s2ram, try:

s2ram -f -s -a3
s2ram -f -m -a3
s2ram -f -p -m
s2ram -f -p -s

Tony 

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Dave Jones]

On Wed, Apr 25, 2007 at 11:24:42PM +0800, Antonino A. Daplas wrote:
 > On Wed, 2007-04-25 at 10:33 -0400, Dave Jones wrote:
 > > On Wed, Apr 25, 2007 at 09:52:16PM +0800, Antonino A. Daplas wrote:
 > >  > > And have you tried the following settings:
 > >  > > FB_BACKLIGHT=y
 > >  > > ACPI_IBM=n
 > >  > > ACPI_VIDEO=n
 > > 
 > 
 > BTW, there was one report where resume from RAM resulted in a screen
 > full of garbage.  It seems that the option acpi_sleep= (or s2ram -a3)
 > did not work for him anymore.  But it worked with s2ram and other
 > options. So if you have s2ram, try:
 > 
 > s2ram -f -s -a3
 > s2ram -f -m -a3
 > s2ram -f -p -m
 > s2ram -f -p -s

I just did a pull of linus' tree, and it now works for me fine.
Adrian, I think we can remove this from the list.

I can't explain what fixed it (or even what caused it in the first place),
but it seems to be behaving itself.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Dave Jones]

On Wed, Apr 25, 2007 at 11:24:42PM +0800, Antonino A. Daplas wrote:
 > On Wed, 2007-04-25 at 10:33 -0400, Dave Jones wrote:
 > > On Wed, Apr 25, 2007 at 09:52:16PM +0800, Antonino A. Daplas wrote:
 > >  > > And have you tried the following settings:
 > >  > > FB_BACKLIGHT=y
 > >  > > ACPI_IBM=n
 > >  > > ACPI_VIDEO=n
 > > 
 > 
 > BTW, there was one report where resume from RAM resulted in a screen
 > full of garbage.  It seems that the option acpi_sleep= (or s2ram -a3)
 > did not work for him anymore.  But it worked with s2ram and other
 > options. So if you have s2ram, try:
 > 
 > s2ram -f -s -a3
 > s2ram -f -m -a3
 > s2ram -f -p -m
 > s2ram -f -p -s

I just did a pull of linus' tree, and it now works for me fine.
Adrian, I think we can remove this from the list.

I can't explain what fixed it (or even what caused it in the first place),
but it seems to be behaving itself.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Adrian Bunk]

On Wed, Apr 25, 2007 at 12:31:45PM -0400, Dave Jones wrote:
> On Wed, Apr 25, 2007 at 11:24:42PM +0800, Antonino A. Daplas wrote:
>  > On Wed, 2007-04-25 at 10:33 -0400, Dave Jones wrote:
>  > > On Wed, Apr 25, 2007 at 09:52:16PM +0800, Antonino A. Daplas wrote:
>  > >  > > And have you tried the following settings:
>  > >  > > FB_BACKLIGHT=y
>  > >  > > ACPI_IBM=n
>  > >  > > ACPI_VIDEO=n
>  > > 
>  > 
>  > BTW, there was one report where resume from RAM resulted in a screen
>  > full of garbage.  It seems that the option acpi_sleep= (or s2ram -a3)
>  > did not work for him anymore.  But it worked with s2ram and other
>  > options. So if you have s2ram, try:
>  > 
>  > s2ram -f -s -a3
>  > s2ram -f -m -a3
>  > s2ram -f -p -m
>  > s2ram -f -p -s
> 
> I just did a pull of linus' tree, and it now works for me fine.
> Adrian, I think we can remove this from the list.
>...

Thanks, removed as "seems fixed in -rc8".

> 	Dave

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Adrian Bunk]

On Wed, Apr 25, 2007 at 12:31:45PM -0400, Dave Jones wrote:
> On Wed, Apr 25, 2007 at 11:24:42PM +0800, Antonino A. Daplas wrote:
>  > On Wed, 2007-04-25 at 10:33 -0400, Dave Jones wrote:
>  > > On Wed, Apr 25, 2007 at 09:52:16PM +0800, Antonino A. Daplas wrote:
>  > >  > > And have you tried the following settings:
>  > >  > > FB_BACKLIGHT=y
>  > >  > > ACPI_IBM=n
>  > >  > > ACPI_VIDEO=n
>  > > 
>  > 
>  > BTW, there was one report where resume from RAM resulted in a screen
>  > full of garbage.  It seems that the option acpi_sleep= (or s2ram -a3)
>  > did not work for him anymore.  But it worked with s2ram and other
>  > options. So if you have s2ram, try:
>  > 
>  > s2ram -f -s -a3
>  > s2ram -f -m -a3
>  > s2ram -f -p -m
>  > s2ram -f -p -s
> 
> I just did a pull of linus' tree, and it now works for me fine.
> Adrian, I think we can remove this from the list.
>...

Thanks, removed as "seems fixed in -rc8".

> 	Dave

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Antonino A. Daplas]

On Wed, 2007-04-25 at 10:33 -0400, Dave Jones wrote:
> On Wed, Apr 25, 2007 at 09:52:16PM +0800, Antonino A. Daplas wrote:
>  > > And have you tried the following settings:
>  > > FB_BACKLIGHT=y
>  > > ACPI_IBM=n
>  > > ACPI_VIDEO=n
> 

BTW, there was one report where resume from RAM resulted in a screen
full of garbage.  It seems that the option acpi_sleep= (or s2ram -a3)
did not work for him anymore.  But it worked with s2ram and other
options. So if you have s2ram, try:

s2ram -f -s -a3
s2ram -f -m -a3
s2ram -f -p -m
s2ram -f -p -s

Tony 

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Antonino A. Daplas]

Forgot to add Richard, sorry for the double post.

On Wed, 2007-04-25 at 21:50 +0800, Antonino A. Daplas wrote:
> On Wed, 2007-04-25 at 09:01 -0400, Dave Jones wrote:
> > On Wed, Apr 25, 2007 at 01:31:02PM +0200, Adrian Bunk wrote:
> >  > On Wed, Apr 25, 2007 at 04:06:05AM -0700, Andrew Morton wrote:
> >  > > On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
> >  > >...
> >  > > > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
> >  > > >              workaround: CONFIG_FB_BACKLIGHT=n
> >  > > > References : http://lkml.org/lkml/2007/3/13/3
> >  > > > Submitter  : Dave Jones <davej@redhat.com>
> >  > > > Caused-By  : PCI merge
> >  > > >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
> >  > > > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
> >  > > >              Rafael J. Wysocki <rjw@sisk.pl>
> >  > > >              Antonino A. Daplas <adaplas@gmail.com>
> >  > > > Status     : unknown
> >  > > 
> >  > > Is this related to the problems Jeremy has been looking at?
> >  > >...
> >  > 
> >  > Dave and Jeremy hran into similar looking but most likely different 
> >  > problems.
> >  > 
> >  > For Jeremy -rc7 is working fine, but for Dave it doesn't.
> > 
> > I think this was due to Jeremy not having CONFIG_FB_BACKLIGHT=y in his config.
> 
> This is really weird, as CONFIG_FB_BACKLIGHT just selects
> BACKLIGHT_CLASS and LCD_CLASS, and adds an entry (bl_curve)
> under /sys/class/backlight/*/. ACPI_IBM which is set (presumably) in
> Dave's kconfig, also selects the BACKLIGHT_CLASS. And the only possible
> framebuffer drivers in the thinkpad are vesafb and intelfb, none of
> which has a backlight driver.
> 
> I'm still at a loss how this happens.  Dave, can you post your config?
> And have you tried the following settings:
> 
> FB_BACKLIGHT=y
> ACPI_IBM=n
> ACPI_VIDEO=n
> 
> I'm also adding Richard Purdie to the CC list.
> 
> Tony 
> 
> PS: I also get a blank display on resume with a Toshiba laptop.  But
> cycling through the Fn keys brings it back.  I don't know if this is a
> regression, I will have to try older kernels.
> 

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Jeremy Fitzhardinge]

Dave Jones wrote:
> I think this was due to Jeremy not having CONFIG_FB_BACKLIGHT=y in his config.
>   

No, I enabled it and it still works.

    J

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Jeremy Fitzhardinge]

Dave Jones wrote:
> I think this was due to Jeremy not having CONFIG_FB_BACKLIGHT=y in his config.
>   

No, I enabled it and it still works.

    J

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Ingo Molnar]

* Andrew Morton <akpm@linux-foundation.org> wrote:

> > Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> > References : http://lkml.org/lkml/2007/3/25/217
> > Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> > Status     : unknown
> 
> That's still rather a lot of bustage from the timekeeping changes.  Is 
> anything really happening here or have we all given up?

Jeff: does that suspend-to-disk hang problem also happen if you use 
hpet=disable?

	Ingo

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Ingo Molnar]

* Andrew Morton <akpm@linux-foundation.org> wrote:

> > Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> > References : http://lkml.org/lkml/2007/3/25/217
> > Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> > Status     : unknown
> 
> That's still rather a lot of bustage from the timekeeping changes.  Is 
> anything really happening here or have we all given up?

Jeff: does that suspend-to-disk hang problem also happen if you use 
hpet=disable?

	Ingo

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Jeff Chua]

On 4/25/07, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > > Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> > > References : http://lkml.org/lkml/2007/3/25/217
> > > Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> > > Status     : unknown
> >
> > That's still rather a lot of bustage from the timekeeping changes.  Is
> > anything really happening here or have we all given up?
>
> Jeff: does that suspend-to-disk hang problem also happen if you use
> hpet=disable?

Yes, it is still broken with HPET disabled.

I've reported that if I press some keys, suspend will complete
successfully, otherwise, it'll just hang before the "percentage" comes
on.

Thanks,
Jeff.

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Thomas Gleixner]

Jeff,

On Wed, 2007-04-25 at 21:45 +0800, Jeff Chua wrote:
> On 4/25/07, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > > > Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> > > > References : http://lkml.org/lkml/2007/3/25/217
> > > > Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> > > > Status     : unknown
> > >
> > > That's still rather a lot of bustage from the timekeeping changes.  Is
> > > anything really happening here or have we all given up?
> >
> > Jeff: does that suspend-to-disk hang problem also happen if you use
> > hpet=disable?
> 
> Yes, it is still broken with HPET disabled.
> 
> I've reported that if I press some keys, suspend will complete
> successfully, otherwise, it'll just hang before the "percentage" comes
> on.

Can you please grab the collection of fixups, which I just put into
bugzilla: 

http://bugzilla.kernel.org/attachment.cgi?id=11379&action=view

and apply it on top of 2.6.21 ?

Thanks,

	tglx

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Thomas Gleixner]

Jeff,

On Wed, 2007-04-25 at 21:45 +0800, Jeff Chua wrote:
> On 4/25/07, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > > > Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> > > > References : http://lkml.org/lkml/2007/3/25/217
> > > > Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> > > > Status     : unknown
> > >
> > > That's still rather a lot of bustage from the timekeeping changes.  Is
> > > anything really happening here or have we all given up?
> >
> > Jeff: does that suspend-to-disk hang problem also happen if you use
> > hpet=disable?
> 
> Yes, it is still broken with HPET disabled.
> 
> I've reported that if I press some keys, suspend will complete
> successfully, otherwise, it'll just hang before the "percentage" comes
> on.

Can you please grab the collection of fixups, which I just put into
bugzilla: 

http://bugzilla.kernel.org/attachment.cgi?id=11379&action=view

and apply it on top of 2.6.21 ?

Thanks,

	tglx

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Jeff Chua]

On 4/25/07, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > > Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> > > References : http://lkml.org/lkml/2007/3/25/217
> > > Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> > > Status     : unknown
> >
> > That's still rather a lot of bustage from the timekeeping changes.  Is
> > anything really happening here or have we all given up?
>
> Jeff: does that suspend-to-disk hang problem also happen if you use
> hpet=disable?

Yes, it is still broken with HPET disabled.

I've reported that if I press some keys, suspend will complete
successfully, otherwise, it'll just hang before the "percentage" comes
on.

Thanks,
Jeff.

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Ingo Molnar]

just found and fixed the bug below in SysRq-T - should be included in 
v2.6.21 i think.

-------------------------->
Subject: [patch] make SysRq-T show all tasks again
From: Ingo Molnar <mingo@elte.hu>

show_state() (SysRq-T) developed the buggy habbit of not showing 
TASK_RUNNING tasks. This was due to the mistaken belief that 
state_filter == -1 would be a pass-through filter - while in reality it 
did not let TASK_RUNNING == 0 p->state values through.

(fix this be restoring the original '!state_filter means all tasks' 
special-case i had in the original version. Test-built and test-booted 
on i686, SysRq-T now works as intended.)

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 include/linux/sched.h |    4 ++--
 kernel/sched.c        |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

Index: linux/include/linux/sched.h
===================================================================
--- linux.orig/include/linux/sched.h
+++ linux/include/linux/sched.h
@@ -196,13 +196,13 @@ extern void init_idle(struct task_struct
 extern cpumask_t nohz_cpu_mask;
 
 /*
- * Only dump TASK_* tasks. (-1 for all tasks)
+ * Only dump TASK_* tasks. (0 for all tasks)
  */
 extern void show_state_filter(unsigned long state_filter);
 
 static inline void show_state(void)
 {
-	show_state_filter(-1);
+	show_state_filter(0);
 }
 
 extern void show_regs(struct pt_regs *);
Index: linux/kernel/sched.c
===================================================================
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -4746,7 +4746,7 @@ void show_state_filter(unsigned long sta
 		 * console might take alot of time:
 		 */
 		touch_nmi_watchdog();
-		if (p->state & state_filter)
+		if (!state_filter || (p->state & state_filter))
 			show_task(p);
 	} while_each_thread(g, p);
 

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[john stultz]

On Wed, 2007-04-25 at 04:06 -0700, Andrew Morton wrote:
> On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
> 
> > This email lists some known regressions in Linus' tree compared to 2.6.20.
> > 
> > If you find your name in the Cc header, you are either submitter of one
> > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > of you caused a breakage or I'm considering you in any other way
> > possibly involved with one or more of these issues.
> > 
> > Due to the huge amount of recipients, please trim the Cc when answering.
> > 
> > 
> > Subject    : HPET enabled freeze my machine at boot
> >              workaround: clocksource=acpi_pm
> > References : http://lkml.org/lkml/2007/4/19/370
> > Submitter  : Guilherme Schroeder <guilherme@centralinf.com.br>
> > Caused-By  : Thomas Gleixner <tglx@linutronix.de>
> >              commit 5d8b34fdcb384161552d01ee8f34af5ff11f9684
> > Handled-By : John Stultz <johnstul@us.ibm.com>
> > Status     : problem is being debugged
> > 
> > 
> > Subject    : acpi_pm clocksource loses time on x86-64
> > References : http://lkml.org/lkml/2007/4/17/143
> > Submitter  : Mikael Pettersson <mikpe@it.uu.se>
> > Handled-By : John Stultz <johnstul@us.ibm.com>
> > Status     : problem is being debugged
> > 
> > 
> > Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> > References : http://lkml.org/lkml/2007/3/25/217
> > Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> > Status     : unknown
> 
> That's still rather a lot of bustage from the timekeeping changes.  Is
> anything really happening here or have we all given up?


The ACPI PM one is *really* odd as its the same clocksource driver on
both arches. I had Mikael cut out the clocksource frequency adjustments,
and confirmed both i386 and x86_64 are using the same base freq
(confirmed via printks).

It almost seems like when booting x86_64 the ACPI PM counter is running
slowly! 

Len: Have you ever heard of such a thing? It seems quite unlikely...


WRT the HPET freeze issue, I'm still digging there. In that case it
appears the HPET isn't counting, so timekeeping just stops. I was
thinking it might be HRT messing w/ the wrong HPET registers, but so far
that hasn't shaken out.

I'll spend some more time on these today and see if we get any further.

thanks
-john

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[john stultz]

On Wed, 2007-04-25 at 04:06 -0700, Andrew Morton wrote:
> On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
> 
> > This email lists some known regressions in Linus' tree compared to 2.6.20.
> > 
> > If you find your name in the Cc header, you are either submitter of one
> > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > of you caused a breakage or I'm considering you in any other way
> > possibly involved with one or more of these issues.
> > 
> > Due to the huge amount of recipients, please trim the Cc when answering.
> > 
> > 
> > Subject    : HPET enabled freeze my machine at boot
> >              workaround: clocksource=acpi_pm
> > References : http://lkml.org/lkml/2007/4/19/370
> > Submitter  : Guilherme Schroeder <guilherme@centralinf.com.br>
> > Caused-By  : Thomas Gleixner <tglx@linutronix.de>
> >              commit 5d8b34fdcb384161552d01ee8f34af5ff11f9684
> > Handled-By : John Stultz <johnstul@us.ibm.com>
> > Status     : problem is being debugged
> > 
> > 
> > Subject    : acpi_pm clocksource loses time on x86-64
> > References : http://lkml.org/lkml/2007/4/17/143
> > Submitter  : Mikael Pettersson <mikpe@it.uu.se>
> > Handled-By : John Stultz <johnstul@us.ibm.com>
> > Status     : problem is being debugged
> > 
> > 
> > Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> > References : http://lkml.org/lkml/2007/3/25/217
> > Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> > Status     : unknown
> 
> That's still rather a lot of bustage from the timekeeping changes.  Is
> anything really happening here or have we all given up?


The ACPI PM one is *really* odd as its the same clocksource driver on
both arches. I had Mikael cut out the clocksource frequency adjustments,
and confirmed both i386 and x86_64 are using the same base freq
(confirmed via printks).

It almost seems like when booting x86_64 the ACPI PM counter is running
slowly! 

Len: Have you ever heard of such a thing? It seems quite unlikely...


WRT the HPET freeze issue, I'm still digging there. In that case it
appears the HPET isn't counting, so timekeeping just stops. I was
thinking it might be HRT messing w/ the wrong HPET registers, but so far
that hasn't shaken out.

I'll spend some more time on these today and see if we get any further.

thanks
-john

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Len Brown]

On Wednesday 25 April 2007 14:08, john stultz wrote:
> On Wed, 2007-04-25 at 04:06 -0700, Andrew Morton wrote:
> > On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
> > 
> > > This email lists some known regressions in Linus' tree compared to 2.6.20.
> > > 
> > > If you find your name in the Cc header, you are either submitter of one
> > > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > > of you caused a breakage or I'm considering you in any other way
> > > possibly involved with one or more of these issues.
> > > 
> > > Due to the huge amount of recipients, please trim the Cc when answering.
> > > 
> > > 
> > > Subject    : HPET enabled freeze my machine at boot
> > >              workaround: clocksource=acpi_pm
> > > References : http://lkml.org/lkml/2007/4/19/370
> > > Submitter  : Guilherme Schroeder <guilherme@centralinf.com.br>
> > > Caused-By  : Thomas Gleixner <tglx@linutronix.de>
> > >              commit 5d8b34fdcb384161552d01ee8f34af5ff11f9684
> > > Handled-By : John Stultz <johnstul@us.ibm.com>
> > > Status     : problem is being debugged
> > > 
> > > 
> > > Subject    : acpi_pm clocksource loses time on x86-64
> > > References : http://lkml.org/lkml/2007/4/17/143
> > > Submitter  : Mikael Pettersson <mikpe@it.uu.se>
> > > Handled-By : John Stultz <johnstul@us.ibm.com>
> > > Status     : problem is being debugged
> > > 
> > > 
> > > Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> > > References : http://lkml.org/lkml/2007/3/25/217
> > > Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> > > Status     : unknown
> > 
> > That's still rather a lot of bustage from the timekeeping changes.  Is
> > anything really happening here or have we all given up?
> 
> 
> The ACPI PM one is *really* odd as its the same clocksource driver on
> both arches. I had Mikael cut out the clocksource frequency adjustments,
> and confirmed both i386 and x86_64 are using the same base freq
> (confirmed via printks).

If this chipset's PM-timer loses "several minutes per hour" on x86_64,
I would expect it to do the same on i386.  I can't imagine what the
difference could be.  Any possibility it is the 24-bit version
and we do something funky on wraparound?

-Len


> It almost seems like when booting x86_64 the ACPI PM counter is running
> slowly! 
> 
> Len: Have you ever heard of such a thing? It seems quite unlikely...
> 
> 
> WRT the HPET freeze issue, I'm still digging there. In that case it
> appears the HPET isn't counting, so timekeeping just stops. I was
> thinking it might be HRT messing w/ the wrong HPET registers, but so far
> that hasn't shaken out.
> 
> I'll spend some more time on these today and see if we get any further.
> 
> thanks
> -john
> 
> 
> -
> 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/
> 

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Len Brown]

On Wednesday 25 April 2007 14:08, john stultz wrote:
> On Wed, 2007-04-25 at 04:06 -0700, Andrew Morton wrote:
> > On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
> > 
> > > This email lists some known regressions in Linus' tree compared to 2.6.20.
> > > 
> > > If you find your name in the Cc header, you are either submitter of one
> > > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > > of you caused a breakage or I'm considering you in any other way
> > > possibly involved with one or more of these issues.
> > > 
> > > Due to the huge amount of recipients, please trim the Cc when answering.
> > > 
> > > 
> > > Subject    : HPET enabled freeze my machine at boot
> > >              workaround: clocksource=acpi_pm
> > > References : http://lkml.org/lkml/2007/4/19/370
> > > Submitter  : Guilherme Schroeder <guilherme@centralinf.com.br>
> > > Caused-By  : Thomas Gleixner <tglx@linutronix.de>
> > >              commit 5d8b34fdcb384161552d01ee8f34af5ff11f9684
> > > Handled-By : John Stultz <johnstul@us.ibm.com>
> > > Status     : problem is being debugged
> > > 
> > > 
> > > Subject    : acpi_pm clocksource loses time on x86-64
> > > References : http://lkml.org/lkml/2007/4/17/143
> > > Submitter  : Mikael Pettersson <mikpe@it.uu.se>
> > > Handled-By : John Stultz <johnstul@us.ibm.com>
> > > Status     : problem is being debugged
> > > 
> > > 
> > > Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> > > References : http://lkml.org/lkml/2007/3/25/217
> > > Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> > > Status     : unknown
> > 
> > That's still rather a lot of bustage from the timekeeping changes.  Is
> > anything really happening here or have we all given up?
> 
> 
> The ACPI PM one is *really* odd as its the same clocksource driver on
> both arches. I had Mikael cut out the clocksource frequency adjustments,
> and confirmed both i386 and x86_64 are using the same base freq
> (confirmed via printks).

If this chipset's PM-timer loses "several minutes per hour" on x86_64,
I would expect it to do the same on i386.  I can't imagine what the
difference could be.  Any possibility it is the 24-bit version
and we do something funky on wraparound?

-Len


> It almost seems like when booting x86_64 the ACPI PM counter is running
> slowly! 
> 
> Len: Have you ever heard of such a thing? It seems quite unlikely...
> 
> 
> WRT the HPET freeze issue, I'm still digging there. In that case it
> appears the HPET isn't counting, so timekeeping just stops. I was
> thinking it might be HRT messing w/ the wrong HPET registers, but so far
> that hasn't shaken out.
> 
> I'll spend some more time on these today and see if we get any further.
> 
> thanks
> -john
> 
> 
> -
> 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/
> 

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[john stultz]

On Wed, 2007-04-25 at 20:33 -0400, Len Brown wrote:
> On Wednesday 25 April 2007 14:08, john stultz wrote:
> > On Wed, 2007-04-25 at 04:06 -0700, Andrew Morton wrote:
> > > On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
> > > > Subject    : acpi_pm clocksource loses time on x86-64
> > > > References : http://lkml.org/lkml/2007/4/17/143
> > > > Submitter  : Mikael Pettersson <mikpe@it.uu.se>
> > > > Handled-By : John Stultz <johnstul@us.ibm.com>
> > > > Status     : problem is being debugged
> > 
> > 
> > The ACPI PM one is *really* odd as its the same clocksource driver on
> > both arches. I had Mikael cut out the clocksource frequency adjustments,
> > and confirmed both i386 and x86_64 are using the same base freq
> > (confirmed via printks).
> 
> If this chipset's PM-timer loses "several minutes per hour" on x86_64,
> I would expect it to do the same on i386.  I can't imagine what the
> difference could be.  Any possibility it is the 24-bit version
> and we do something funky on wraparound?

No, we assume the PM timer wraps at 24 bits and mask it as such on all
systems.

-john

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[john stultz]

On Wed, 2007-04-25 at 20:33 -0400, Len Brown wrote:
> On Wednesday 25 April 2007 14:08, john stultz wrote:
> > On Wed, 2007-04-25 at 04:06 -0700, Andrew Morton wrote:
> > > On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
> > > > Subject    : acpi_pm clocksource loses time on x86-64
> > > > References : http://lkml.org/lkml/2007/4/17/143
> > > > Submitter  : Mikael Pettersson <mikpe@it.uu.se>
> > > > Handled-By : John Stultz <johnstul@us.ibm.com>
> > > > Status     : problem is being debugged
> > 
> > 
> > The ACPI PM one is *really* odd as its the same clocksource driver on
> > both arches. I had Mikael cut out the clocksource frequency adjustments,
> > and confirmed both i386 and x86_64 are using the same base freq
> > (confirmed via printks).
> 
> If this chipset's PM-timer loses "several minutes per hour" on x86_64,
> I would expect it to do the same on i386.  I can't imagine what the
> difference could be.  Any possibility it is the 24-bit version
> and we do something funky on wraparound?

No, we assume the PM timer wraps at 24 bits and mask it as such on all
systems.

-john

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Rafael J. Wysocki]

On Wednesday, 25 April 2007 13:06, Andrew Morton wrote:
> On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
> 
> > This email lists some known regressions in Linus' tree compared to 2.6.20.
> > 
> > If you find your name in the Cc header, you are either submitter of one
> > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > of you caused a breakage or I'm considering you in any other way
> > possibly involved with one or more of these issues.
> > 
> > Due to the huge amount of recipients, please trim the Cc when answering.
> > 
> > 
> > Subject    : HPET enabled freeze my machine at boot
> >              workaround: clocksource=acpi_pm
> > References : http://lkml.org/lkml/2007/4/19/370
> > Submitter  : Guilherme Schroeder <guilherme@centralinf.com.br>
> > Caused-By  : Thomas Gleixner <tglx@linutronix.de>
> >              commit 5d8b34fdcb384161552d01ee8f34af5ff11f9684
> > Handled-By : John Stultz <johnstul@us.ibm.com>
> > Status     : problem is being debugged
> > 
> > 
> > Subject    : acpi_pm clocksource loses time on x86-64
> > References : http://lkml.org/lkml/2007/4/17/143
> > Submitter  : Mikael Pettersson <mikpe@it.uu.se>
> > Handled-By : John Stultz <johnstul@us.ibm.com>
> > Status     : problem is being debugged
> > 
> > 
> > Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> > References : http://lkml.org/lkml/2007/3/25/217
> > Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> > Status     : unknown
> 
> That's still rather a lot of bustage from the timekeeping changes.  Is
> anything really happening here or have we all given up?
> 
> > 
> > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
> >              workaround: CONFIG_FB_BACKLIGHT=n
> > References : http://lkml.org/lkml/2007/3/13/3
> > Submitter  : Dave Jones <davej@redhat.com>
> > Caused-By  : PCI merge
> >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
> > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
> >              Rafael J. Wysocki <rjw@sisk.pl>
> >              Antonino A. Daplas <adaplas@gmail.com>
> > Status     : unknown
> > 
> 
> Is this related to the problems Jeremy has been looking at?
> 
> > Subject    : suspend to disk works only once
> >              workaround: "echo shutdown > /sys/power/disk"
> > References : http://lkml.org/lkml/2007/4/13/240
> > Submitter  : Tobias Diedrich <ranma+kernel@tdiedrich.de>
> > Caused-By  : Rafael J. Wysocki <rjw@sisk.pl>
> >              commit ed746e3b18f4df18afa3763155972c5835f284c5
> > Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
> >              Dmitry Torokhov <dtor@insightbb.com>
> > Status     : problem is being debugged
> 
> That's been happening on my Vaio-of-death for several weeks now.  I spent a
> bit of time with the ACPI guys on it but we didn't get far.  I need to
> find an hour or two to work out what's gone wrong.

I can't reproduce it on any of my machines ...

Does the appended patch help, BTW?


---
 kernel/power/disk.c |    4 ++--
 kernel/power/user.c |    8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

Index: linux-2.6.21-rc7/kernel/power/disk.c
===================================================================
--- linux-2.6.21-rc7.orig/kernel/power/disk.c
+++ linux-2.6.21-rc7/kernel/power/disk.c
@@ -170,9 +170,9 @@ int pm_suspend_disk(void)
 
 	if (in_suspend) {
 		enable_nonboot_cpus();
-		platform_finish();
 		device_resume();
 		resume_console();
+		platform_finish();
 		pr_debug("PM: writing image.\n");
 		error = swsusp_write();
 		if (!error)
@@ -189,9 +189,9 @@ int pm_suspend_disk(void)
  Enable_cpus:
 	enable_nonboot_cpus();
  Resume_devices:
-	platform_finish();
 	device_resume();
 	resume_console();
+	platform_finish();
  Thaw:
 	unprepare_processes();
  Finish:
Index: linux-2.6.21-rc7/kernel/power/user.c
===================================================================
--- linux-2.6.21-rc7.orig/kernel/power/user.c
+++ linux-2.6.21-rc7/kernel/power/user.c
@@ -170,11 +170,11 @@ static inline int snapshot_suspend(int p
 	}
 	enable_nonboot_cpus();
  Resume_devices:
+	device_resume();
+	resume_console();
 	if (platform_suspend)
 		platform_finish();
 
-	device_resume();
-	resume_console();
  Finish:
 	mutex_unlock(&pm_mutex);
 	return error;
@@ -202,11 +202,11 @@ static inline int snapshot_restore(int p
 
 	enable_nonboot_cpus();
  Resume_devices:
+	device_resume();
+	resume_console();
 	if (platform_suspend)
 		platform_finish();
 
-	device_resume();
-	resume_console();
  Finish:
 	pm_restore_console();
 	mutex_unlock(&pm_mutex);

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Rafael J. Wysocki]

On Wednesday, 25 April 2007 13:06, Andrew Morton wrote:
> On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
> 
> > This email lists some known regressions in Linus' tree compared to 2.6.20.
> > 
> > If you find your name in the Cc header, you are either submitter of one
> > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > of you caused a breakage or I'm considering you in any other way
> > possibly involved with one or more of these issues.
> > 
> > Due to the huge amount of recipients, please trim the Cc when answering.
> > 
> > 
> > Subject    : HPET enabled freeze my machine at boot
> >              workaround: clocksource=acpi_pm
> > References : http://lkml.org/lkml/2007/4/19/370
> > Submitter  : Guilherme Schroeder <guilherme@centralinf.com.br>
> > Caused-By  : Thomas Gleixner <tglx@linutronix.de>
> >              commit 5d8b34fdcb384161552d01ee8f34af5ff11f9684
> > Handled-By : John Stultz <johnstul@us.ibm.com>
> > Status     : problem is being debugged
> > 
> > 
> > Subject    : acpi_pm clocksource loses time on x86-64
> > References : http://lkml.org/lkml/2007/4/17/143
> > Submitter  : Mikael Pettersson <mikpe@it.uu.se>
> > Handled-By : John Stultz <johnstul@us.ibm.com>
> > Status     : problem is being debugged
> > 
> > 
> > Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> > References : http://lkml.org/lkml/2007/3/25/217
> > Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> > Status     : unknown
> 
> That's still rather a lot of bustage from the timekeeping changes.  Is
> anything really happening here or have we all given up?
> 
> > 
> > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
> >              workaround: CONFIG_FB_BACKLIGHT=n
> > References : http://lkml.org/lkml/2007/3/13/3
> > Submitter  : Dave Jones <davej@redhat.com>
> > Caused-By  : PCI merge
> >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
> > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
> >              Rafael J. Wysocki <rjw@sisk.pl>
> >              Antonino A. Daplas <adaplas@gmail.com>
> > Status     : unknown
> > 
> 
> Is this related to the problems Jeremy has been looking at?
> 
> > Subject    : suspend to disk works only once
> >              workaround: "echo shutdown > /sys/power/disk"
> > References : http://lkml.org/lkml/2007/4/13/240
> > Submitter  : Tobias Diedrich <ranma+kernel@tdiedrich.de>
> > Caused-By  : Rafael J. Wysocki <rjw@sisk.pl>
> >              commit ed746e3b18f4df18afa3763155972c5835f284c5
> > Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
> >              Dmitry Torokhov <dtor@insightbb.com>
> > Status     : problem is being debugged
> 
> That's been happening on my Vaio-of-death for several weeks now.  I spent a
> bit of time with the ACPI guys on it but we didn't get far.  I need to
> find an hour or two to work out what's gone wrong.

I can't reproduce it on any of my machines ...

Does the appended patch help, BTW?


---
 kernel/power/disk.c |    4 ++--
 kernel/power/user.c |    8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

Index: linux-2.6.21-rc7/kernel/power/disk.c
===================================================================
--- linux-2.6.21-rc7.orig/kernel/power/disk.c
+++ linux-2.6.21-rc7/kernel/power/disk.c
@@ -170,9 +170,9 @@ int pm_suspend_disk(void)
 
 	if (in_suspend) {
 		enable_nonboot_cpus();
-		platform_finish();
 		device_resume();
 		resume_console();
+		platform_finish();
 		pr_debug("PM: writing image.\n");
 		error = swsusp_write();
 		if (!error)
@@ -189,9 +189,9 @@ int pm_suspend_disk(void)
  Enable_cpus:
 	enable_nonboot_cpus();
  Resume_devices:
-	platform_finish();
 	device_resume();
 	resume_console();
+	platform_finish();
  Thaw:
 	unprepare_processes();
  Finish:
Index: linux-2.6.21-rc7/kernel/power/user.c
===================================================================
--- linux-2.6.21-rc7.orig/kernel/power/user.c
+++ linux-2.6.21-rc7/kernel/power/user.c
@@ -170,11 +170,11 @@ static inline int snapshot_suspend(int p
 	}
 	enable_nonboot_cpus();
  Resume_devices:
+	device_resume();
+	resume_console();
 	if (platform_suspend)
 		platform_finish();
 
-	device_resume();
-	resume_console();
  Finish:
 	mutex_unlock(&pm_mutex);
 	return error;
@@ -202,11 +202,11 @@ static inline int snapshot_restore(int p
 
 	enable_nonboot_cpus();
  Resume_devices:
+	device_resume();
+	resume_console();
 	if (platform_suspend)
 		platform_finish();
 
-	device_resume();
-	resume_console();
  Finish:
 	pm_restore_console();
 	mutex_unlock(&pm_mutex);

2.6.21-rc7: known regressions with patches

[Adrian Bunk]

This email lists some known regressions in Linus' tree compared to 2.6.20
with patches available.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : Oops when changing USB DVB-T adapter
References : http://lkml.org/lkml/2007/3/9/212
             http://lkml.org/lkml/2007/4/5/154
Submitter  : CIJOML <cijoml@volny.cz>
Handled-By : Markus Rechberger <markus.rechberger@amd.com>
Status     : patches available


Subject    : snd_intel8x0: divide error: 0000
References : http://lkml.org/lkml/2007/3/5/252
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Handled-By : Takashi Iwai <tiwai@suse.de>
Patch      : http://lkml.org/lkml/2007/4/20/117
Status     : patch available


Subject    : qla2xxx driver no longer works
References : http://lkml.org/lkml/2007/4/16/49
             http://lkml.org/lkml/2007/4/20/224
Submitter  : David Miller <davem@davemloft.net>
             Robert Peterson <rpeterso@redhat.com>
Handled-By : David Miller <davem@davemloft.net>
Patch      : http://lkml.org/lkml/2007/4/16/234
Status     : patch was suggested